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

Steven Barth cyrus at openwrt.org
Mon Apr 20 03:17:49 BST 2015 

Well, the general issue here is that indication of M- and O-Flags in the 
RA is not a 100% clear indicator of what the DHCPv6 support on the link 
is. Especially in the ISP-case O in practice does also mean: do stateful 
DHCPv6, but only ask for IA_PD and not IA_NA. Since this is all so 
ambiguous having DHCPv6 servers send out NoAddrsAvail makes thing much 
easier to determine whether switching to Stateless makes sense or not. 
The silent treatment in general I think is bad.

In addition to that, I've tried to reproduce the original issue that the 
patch tried to solve (apparently some faulty Windows 8 behaviour) but 
could not neither with Windows 8 nor with Windows 10 so I considered it. 
Maybe there is a special precondition for that to happen (ICS being 
enabled?) but it wasn't indicated.

Thirdly my reading of RFC 3315 17.2.1. is such that a server is by 
administrative policy forbidden to talk to a certain class / group of 
clients by administrative choice i.e. is not supposed to talk to those 
clients at all not indicating there are clients which it should ignore 
Solicits from but react to Information-Requests.

So until further evidence is provided of what it does I consider this 
patch to be more harmful than useful, so I decided to revert it in OpenWrt.


Cheers,

Steven


On 19.04.2015 23:16, Vladislav Grishenko wrote:
> Simon, thanks
> As for reasons, I guess, Steven thought it departs from ordinal meaning of
> RFC and prevents his odhcp6c to work normally.
>
> p.s in my previous mail was a typo, RFC 2119, of course, not 2219. sorry
>
> Best Regards, Vladislav Grishenko
>
>> -----Original Message-----
>> From: Simon Kelley [mailto:simon at thekelleys.org.uk]
>> Sent: Monday, April 20, 2015 1:21 AM
>> To: Vladislav Grishenko; 'Win King Wan'
>> Cc: dnsmasq-discuss at lists.thekelleys.org.uk
>> Subject: Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6
> addresses
>> when M flag is off
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> My feeling is that this is a better solution, and I'm inclined to apply
> the patch.
>> Does anyone know what caused openWRT to revert the patc h?
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>> On 17/04/15 12:51, Vladislav Grishenko wrote:
>>> Hi,
>>>
>>> Per RFC 3315 17.2.1 the server MAY discard the Solicit message, but
>>> per 17.2.2, 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 client. Also, per RFC 2219 MAY is truly optional
>>> item, and MUST be prepared to interoperate with another inverse option
>>> existence implementation. So, interpreting that dnsmasq may not
>>> respond at all in stateless mode into RFC 3315
>>> 17.2.1 seems a bit farfetched.
>>>
>>> In real world, absence of Advertise message with NoAddrsAvail Status
>>> Code may lead to client misbehavior and prevent it from fallback to
>>> DHCPv6 Stateless mode, because RFC 3315 doesn't state any non-zero MRC
>>> & MRD non-zero values by default for Solicit messages transmission.
>>> Example of such client is https://github.com/sbyx/odhcp6c Also,
>>> openwrt has already reverted this change, refer
>>>
>> https://dev.openwrt.org/browser/trunk/package/network/services/dnsmas
>> q
>> /patch
>>>
>> es/200-fix-dhcpv6-solicit-handling.patch
>>> Since the original issue was in log flooding, log error only for
>>> non-stateless contexts and threat it as false-positive error if it's
>>> expected due the configuration. Please refer patch attached.
>>>
>>> Best Regards, Vladislav Grishenko
>>>
>>>> -----Original Message----- From: Dnsmasq-discuss
>>>> [mailto:dnsmasq-discuss- bounces at lists.thekelleys.org.uk] On Behalf
>>>> Of Simon Kelley Sent: Thursday, January 22, 2015 2:02 AM
>>>> To: dnsmasq-discuss at lists.thekelleys.org.uk Subject: Re:
>>>> [Dnsmasq-discuss] Don't reply to requests for DHCPv6
>>> addresses
>>>> when M flag is off
>>>>
>>> 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
>>>>>>
>>>>
>> _______________________________________________
>>>> 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 v2.0.22 (GNU/Linux)
>>
>> iEYEARECAAYFAlU0Dj8ACgkQKPyGmiibgrdE1ACeN88pbTgqJNkaJVCZs6jFKg+
>> D
>> TwEAmgOXxdPXbYQraMVtmQUcSgjjX/Kp
>> =q+SC
>> -----END PGP SIGNATURE-----

More information about the Dnsmasq-discuss mailing list