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

[David Farmer <[e-mail]>]

On Fri, Aug 4, 2017 at 3:43 PM, DY Kim <[e-mail]> wrote:

> 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?
>

Read Section 2.1 of RFC4291, multiple subnets per link in in the last
paragraph of that section.


> 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’.
>

There are lots of links with only one hosts, at least at some point in its
life cycle, are you saying that a subnet prefix isn't a subnet until the
second host shows up?

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          |
>    +-------------------------------+————————————————-----------------+
>

For a whole bunch of other reasons I'd be just fine with that suggestion, I
think the term subnet brings a who bunch of IPv4 baggage that is really
complicating other part of the RFC4291bis conversations. I'm all for
banishing the term subnet from RFC4291bis, except when comparing to an IPv4
subnet.


> > , 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.
>

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================