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

Vladislav Grishenko themiron at mail.ru
Fri Apr 17 12:51:30 BST 2015


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/dnsmasq/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
> 
> -----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
> 
> iQIcBAEBCAAGBQJUwBPHAAoJEBXN2mrhkTWixUIQAJ1NTzBIPhnb6K2GgQU
> 63aWE
> nd/0UKGk+TFof0YDdFIU/njC6TIwYC+gZTFu2jKnUGy14d2f8EA/4iuTCDIJ2H3b
> hXHvKvZFv7nTmEpe/k7vj1owt+8ORtU7MTlJ0TA4pJ9hD8ySoF//IuaCX+jyXmp
> s
> txErXdToX87i7Ry+EFQwMNQwIPZUSggMuK0cjp+mkEgAdeqGJStT3EOJ6jl4eg
> 4d
> GLjz5SFDQfrz2FRcWbW05SqoaaTn1KlwwHxkkCxVXYuYaJ52z0hIIVjJsz6K8uxL
> VrVTDiJr93yUWGLZx71gd8Luj+hSJfO/dsyhOjqezKlb/TPyhowdCSPjzjEUihao
> wdHWV8DT8WHjYrqwaAO06zfi7kQbiw24vCtV4UxuW4HzS9etrgh7nMI6exUZ
> CztE
> dtsE7G7vMZKlof7A3wsZFm/tD3Ey14Ohvrrp0yQIx7zVLw33e5yILCDcqTb1OqZ2
> mm134cQfUOAckOoyNmzX3cuPyyPTDU+gtkpQ7mR4hAK5bKwOSzpUUylPSF
> +xwfE1
> 11Cd4jKmBQmF7kerKaAI3bRfPRMgjQKaeBrkkO4gsHgreFg4tRfFAERADix+yF1
> B
> lldK2WMw0dkhDRRmhjY/mkEMeriL/OIeKNy7KCCaMuM76FskH+1ap77BKxvP
> 3PmO
> HXO859Ok7dTjVH8jGbIt
> =vWPF
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Always-reply-to-DHCPv6-SOLICIT-with-Status-Code.patch
Type: application/octet-stream
Size: 2549 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150417/0fb2f08c/attachment.obj>


More information about the Dnsmasq-discuss mailing list