Le 23/02/2017 à 06:58, Lorenzo Colitti a écrit :
On Thu, Feb 23, 2017 at 1:39 PM, Manfredi, Albert E
<albert(_dot_)e(_dot_)manfredi(_at_)boeing(_dot_)com
<mailto:albert(_dot_)e(_dot_)manfredi(_at_)boeing(_dot_)com>> wrote:
> Help he understand, then. There is widely-deployed code that assumes
> that the interface ID is 64 and does not work on anything other than
> 64 bit prefix lengths. Currently that code is correct on all unicast
> space. If you change RFC 4291, won't that code be incorrect?
This shows precisely why it is urgent to update RFC 4291, to correct
that notion of a fixed IID, before it's too late to set things
straight again.
Ok, so you're suggesting that we drop the attempt to reclassify RFC
4291, and instead write a new document to update it? That's a possible
course of action. It would only result in your desired outcome if there
was rough consensus to change the boundary, but as I said before, I'm
not going to oppose that course of action.
IPv6 unicast addresses are aggregatable with prefixes of arbitrary
bit-length, similar to IPv4 addresses under Classless Inter-Domain
Routing.
Important point. Arbitrary length. That does not mean 64 bits.
Nobody is disagreeing with that text. Please refer to the earlier
clarifications in this thread and the discussion in 6man that pointed
out that *routing* based on prefix lengths != 64 is independent from
*interface IDs* being required to be 64 bits long or not.
Please understand that routing based on prefix lenghts != 64 is
dependent on subnets with IIDs precisely of that prefix length.
It is an error to SLAAC/Ethernet/64 on a subnet to which only a /120 is
routed.
Alex