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

[DY Kim <[e-mail]>]

inline...

---
DY


> On 5 Aug 2017, at 03:15, David Farmer <[e-mail]> wrote:
> 
> Well, RFC4291 is quite clear there can be more than one subnet per link

Clear? Where?

Let’s assume what you say is correct and hence ‘link’ and ‘subnet’ are totally different things.

Hosts on a subnet acquire the subnet prefix from RA. All hosts on the same subnet gets the same common prefix; well eligible to be called ’subnet prefix’. Hosts generate interface addresses through SLAAC, by generating IID independently. That’s why we need DAD for no collision of the interface addresses, or equivalently, of the IIDs on the same subnet.

With the draft under discussion, however, each host gets a unique prefix, different from those of others. And hence, there’s no worry of address collision, so that DAD is not necessary in this case. What do we call then the prefix unique to each host in this case? Should we continue call that 'subnet prefix', with the consequence that we should then be dealing with multiple subnet prefixes for the same subnet?

I’d think that’s an odd naming, and the prefix unique to each host should best be called ‘host prefix’ or ‘node prefix’.

Now that neither ‘host prefix’ nor ‘node prefix’ is defined in rfc4291bis, wherein only the subnet prefix is defined, the current draft is using an address-related terminology not defined in the address architecture standard.

In this sense, the current draft could be said not to be compliant with the address architecture standard.

I’m not sure of the IETF culture, but terminology/nomenclature is ultimately important in dealing with standards.

I’m not at all against the draft under discussion. On the contrary, I like this draft very much.

To resolve the conflict, if any change has to take place, I’d think it should be with rfc 4291bis, very unfortunately. That is, this text in rfc4291bis

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+

might better be changed to

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |          prefix               |           interface ID          |
   +-------------------------------+————————————————-----------------+


> , there might be practical limits on how may subnet you can have on a link but there is no theoretical limit that I'm aware of.  Furthermore, Wifi or other link technology will probably reach congestion collapse before you reach such limits on a modern router.  While it is common for a router to have an address in the subnet this is not required, the host can just use the router's link-local address, and if the router is learned form RAs using the link-local address is the normal mode of operation anyway. Also, it's common for subnets to have more than one host again nothing requires this either.
> 
> So, this isn't what most people will think of when they read RFC4291, but your only running afoul of people's assumptions not the specification itself. Therefore, bring this up might be a good idea for RFC4291bis, principle of least astonishment and all, but not absolutely necessary.