AW: dhclient -6 and IPv6 prefixes

Mon Sep 16 08:49:39 UTC 2013

Thanks Oskar, this clarifies the situation to me. So far I was under the (wrong) assumption that dhclient always uses dhclient-script, which isn’t the case when Network Manager is running. I’ve now noticed that Network Manager does run dhclient with nm-dhcp-client.action as its action script. And this also explains why I don’t see the wrong /64 prefix on my Kubuntu 13.04 installation but the /128 prefix instead, which is okay. So thanks again for explaining the situation!

-- Harald

Von: Oskar Berggren [mailto:oskar.berggren at gmail.com]
Gesendet: Montag, 16. September 2013 10:41
An: Albrecht, Harald
Cc: dhcp-hackers at lists.isc.org
Betreff: Re: dhclient -6 and IPv6 prefixes

Well... the ISC doesn't exactly live in the modern world of public bugtrackers and source code repositories, that we've come to expect from other open source projects.
Since some OS use network manager the bug gets reported there. I believe I read somewhere that someone had reported it to a isc dhcp mailing list, but I'm not sure. In the meantime, it's useful to have network manager simply ignore the flawed data coming from dhclient. Since there is no prefix length information transmitted by DHCPv6, the information from dhclient simply cannot come from the DHCP server anyway, and so therefore it's perfectly valid for network manager to ignore it, and use its own assumptions.
I _believe_ Network manager uses dhclient to handle the DHCP protocol, but then configures the system itself, without the dhclient-script.

So yes, if you don't use network manager, any other mechanism you use to apply the configuration to your system must deal with this to. In my understanding it would be perfectly valid for that mechanism to simply ignore the prefix from dhclient6 (and probably use a prefix length of 128).
But then, dhclient6 shouldn't emit a prefix length that is clearly wrong - it should probably not emit a prefix length at all, so IMHO there is still a bug there.

2013/9/16 Albrecht, Harald <harald.albrecht at siemens.com<mailto:harald.albrecht at siemens.com>>
Thanks for the pointers and confirming my suspicion. There is something in the big picture that I yet don’t understand, so please bear with me asking again:

1. You refer to bug reports related to Network Manager. However, isn’t this at least a bug in dhclient after all? For instance, if Network Manager isn’t present on a system, the usual dhclient-script runs and also causes prefixes to be added which shouldn’t . Is there a bug report for dhclient? I wasn’t able to find one, but I may have searched not thoroughly enough.

2. I’m not exactly clear of what happens when dhclient is used on a system where the Network Manager is installed: does dhclient-script still get called? Or is there a different mechanism used? How do dhclient and Network Manager communicate with each other?

Thank you for any light you can shed on this topic!

-- Harald

Von: Oskar Berggren [mailto:oskar.berggren at gmail.com<mailto:oskar.berggren at gmail.com>]
Gesendet: Montag, 2. September 2013 20:23
An: Albrecht, Harald
Cc: dhcp-hackers at lists.isc.org<mailto:dhcp-hackers at lists.isc.org>
Betreff: Re: dhclient -6 and IPv6 prefixes

Myself and others also think this is a bug:

Bug report in Debian against Network Manager trusting the false prefix from DHCP6 client:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661885
Upstream bug report for Network Manager, which have since worked around it by ignoring the prefix length from dhclient:
https://bugzilla.gnome.org/show_bug.cgi?id=656610
/Oskar

2013/9/2 Albrecht, Harald <harald.albrecht at siemens.com<mailto:harald.albrecht at siemens.com>>
Hi,

I’ve stumbled across some code in dhcp-4.2.5-P1 in client/dhc6.c related to IPv6 addresses and prefixes. I would like to clarify whether I’m totally wrong here or whether there is something not exactly 100% right with the current implementation of dhclient when run in IPv6 mode “-6”?

My understanding according to RFC 5942 (IPv6 Subnet Model) is that leasing an IPv6 address via DHCPv6 MUST NOT automatically constitute a corresponding on-link prefix. In order to make use of such a leased IPv6 address a default router on the same link as the node that leased the IPv6 address must be setup in such a way that it advertises a suitable on-link prefix (or even a suitable prefix which is not on-link but where the router is willing to route within this link for this not-on-link prefix).

Looking at client/dhc6.c, lines 3907 and following, there’s a note saying: “Current practice is that all subnets are /64’s, but some suspect this may not be permanent.” The code then goes on to establish a dhclient-script environment variable named “ipv6_prefixlen”. The dhclient-script, for instance, for Linux, then picks up the prefix length when it adds a leased IPv6 address using “ip -f inet6 addr add ${new_ip6_address}/${new_ip6_prefixlen} …”

This causes Linux not only to add the IPv6 address but also create a new route for an on-link prefix derived from the leased IPv6 address. However, RFC 5942 in section 5, Observed Incorrect Implementation Behavior explicitly marks this behavior as incorrect.

On another note, /64 prefixes are currently only required if (stateless) automatic address autoconfiguration is desired. There is nothing that denies using longer prefixes for special purposes where (SL)AAC is not required and smaller subnets than 64bits interface identifiers are desired. In fact, there are several RFCs detailing the advantages and disadvantages of operation when going for longer prefixes than /64.

So back to my original question: could it be that the current dhclient implementation isn’t exactly conforming to the RFCs? If yes, is there any intention to fix this behavior in collision with in particular RFC 5942?

With best regards,
Harald

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 Nürnberg, Deutschland

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

_______________________________________________
dhcp-hackers mailing list
dhcp-hackers at lists.isc.org<mailto:dhcp-hackers at lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-hackers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20130916/5d0400fc/attachment-0001.html>