Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

[Simon Hobson <[e-mail]>]

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

> The problem I have is mainly that in the ebb and flow of these continuing discussions, one sees the "IIDs must be 64 bits wide" creeping back in, again and again. Where instead, the rough consensus seems to have become, must be 64-bits wide unless the addresses are statically configured or are provided by DHCPv6. In the latter cases, 64-bit IIDs might still be "recommended," but in fact, the on-link prefix length can be from zero to 128 bits, and the IID must therefore be 128 - prefix length.

I'd go further ...
While I've not been following the detail too closely, I get the feeling that SLAAC for global addressing BASED ON HARDWARE ADDRESS, and link local addresses, need 64 bits, nothing else actually does. On that basis, surely the better way to express it would be to say that in general there is no restriction as to where the prefix/id split falls - but some addressing methods have specific requirements. And in reality, link local addresses are pretty irrelevant in terms of how you manage other addresses as they have their own prefix and semantics.

If you say "it must be 64 bits except for X and Y" then if someone comes along in the future with a spiffing idea for method Z - then the whole merry go round of discussion starts up again getting "that changed to "... except for X and Y and Z".

Ie, unless there is some fundamental reason why the split MUST be at 64 bits, then simply say there isn't a requirements except where noted in the RFCs for the addressing methods that DO have a requirements for a specific length. IMO that's the cleaner way of expressing it.
If there are reasons why it's a good idea to use 64 bits - such as because there are implementations out there that make that assumption - then point them out (with a "for reasons of A, B, C is is recommended that ..." paragraph) rather than using them as a reason to maintain something that doesn't seem to make much sense now.



David Farmer <[e-mail]> wrote:

> IPv6 as currently defined does actually require IIDs to be 64 bits, if this wasn't the case then you could use subnets of any length without any special requirements or considerations. 

And so we come back to (what appears to me to be) the fundamental problem. At some point, for whatever reason, it was written that the split must be at 64 bits. Now it seems that in the general case there is no such requirement - but that CERTAIN ADDRESSING MODES/PROTOCOLS or IMPLEMENTATIONS require it to be at 64 bits.

So if the argument is that "we can't change 'something' because it clashes with 'something else'" - then isn't that an argument for 'correcting' the something else ?


> So, how about something like this;
> ...
> Oops, forgot something;
> 
> For the full functioning of all IPv6 capabilities, when assigning unicast addresses, except those that start with the binary value 000, Interface Identifiers are required to be 64 bits long. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. However, as IPv6 unicast routing and on-link determination are separate from address assignment and will operate with Interface Identifiers of any length. It is therefore possible, with several limitations, to use Interface Identifiers of other lengths in limited scenarios, these include; 128 bit prefixes, such as for router loopback addresses, point-to-point router-links [RFC6164], and links where all node are manually configured.

As it read the discussions, it's not so much a case of "in limited scenarios", but a case of "where an addressing mode requiring a specific IID length is not in use".

Al Albert writes, it seems that there's a desperation to hang on to 64 bits but allow some exceptions (and somehow imply that even when these exceptions apply, then it's a really really bad idea to depart from 64 bits - rather than simply drop the requirement and move it to where it actually applies (in the definition of those features/protocols that require it).



Just for completeness I'll add that my experience with IPv4 started more or less after classless addresses was the norm. In a parallel to the bit above about implementations having hardcoded assumptions, it came as "a surprise" to me when I came across a piece of equipment (an oldish serial terminal server) that refused to allow a /23 in the 192.168 RFC1918 range as it had hard-coded assumptions about address classes. That was the only time I came across such an issue - other than Cisco course content still stuck in classful mode even after the whole world set their routers to allow classless (and IP subnet zero) as the first step in configuring a router.