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] Adding Route Information Option to prefixes in RA
Focusing on the current dnsmasq code, I guess the take-home message here is that we're probably better off to revert the code which adds RIOs, for now, as the only RIOs we're sending are exactly the ones which Steven suggests should be suppressed. Should probably re-visit the issue of more general support for RIO in the next release. Possibly rare client issues aside if you announce a prefix both using an on-link PIO and a RIO the RIO doesn't do you any good. In the best case it just adds another redundant route for the same /64 in the worst case it confuses clients. My personal opinion would be to only send it if you announce the PIO as off-link (don't know if that is configurable in dnsmasq) and otherwise just drop the RIO if it would be identical to the PIO. I think it would make more sense to add some kind of option to specify the RIO-length for a prefix and only announce the RIO if said RIO length is than that of the prefix announced in the PIO or just add a generic option which let's you add arbitrary RIOs or so. Cheers, Steven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Adding Route Information Option to prefixes in RA
Hi Simon, just stumbled upon this and wanted to add some notes about that because I have some experience with RIOs from OpenWrt already. If you want to send RIOs because you want to be compliant with RFC 6204/7084 you should send them with the prefix that was delegated to the router running dnsmasq not the prefix that was actually assigned to the interface (i.e. if you get a /56 from the ISP you should announce the /56 as RIO and a /64 out of that as PIO to make it work). In addition and what is probably more critical here: some client implementations don't handle PIOs and RIOs for the same prefix very well (at least with the most-common prefix-size of /64 that is) and it might in some extreme cases even lead to disrupted connectivity between hosts. Since I had the fun to debug such a case and want to spare you the trouble you might want to have a look at this lengthy thread: https://dev.openwrt.org/ticket/17396 Cheers, Steven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Adding Route Information Option to prefixes in RA
Hi Ilya, please see the link to the OpenWrt ticket in my last mail which goes about what happens in detail. I don't remember if the user actually posted what OS the host ran on but it seemed to be some kind of server so probably something linux/unix? To summarize the issue since the ticket thread is a bit lengthy: The RIO and the PIO were identical let's say 2001:db8::/64 which lead to two routes being created in the host's routing table. One route saying 2001:db8::/64 is on-link (PIO) and one route saying 2001:db8::/64 is off-link and should be reached via the router sending the RA (RIO). Now the host in question preferred the off-link route over the on-link route so when it tried to send packages to an other host in 2001:db8::/64 it sent them to the router instead of doing neighbor discovery and sending it directly on-link. Now the router sending the RA in-turn disagreed about it being the one who should forward the package and replied with an ICMPv6-redirect saying: send directly to the other host, but it seems this redirect was ignored. Since this should only happen when RIO and PIO are both /64 (and on-link flag is set for the PIO) my work-around in OpenWrt was to simply not send the RIO when PIO and RIO would be identical which solved the problem for the user. Obviously if RIO and PIO have different sizes this shouldn't matter. As a side note: since afaik Windows is about the only system to support and enable RIOs by default and Linux kernel-defaults are to ignore RIOs with prefix-length != 0 and Apple not implementing RIO support at all we could get in more trouble once more platforms enable RIO-handling by default and maybe emitting the same behavior as this host. I didn't bother to search the RFCs for what is the correct behaviour in case identical RIOs and PIOs exist. Cheers, Steven ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Dnsmasq 2.44 refuses DNS-Queries from LAN clients
Hello, it looks like there is an issue with the latest 2.44 version of Dnsmasq. I recently upgraded the Dnsmasq on my router from 2.43 to 2.44 and it started to refuse DNS-Queries from PCs in the LAN. Downgrading to 2.43 made it work again. This is the output of host on a PC in the LAN: host -v kernel.org 192.168.2.1 Trying kernel.org Received 28 bytes from 192.168.2.1#53 in 14 ms Trying kernel.org Using domain server: Name: 192.168.2.1 Address: 192.168.2.1#53 Aliases: Host kernel.org not found: 5(REFUSED) Received 28 bytes from 192.168.2.1#53 in 12 ms The same request on the router running Dnsmasq itself worked flawlessly: root@OpenWrt:/# nslookup kernel.org 192.168.2.1 Server:192.168.2.1 Address 1: 192.168.2.1 Name: kernel.org Address 1: 204.152.191.5 pub1.kernel.org Address 2: 204.152.191.37 pub2.kernel.org Running dnsmasq -qd for debug purposes: the host-call produced the following output on the router: dnsmasq: query[A] kernel.org from 192.168.2.2 dnsmasq: query[A] kernel.org from 192.168.2.2 the nslookup-call: dnsmasq: query[PTR] 1.2.168.192.in-addr.arpa from 127.0.0.1 dnsmasq: query[PTR] 1.2.168.192.in-addr.arpa from 127.0.0.1 dnsmasq: query[PTR] 1.2.168.192.in-addr.arpa from 127.0.0.1 dnsmasq: query[] kernel.org from 127.0.0.1 dnsmasq: query[] kernel.org from 127.0.0.1 dnsmasq: query[] kernel.org from 127.0.0.1 This behaviour occured on both a Linksys WRT54GL (OpenWRT Kamikaze, MIPSel, Linux 2.4/uclibc) and a Netgear WGT634U (OpenWRT Kamikaze, MIPSel, Linux 2.6/uclibc). It seems that setting --min-port to anything from 1 to 65535 works around this but I think this is not expected behaviour. The following patches have been applied before building (after being refreshed): https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/trunk/package/dnsmasq/patches/101-ipv6.patch https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/trunk/package/dnsmasq/patches/102-rtnetlink.patch compile time options: IPv6 GNU-getopt ISC-leasefile no-DBus no-I18N TFTP Greetings Steven
