<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Hi,</div>
<div> </div>
<div>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”?</div>
<div><font face="Times New Roman"> </font></div>
<div>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).</div>
<div> </div>
<div>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} …”</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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?</div>
<div><font face="Times New Roman"> </font></div>
<div><font face="Arial" size="2"><span style="font-size:10pt;">With best regards,</span></font></div>
<div><font face="Arial" size="2"><span style="font-size:10pt;">Harald</span></font></div>
<div><font face="Arial" size="2"><span style="font-size:10pt;"> </span></font></div>
<div><font face="Times New Roman"> </font></div>
<div><font face="Arial" size="2"><span style="font-size:10pt;">Siemens AG<br>
Industry Sector<br>
Industry Automation Division<br>
Industrial Automation Systems<br>
I IA AS CTO DH 1<br>
Gleiwitzer Str. 555<br>
90475 Nürnberg, Deutschland<br>
<br>
<font size="1"><span style="font-size:8pt;">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 </span></font></span></font></div>
<div><font face="Times New Roman"> </font></div>
<div><font face="Times New Roman"> </font></div>
<div><font face="Times New Roman"> </font></div>
<div><font face="Times New Roman"> </font></div>
</span></font>
</body>
</html>