AW: dhclient -6 and IPv6 prefixes

[Albrecht, Harald]

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<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/8ed5d61f/attachment.html>