Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[Ole Troan <[e-mail]>]

Have you read RFC7421?
What problem are you trying to solve?

Ole


> On 17 Aug 2017, at 10:53, DY Kim <[e-mail]> wrote:
> 
> I’d hope I’m not bothering busy people too much, but let me recall the history as I remember:
> 
> o 128 bits decided for the IPv6 address length, part of which being prefix, part IID.
> 
> o The next question arose about how to configure the addresses.
> 
> o People noticed that 128 bits are large enough to hold the whole 802 MAC addresses.
> 
> o Soon, they also realized the length of the 802 MAC addresses are going to be extended to 64 bits.
> 
> o Each host interface would be associated with, typically, a 802 MAC, so it should be the most convenient choice to identify an interface.
> 
> o This then led to the possibility that the address can be auto-configured once the hosts are given subnet prefixes, i.e., 64-bit subnet prefix and 64-bit IID.
> 
> o The practice has been over 20 years.
> 
> o By now, IIDs are not to be configured with MAC addresses anymore, but with (hashed) random numbers to provide privacy.
> 
> o Hence, the historical link of the IID to the MAC address is now broken, and so its link to 64 bits. Apparently, IID is now free from 64 bits.
> 
> o And yet, people would now pick the fallen broken branch of 64 bits, and try to graft it back to the trunk IID.
> 
> o As the history started out 20 years ago, the IID would be the master and the 64-bit would be the slave. Now, the history is about to go upside down so that the roles are overturned; the 64-bit is now the master and the IID would be the slave.
> 
> This flow of history looks a bit funny to me, I’m afraid.
> 
> ---
> DY
> 
> 
>> On 17 Aug 2017, at 16:36, Ole Troan <[e-mail]> wrote:
>> 
>> That's not quite correct, at least not in a historical context.
>