dhclient -6 and IPv6 prefixes

Oskar Berggren oskar.berggren at gmail.com
Mon Sep 16 08:41:16 UTC 2013


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>

>  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]
> *Gesendet:* Montag, 2. September 2013 20:23
> *An:* Albrecht, Harald
> *Cc:* 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>****
>
> 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
> 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/34441c47/attachment-0001.html>


More information about the dhcp-hackers mailing list