Re: [v6ops] Chair decision on WGLC for draft-ietf-v6ops-dhcp-pd-per-device-04

[Brian E Carpenter <[e-mail]>]

Hi Owen,

> So, in fact, the point of having 128 bit addresses (at least in the initial engineering of same) was, in fact, to use the lower 64 bits as IID and leave the upper 64 bits for locator/network ID.

Not quite. The original expectation was to leave the upper 80 bits for routing and have a 48 bit IID. We only moved from /80 to /64 because we were effectively copying the XNS/Netware model and there was a theory that 64-bit Firewire MAC addresses would take over the universe.

draft-odell-8+8-00.txt (October 1996) did propose a rigid /64 boundary.

Regards
    Brian Carpenter

On 02-Nov-23 10:44, Delong.com wrote:
> 
> 
>> On Nov 1, 2023, at 12:05, Lorenzo Colitti <lorenzo=[e-mail]> wrote:
>>
>> On Wed, Nov 1, 2023 at 5:28 PM Gert Doering <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     The point of having 128 bit is not to throw half of it away.
>>
>>
>> Maybe we should start working on running SLAAC on IIDs shorter than 64 bits then?
> 
> Or maybe not…
> 
> ISTR that the early discussion was for a 64-bit address space up to the point where someone pointed out the utility of 64-bit IIDs in an EUI-64 world (which was, at the time, expected for future IEEE802 work and had
> already hit a couple of media types such as FDDI (yes, FDDI meant something back then)).
> 
> So, in fact, the point of having 128 bit addresses (at least in the initial engineering of same) was, in fact, to use the lower 64 bits as IID and leave the upper 64 bits for locator/network ID.

Not quite. The original expectation was to leave the upper 80 bits for routing and have a 48 bit IID. We only moved from /80 to /64 because we were effectively copying the XNS/Netware model and there was a theory that 64-bit Firewire MAC addresses would take over the universe.

draft-odell-8+8-00.txt (October 1996) did propose a rigid /64 boundary.
  
> I’m sure opinions vary on this today, but is there a genuine belief that we need more than 2 quintillion subnets? (An admittedly rough approximation of 2^61 which is the number of /64s available in 2000::/3).

No. The argument is different: route aggregation must be possible at all levels.
  
> Unless there’s some compelling reason that’s necessary, I remain unconvinced that killing the /64 concept is such a good idea.

That isn't the goal. The goal is to ensure that *architecturally* all our specifications allow for route aggregation at all levels; /64 is just a setting. And as we know, mobile operators have turned /64 into an axiom, which is quite wrong architecturally. But its direct consequence is that we *will* need longer prefixes downstream from this /64 bottleneck. Or NPTv6/NAT66.

draft-bourbaki-6man-classless-ipv6 says more.

(The authors of rfc6296-bis might consider whether NPTv6 will also work for prefixes as long as /80. I think so, there is still space for the checksum-neutral computation.)

    Brian