RE: draft-bourbaki-6man-classless-ipv6-00

["Manfredi, Albert E" <[e-mail]>]

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 

>> That should hardly be contentious, on technical grounds, because
>> the problem is not difficult to solve.
>
> Most problems can be solved as a "small matter of programming",
> but given that the deployed base of IPv6, which assumes /64 for
> SLAAC, is now much larger** than the whole Internet was when the
> /64 boundary was defined, I really don't think that is going to
> happen for any existing technology.

Since you mention in your footnote CIDR deployment with IPv4, which was also what came to mind to me, I think that this non-64-bit-IID SLAAC should be easier to introduce than CIDR was. For one thing, routers already know how to route variable length prefixes with IPv6. But either way, these changes can happen, with software updates, as they have happened in the past.

I see this IID-agnostic SLAAC as being limited to a local subnet issue, which a truly-not-difficult software update to the local hosts can solve. Prefix length agnostic SLAAC can be switched on in a very well controlled manner, by the router, when the net admin determines that the attached hosts are ready, or enough of them are ready. Until such a time, all upgraded hosts continue to work just fine, with 64-bit IIDs.

I largely agree with this draft, really. But, for example:

   IPv6 unicast interfaces may use any subnet length up to 128 except
   for situations where an Internet Standard document may impose a
   particular length, for example Stateless Address Autoconfiguration
   (SLAAC) [RFC4862],

I would say instead, even RFC 4862 can be modified, with minimal changes, to not impose such a restriction. That restriction was motivated by RFC 2464. The intent of RFC 2464 no longer applies. The rationale for a particular IID length, with IPv6 over Ethernet, IEEE 802.11, and most other link layers, therefore also no longer applies.

The recommendations of Section 4 are generally non-controversial (to me), although probably overly conservative.

>> It might be contentious only tangentially, in the sense that it
>> makes variable prefix lengths so easy to contend with?
>
> I don't understand that sentence.

Because SLAAC with variable IID lengths seems so straightforward to implement, I can only think that this is contentious because it makes moving that 64-bit boundary too easy? The boundary would be more difficult to change, if the only ways to do so required manual configuration of hosts.

Bert