[Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses when M flag is off

Simon Kelley simon at thekelleys.org.uk
Wed Jan 21 21:02:00 GMT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

My first reaction to this was to apply it, but then I went and looked
at RFC3315, and found this:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.

Which seems to indicate that the patch would violate the RFC.

But then I looked some more, and found this:

17.2.1. Receipt of Solicit Messages


   The server determines the information about the client and its
   location as described in section 11 and checks its administrative
   policy about responding to the client.  If the server is not
   permitted to respond to the client, the server discards the Solicit
   message.  For example, if the administrative policy for the server is
   that it may only respond to a client that is willing to accept a
   Reconfigure message, if the client indicates with a Reconfigure
   Accept option in the Solicit message that it will not accept a
   Reconfigure message, the servers discard the Solicit message.


So I think we can define "DHCPv6 address allocation not configured" as
administrative policy and chose to discard the solict message in this
case.

Patch applied, with some style changes, thanks.


Cheers,

Simon.







On 19/01/15 21:30, Win King Wan wrote:
> Hi,
> 
> In https://github.com/RMerl/asuswrt-merlin/pull/854 I patched the
> dnsmasq version of my router's firmware to not send out replies to
> DHCPv6 queries when dhcp-range mode is ra-stateless.
> 
> Even though the M flag is off in the router advertisement, Windows
> 8 (and newer) clients will still request an address via DHCPv6.
> When it receives a reply that no addresses are available, it tries
> a few more time before giving up for several minutes. After several
> minutes however it retries. This causes the syslog to be filled up
> with noise stating that there are no DHCPv6 addresses available for
> a specific MAC address. (--quiet-dhcp6 does not help much as the
> "no addresses  available" message is always logged.)
> 
> My changes basically stops dnsmasq from sending this reply. Since
> the O flag is on, Windows 8 will try to get other information from
> the DHCPv6 server if it does not get an reply for its initial
> request for an address (which seems to still work, as it is able to
> get the IPv6 DNS server).
> 
> After running Wireshark for quite some time, it appears that
> Windows 8 will not send out subsequent requests for an IPv6 address
> to the DHCPv6 server (after my patch), at least not within several
> minutes.
> 
> I have included the patch for completeness sake. Would it be
> possible to apply it? Or perhaps there is a better or more elegant
> solution to this problem?
> 
> diff --git a/src/rfc3315.c b/src/rfc3315.c index ddb390b..1f3646a
> 100644 --- a/src/rfc3315.c +++ b/src/rfc3315.c @@ -824,6 +824,19 @@
> static int dhcp6_no_relay(struct state *state, int msg_type, void
> *inbuff, size_ } else { +	    int all_stateless = 1; +	    for (c =
> state->context; c; c = c->current) +		if (!(c->flags &
> CONTEXT_RA_STATELESS)) +		  { +		    all_stateless = 0; +
> break; +		 } +	    if (all_stateless) +		/* Windows 8 always
> requests an address even if the Managed bit +		   in RA is 0 and it
> keeps retrying if it receives a reply +		   stating that no
> addresses are available */ +		return 0; + /* no address, return
> error */ o1 = new_opt6(OPTION6_STATUS_CODE); 
> put_opt6_short(DHCP6NOADDRS);
> 
> 
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUwBPHAAoJEBXN2mrhkTWixUIQAJ1NTzBIPhnb6K2GgQU63aWE
nd/0UKGk+TFof0YDdFIU/njC6TIwYC+gZTFu2jKnUGy14d2f8EA/4iuTCDIJ2H3b
hXHvKvZFv7nTmEpe/k7vj1owt+8ORtU7MTlJ0TA4pJ9hD8ySoF//IuaCX+jyXmps
txErXdToX87i7Ry+EFQwMNQwIPZUSggMuK0cjp+mkEgAdeqGJStT3EOJ6jl4eg4d
GLjz5SFDQfrz2FRcWbW05SqoaaTn1KlwwHxkkCxVXYuYaJ52z0hIIVjJsz6K8uxL
VrVTDiJr93yUWGLZx71gd8Luj+hSJfO/dsyhOjqezKlb/TPyhowdCSPjzjEUihao
wdHWV8DT8WHjYrqwaAO06zfi7kQbiw24vCtV4UxuW4HzS9etrgh7nMI6exUZCztE
dtsE7G7vMZKlof7A3wsZFm/tD3Ey14Ohvrrp0yQIx7zVLw33e5yILCDcqTb1OqZ2
mm134cQfUOAckOoyNmzX3cuPyyPTDU+gtkpQ7mR4hAK5bKwOSzpUUylPSF+xwfE1
11Cd4jKmBQmF7kerKaAI3bRfPRMgjQKaeBrkkO4gsHgreFg4tRfFAERADix+yF1B
lldK2WMw0dkhDRRmhjY/mkEMeriL/OIeKNy7KCCaMuM76FskH+1ap77BKxvP3PmO
HXO859Ok7dTjVH8jGbIt
=vWPF
-----END PGP SIGNATURE-----



More information about the Dnsmasq-discuss mailing list