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:si...@thekelleys.org.uk]
Sent: Monday, April 20, 2015 1:21 AM
To: Vladislav Grishenko; 'Win King Wan'
Cc: dnsmasq-discuss@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- boun...@lists.thekelleys.org.uk] On Behalf
Of Simon Kelley Sent: Thursday, January 22, 2015 2:02 AM
To: dnsmasq-discuss@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@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@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-----
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
