Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses when M flag is off
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patch applied, with a comment to explain the logging stuff. Cheers, Simon. On 19/04/15 22: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 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
Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses when M flag is off
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
Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses when M flag is off
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
Re: [Dnsmasq-discuss] Don't reply to requests for DHCPv6 addresses when M flag is off
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-
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
-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; +
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@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-
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
