dhclient -6 and IPv6 prefixes

[Oskar Berggren]

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/20130902/20189ddd/attachment.html>