Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis

[Philip Homburg <[e-mail]>]

>    On Mar 9, 2017, at 03:16, Philip Homburg
>    <[1][e-mail]> wrote:
> 
>    It seems to me that RFC 4291 uses the term interface identifier
>    for what are now two separate concepts.  The first interface
>    identifier concept is that for any prefix of length n, the length
>    of the interface identifier is 128-n. Let me call this prefix-iid.
>    The second iid concept is in auto configuration of addresses.
>    I'll call this slaac-iid.  The way I see i []
> 
>    I see it differently.
> 
>    Predecessors of I-D.ietf-6man-rfc4192bis going back to RFC 2373
>    have provided text in the Interface Identifiers subsection
>    defining the uniqueness properties of IIDs, and usage of that
>    term has always been clearly limited to the part of unicast
>    address following a subnet prefix. The part following any other
>    unicast routing prefix has always been unnamed and unstructured,
>    and its uniqueness properties are not those of an IID unless it
   is long enough to include the whole IID within it.

If your use of the term 'subnet prefix' only refers to (stateless) address
configuration and not to being onlink or not, then I agree about the
concept (but not the term).

However, where IPv6 clearly separates address configuration from being onlink,
calling a prefix that is only used for (stateless) address configuration
'a subnet prefix' is very confusing.

At the same time, calling some onlink prefixes 'subnet prefixes' and others
'other unicast routing prefixes' is also very confusing if they are
announced using the same L flag in a PIO option in a router advertisement.
I.e, whether or not the A flag is set in PIO option, should not have an effect
on what we call an onlink prefix. Or on how we describe onlink prefixes and
what their properties are.

Currently RFC 4291 says (and this is still in rfc4291bis-07):
"Interface identifiers in IPv6 unicast addresses are used to identify
"interfaces on a link.  They are required to be unique within a subnet prefix.

It doesn't say anything that the concept of interface identifier is only
related to stateless address configuration.

Only when we clearly separate address configuration from onlink prefixes
is there a chance that a new version of RFC 4291 will have easy to
understand concepts. And match the concepts used in the neighbor discovery
protocol.

So if we want to say that prefixes used for stateless address configuration
MUST/SHOULD be 64 bits long, whereas onlink prefixes can be of any length,
then we should at least use clear terminology that separates prefixes for
stateless address configuration from other uses. 

Certainly people who are used to the IPv4 use of the word 'subnet' may
not realize that in IPv6 addresses can be configured from a prefix but that
the prefix may not be onlink. 

So dropping the word subnet as much of possible and using terms like
(stateless) address configuration prefix and onlink prefix would make the
text a lot easier to read.