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

From: james woodyatt <[email-masked]>
Date: Thu, 9 Mar 2017 00:19:21 -0800

Hi Everyone,

This message includes my proposal to provide further clarity in the successor to RFC 4291 on recent questions related to the length of interface identifiers and consequently to the length of subnet prefixes and their relationship to the validity of on-link prefix determination.

I see two possible alternatives for consideration.

1. In the “conservative” alternative, interface identifiers are required to have a standard length according to the type of link, and 64 bits is the recommended length for use in future standards, citing RFC 7421. I believe this to be consistent with what RFC 4291 says today, but also at variance with what many participants would prefer and not fully consistent with what some people also say is the letter and spirit of RFC 4861 and RFC 4862 (including the authors of those documents).

2. In the “liberal” alternative, the length of interface identifiers is unspecified, and 64 bits is the RECOMMENDED length, citing RFC 7421. I believe this to be a significant technical change to the current requirements set by RFC 4291, with additional complications that need to be described and understood, but it would be more in keeping with the letter and spirit of RFC 4861 (but not entirely with RFC 4862) and I believe more preferable to the participants who object to the current draft (and likely my conservative alternative too).

3. In both alternatives, I’ve proposed a new subsection to describe briefly the concept of neighbor discovery, to discuss the distinction (from RFC 5942) between subnet prefixes and on-link prefixes and their relationships to interface identifiers. I think this will help clear up the ambiguity that I discussed previously at length in a recent message to the working group.

For the record, I’m still very much in favor of my proposed “conservative" alternative, but I provide the “liberal" alternative as well in the hope of offering some constructive improvement over the current draft despite my reservations about choosing that alternative.

Here are both sets of my proposed changes.

— Update to §2.1 Addressing Model

Current:
> Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link.

Proposed (liberal and conservative):
> The relationship between links and IPv6 subnet prefixes is not the same as in the IPv4 model. As explained in The IPv6 Subnet Model [RFC5942], the most important differences are that multiple subnet prefixes may be assigned to the same link, and that unicast addresses are not automatically associated with an on-link prefix.

Reasoning: RFC 5942 is Proposed Standard and without errata. Its abstract explicitly says that IPv6 diverges from the IPv4 subnet model rather than continuing it. This correction reflects the truth of that. This change would also add an informative reference to RFC 5942.

— Update to §2.2.2 Text Representation of Address Prefixes

Current:
> When writing both a node address and a prefix of that node address (e.g., the node's subnet prefix), the two can be combined as follows:
> 
>       the node address        2001:0db8:0:cd30:123:4567:89ab:cdef
>       and its subnet number   2001:0db8:0:cd30::/60

Proposed (liberal and conservative):
> When writing both a node address and a prefix of that node address, the two can be combined as follows:
> 
>       the node address        2001:0db8:0:cd30:123:4567:89ab:cdef
>       and its prefix          2001:0db8:0:cd30::/60

Reasoning: eliding the example of “subnet prefix” here avoids the suggestion that link types have already been defined (at the time of publication) for which 68 bits is a valid length for interface identifiers.

— Update to §2.4 Unicast Addresses

Current:
> IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on inter-router point-to-point links. However, the Interface ID of all unicast addresses, except those that start with the binary value 000, is required to be 64 bits long.  The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421]

Proposed (liberal and conservative):
> IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on inter-router point-to-point links.

Reasoning: In the current text, the sentence beginning with “However,” uses the phrase “Interface ID” before it is adequately defined (along with the concept of the subnet prefix) in the subsequent text. (See below, where the elided language in this paragraph is restored in the conservative alternative.)

Current:
> A slightly sophisticated host (but still rather simple) may additionally be aware of subnet prefix(es) for the link(s) it is attached to, where different addresses may have different values for n:
> 
>    |          n bits               |           128-n bits            |
>    +-------------------------------+---------------------------------+
>    |       subnet prefix           |           interface ID          |
>    +-------------------------------+---------------------------------+

Proposed (conservative):
> A slightly sophisticated node (e.g. one capable of neighbor discovery) may additionally be aware of subnet prefix(es) for the link(s) to which it attaches, where the length (n) of the interface ID field may vary with different types of link:
> 
>    |       128-n bits              |           n bits                |
>    +-------------------------------+---------------------------------+
>    |       subnet prefix           |           interface ID          |
>    +-------------------------------+---------------------------------+
> 
> Note: according to the reasoning presented in Analysis of the 64-bit Boundary in IPv6 Addressing [RFC7421], the length of the Interface ID field in all unicast IPv6 addresses is 64 bits, except for addresses beginning with binary value 000 and except in cases where otherwise specified in future IETF standard actions.

Reasoning: this (conservative) change clarifies that interface identifiers have a length that is a function of the link type, which defines the length of the interface identifier, which is a constant for all links of that type. And it cites RFC 7421 to explain why 64 bits is required for most interface identifiers. And it replaces “host” with “node” in one case where that’s more accurate.

Proposed (liberal):
> A slightly sophisticated node (e.g. capable of neighbor discovery) may additionally be aware of subnet prefix(es) for the link(s) to which it attaches, where the length (n) of the interface ID field may vary for each subnet prefix:
> 
>    |       128-n bits              |           n bits                |
>    +-------------------------------+---------------------------------+
>    |       subnet prefix           |           interface ID          |
>    +-------------------------------+---------------------------------+
> 
> Note: according to the reasoning presented in Analysis of the 64-bit Boundary in IPv6 Addressing [RFC7421], interface identifiers are recommended to be 64 bits in length.

Reasoning: this (liberal) change relaxes the requirement that interface identifiers have any fixed length, citing RFC 7421 to recommend 64 bits (but not require it). And it replaces “host” with “node” in one case where that’s more accurate.

— Update to §2.4.1 Interface Identifiers

Current:
> 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 is recommended that the same interface identifier not be assigned to different nodes on a link. They may also be unique over a broader scope. The same interface identifier may be used on multiple interfaces on a single node, as long as they are attached to different subnets.

Proposed (conservative):
> Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be of a standard length for the type of the link and unique among all the nodes on the link using the same subnet prefix. It is recommended that the same interface identifier not be assigned to different nodes on the same link. They may also be unique over a broader scope. The same interface identifier may be used on multiple interfaces on a single node, as long as they are used with different subnet prefixes.

Reasoning: this (conservative) change improves clarity by ensuring the term “subnet” is always used in the phrase “subnet prefix” and not as a shorthand for a subset of the nodes on a link using addresses that share the same subnet prefix. It also clarifies that standards dictate the valid length(s) of interface identifiers for each link type.

Proposed (liberal):
> Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique among all the nodes on the link using the same subnet prefix. It is recommended that the same interface identifier not be assigned to different nodes on a link. They may also be unique over a broader scope. The same interface identifier may be used on multiple interfaces on a single node, as long as they are used with different subnet prefixes.

Reasoning: this (liberal) change only improves clarity by ensuring the term “subnet” is always used in the phrase “subnet prefix” and not as a shorthand for a subset of the nodes on a link using addresses that share the same subnet prefix. It leaves open the variable length of interface identifiers.

— Update to §2.4.4 Global Unicast Addresses

Current:
> The general format for IPv6 Global Unicast addresses is as follows:
> 
>    |         n bits         |   m bits  |       128-n-m bits         |
>    +------------------------+-----------+----------------------------+
>    | global routing prefix  | subnet ID |       interface ID         |
>    +------------------------+-----------+----------------------------+
> 
> where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnets/links), the subnet ID is an identifier of a link within the site, and the interface ID is as defined in Section 2.4.1.
> 
> As noted in Section 2.4, all Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.4.1. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
> 
> Examples of Global Unicast addresses that start with binary 000 are the IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An example of global addresses starting with a binary value other than 000 (and therefore having a 64-bit interface ID field) can be found in [RFC3587].

Proposed (conservative):
> The general format for IPv6 Global Unicast addresses is as follows:
> 
>    |     128-n-m bits       |   m bits  |       n bits               |
>    +------------------------+-----------+----------------------------+
>    | global routing prefix  | subnet ID |       interface ID         |
>    +------------------------+-----------+----------------------------+
> 
> where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnet prefixes assigned to links), the subnet ID is an identifier of a link within the site, and the interface ID is as defined in Section 2.4.1.
> 
> As noted in Section 2.4, all Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n = 64), formatted as described in Section 2.4.1. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
> 
> Examples of Global Unicast addresses that start with binary 000 are the IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An example of global addresses starting with a binary value other than 000 (and therefore having a 64-bit interface ID field) can be found in [RFC3587].

Reasoning: the only changes here are to make the field headings in the structure diagram consistent with those proposed for the similar diagram in §2.4, to use “subnet” only in the phrase “subnet prefix” and not as cognate of link, and to update the explanatory parenthetical in the second paragraph, “(i.e. n = 64)”, to reflect it accordingly. 

Proposed (liberal):
> The general format for IPv6 Global Unicast addresses is as follows:
> 
>    |     128-n-m bits       |   m bits  |       n bits               |
>    +------------------------+-----------+----------------------------+
>    | global routing prefix  | subnet ID |       interface ID         |
>    +------------------------+-----------+----------------------------+
> 
> where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnet prefixes assigned to links), the subnet ID is an identifier of a link within the site, and the interface ID is as defined in Section 2.4.1.

Reasoning: the field headings in the structure diagram are made consistent with those for the similar diagram in §2.4, and the two final paragraphs about addresses that start with binary 000 are elided in accordance with the proposed (liberal) change to §2.4. Also, the word “subnet” is used properly in the phrase “subnet prefix” where it is more clearly defined.

— Insertion of §2.4.8 Neighbor Discovery

Proposed (conservative):
> Nodes can send packets directly to other nodes with interfaces on the same link, without forwarding by a router, when they can identify the link-layer addresses associated with the unicast IPv6 addresses that share on-link subnet prefixes assigned to the interface. Neighbor discovery is conceptually the process of resolving such associations as necessary.
> 
> Nodes may be configured manually with on-link subnet prefixes for each of their interfaces. Also, routers may inform hosts automatically of the set of on-link subnet prefixes by a process related to neighbor discovery. Nodes sending packets to unicast addresses with subnet prefixes that are not on-link must direct those packets to a router for forwarding to their destination.
> 
> Every on-link prefix is a subnet prefix, and subnet prefixes for all global unicast addresses beginning with a binary value other than 000 are required according to Section 2.4 to be 64 bits in length.

Reasoning: this text provides clarification that on-link prefixes are subnet prefixes for which neighbor discovery can be used by nodes to communicate directly without forwarding packets through a router. It also repeats the requirement that all subnet prefixes other than those beginning with 0b000 are 64 bits long.

Proposed (liberal):
> Nodes can send packets directly to other nodes with interfaces on the same link, without forwarding by a router, when they can identify the link-layer addresses associated with the unicast IPv6 addresses that share on-link prefixes assigned to the interface. Neighbor discovery is conceptually the process of resolving such associations as necessary.

> 
> Nodes may be configured manually with on-link prefixes for each of their interfaces. Also, routers may inform hosts automatically of the set of on-link prefixes by a process related to neighbor discovery. Nodes sending packets to unicast addresses without an on-link prefix must direct those packets to a router for forwarding to their destination.
> 
> An important distinction is made between subnet prefixes, which are defined in Section 2.4 as the part of a unicast address that precedes the interface identifier, and on-link prefixes which do not necessarily have structure in the part of unicast addresses that follows them. In particular, an on-link prefix may be shorter than the one or more subnet prefixes that share it, in which case the part that follows the on-link prefix consists of some additional bits that precede the interface identifier. Likewise, an on-link prefix may be longer than a subnet prefix it shares with one or more other on-link prefixes, in which case the part that follows the on-link prefix is only a portion of an interface identifier and hence may not itself necessarily have all the properties of an interface identifier as defined in Section 2.4.1, therefore it must not be used alone, in that case, to identify an interface on a link.

Reasoning: this text is similar to the text in the conservative alternative except that it does not assert that every on-link prefix is a subnet prefix or specify any requirement for the length of either on-link or subnet prefixes. However, it does include an additional paragraph that discusses the necessary distinction between on-link and subnet prefixes in substantial detail, and it forbids the use of the part of a unicast address following an on-link prefix as identification for an interface on a link unless it is sufficiently long to meet the requirements of §2.4.

— Update to §2.5 Anycast Addresses

Current:
> Some other possible uses are to identify the set of routers attached to a particular subnet, or the set of routers providing entry into a particular routing domain.

Proposed (liberal and conservative):
> Some other possible uses are to identify the set of routers attached to a link for use by nodes at addresses sharing a particular subnet prefix, or to identify the set of routers providing entry into a particular routing domain.

Reasoning: this change improves clarity by ensuring the term “subnet” is always used in the phrase “subnet prefix” and not as a shorthand for a subset of the nodes on a link using addresses that share the same subnet prefix.

— Update to §2.5.1 Required Anycast Address

Current:
> 2.5.1.  Required Anycast Address
> 

> The Subnet-Router anycast address is predefined. Its format is as follows:
> 
>    |                         n bits                 |   128-n bits   |
>    +------------------------------------------------+----------------+
>    |                   subnet prefix                | 00000000000000 |
>    +------------------------------------------------+----------------+
> 
> The "subnet prefix" in an anycast address is the prefix that identifies a specific link. This anycast address is syntactically the same as a unicast address for an interface on the link with the interface identifier set to zero.
> 
> Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces.

Proposed (liberal and conservative):
> 2.5.1.  Subnet-Router Anycast Address
> 
> The Subnet-Router anycast address is predefined for each subnet prefix. Its structure, as shown below, is the same as a unicast address with the same subnet prefix and with zero for the interface identifier.
> 
>    |                      128-n bits                |   n bits       |
>    +------------------------------------------------+----------------+
>    |                   subnet prefix                | 00000000000000 |
>    +------------------------------------------------+----------------+
> 
> Packets sent to the Subnet-Router anycast address are destined for any router on the link that is assigned a unicast address with the corresponding subnet prefix. All routers are required to assign Subnet-Router anycast addresses to their interfaces for each subnet prefix used on the link.

Reasoning: this change (which is essentially a complete rewrite of §2.5.1) improves clarity by making the field headers in the structure diagram consistent with §2.4, and by ensuring the term “subnet” is always used in the phrase “subnet prefix” and not as a shorthand for a subset of the nodes on a link using addresses that share the same subnet prefix.

Commentary: it’s not clear to me what is the real purpose of the Subnet-Router anycast address, even in the conservative case, but especially so in the liberal case where on-link prefixes are not required to have the same length as subnet prefixes. It seems okay that a single Subnet-Router anycast address should be defined as the destination for any router with an address where more than one on-link prefix has a shorter subnet prefix in common. It seems much less okay that multiple Subnet-Router anycast addresses should be defined as destinations for any router with addresses having more than one subnet prefix sharing a common on-link prefix. Still, I don’t see how it breaks anything important, so I'm saying: let's try not to do any further damage.

——

In summary, I believe when publishing the successor to RFC 4291 it may be possible for IETF to further clarify the IPv6 address architecture so that controversies over the validity of on-link prefixes used in neighbor discovery do not arise, either A) in the conservative case, because all on-link prefixes are also subnet prefixes and subnet prefixes are constrained to standard size(s) for each link type and to 64 bits for all prefixes beginning with 0b000, or B) in the liberal case, because neither on-link prefixes nor subnet prefixes are constrained to any standard size nor even required to be the same length.

I hope this proposal will be seen correctly as my sincere attempt to provide a constructive basis for resolving this ongoing controversy into a rough consensus.

--james woodyatt <[email-masked]>

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Mar 2017 12:16:59 +0100

> 1. In the conservative alternative, interface identifiers are
> required to have a standard length according to the type of link,
> and 64 bits is the recommended length for use in future standards,
> citing RFC 7421. I believe this to be consistent with what RFC 4291
> says today, but also at variance with what many participants would
> prefer and not fully consistent with what some people also say is
> the letter and spirit of RFC 4861 and RFC 4862 (including the
> authors of those documents).
> 
> 2. In the liberal alternative, the length of interface identifiers
> is unspecified, and 64 bits is the RECOMMENDED length, citing RFC
> 7421. I believe this to be a significant technical change to the
> current requirements set by RFC 4291, with additional complications
> that need to be described and understood, but it would be more in
> keeping with the letter and spirit of RFC 4861 (but not entirely
> with RFC 4862) and I believe more preferable to the participants
> who object to the current draft (and likely my conservative
> alternative too).

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 it, any slaac-iid that is based on (pseudo)-random number 
has to be at least 64 bits. I don't see any reason for more than 64 so
exactly 64 sounds about right.

In theory, a link that has hardware MAC addresses with less than 64 bits
could define a slaac-iid that is shorter, however that precludes the use of
pseudo-random slaac-iids. So that doesn't make a lot of sense. Though we
could leave room for a future IPv6-over-foo document to do just that.

Simply put, a slaac-iid should be 64 bits.

For prefix-iids the situation is completely different. A /127 on p2p links is
standard. Various long prefixes are used in practice. There really is no
reason why a node would care about the length of an onlink prefix.
So basically, a node just has to support onlink prefixes of any length.

Note that onlink prefixes are not tied to a particular link type.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Mar 2017 15:02:39 +0100

Hi,

I will read in detail the proposal later, but for now I would like to 
point out one thing in particular that pops up every time I read this 
4291 text.

Le 09/03/2017 à 09:19, james woodyatt a écrit :
[...]

>> Note: according to the reasoning presented in Analysis of the 64-bit Boundary in IPv6 Addressing [RFC7421], the length of the Interface ID field in all unicast IPv6 addresses is 64 bits, except fo…

That 'subnet prefix' looks very much like a 64bit-or-so subnet.

[...]
>>    |         n bits         |   m bits  |       128-n-m bits         |

This 'subnet ID' looks like something shorter than a 64bit-or-so length.

I think we should be consistent in the use of this subnet word.

Alex
[...]

---

From: David Farmer <[email-masked]>
Date: Thu, 9 Mar 2017 08:27:15 -0600

James,

I think both versions of the proposal significantly clarify RFC4291bis.
Thank you.

They both include a reference to RFC6164, however the conservative version
seem to go on to deny the possibility of a /127 on-link prefix.  Whereas,
the liberal version seems to go on to explain that when following RFC6164
you have a 64bit IID and a /127 on-link prefix, which seems consistent with
the details of RFC6164.  In fact I would like to recommend that a /127
point-to-point ethernet type link be used to as an example to help clarify
your on-link prefix and ND discussion in the liberal version of §2.4.8.

I think the liberal version should also clearly recommend the use of /64
on-link prefixes, while permitting on-link prefixes of any length, as it
does already. I'd even go as far as saying on-link prefixes are normally
/64. I feel on-link prefixes other than /64 are special cases, that have to
be allowed, but are not to be used lightly and are probably not for general
purpose use.  So, I'd be fine with strong caveats on the use of on-link
prefixes other than /64, especially with links that have nodes using SLAAC.
I'd even be open to a compromise between the conservative and liberal
versions, such that SLAAC, ("A" flag set in an RA) requires /64 on-link
prefixes.

The conservative version of the proposal at least needs to be adjusted to
allow for RFC6164 /127 point-to-point router links as an exception to
on-link prefixes always being /64, there seems to be a conflict here
in the conservative
version.

I suspect it comes as no surprise, I like the liberal version of the
proposal.  It seems to be consistent with both /64 for SLAAC and allowing
manual configuration of any on-link prefix length.  It's mute on the issue
of DHCPv6, I'm fine with that.  But it clearly implies that DHCPv6 would
use the on-link prefixes from the provided RAs. Further, the liberal
version provides real meaning to the statement "IPv6 unicast routing is
based on prefixes of any valid length up to 128 [BCP198]." in that on-link
prefixes are allow to be any length.  Where as the conservative version,
still seems to be classful, at lest to me.

While the liberal proposal, maybe with tweaks I suggest above, seems to
successfully deal with the primary issues of controversy, at least in my
opinion, there are also a few secondary issues that have come up in the
discussion that I'd like to also see resolved too;

1. I think a statement about and a reference to RFC7934/BCP204 should be
added to §2.1, this would be a strong addition supporting and clarifying
the architectural intent of multiple addresses in IPv6.

2. I think §2.4.4 needs a more direct reference to RFC6177/BCP157, right
now you get there indirectly via RFC3587 to RFC3177 which is obsoleted by
6177.  The concept that a site is more than one link or subnet, and
therefore a site usually need more than one /64, is an important
architectural concept to convey.  Especially, if you think subnet and
on-link prefixes are always /64.

3. I think adding the concept that sites are not just fixed locations, but
could be mobile, is also an important architectural clarification. This is
extremely important in the world of 2017. This seem to best fit in §2.4.4 where
a site is defined.

4. RFC4291bis, seem to imply the primary purpose of the exception to 64-bit
IIDs for addresses that begin with binary 000 is primarily related to IPv6
address with embedded IPv4 addresses, and historically NSAP, IPX, etc...
So, therefore it seems there should be a similar exception when using
RFC6052, and its IPv6 addresses with IPv4 addresses embedded anywhere in
global unicast, at least for the /96 option in [RFC6052].

5. Further it seems that §2.4.5 should have a pointer to [RFC6052] as
additional IPv6 addresses with embedded IPv4 addresses.

 Again, thank you.

On Thu, Mar 9, 2017 at 2:19 AM, james woodyatt <[email-masked]> wrote:

> Hi Everyone,
>
> This message includes my proposal to provide further clarity in the
> successor to RFC 4291 on recent questions related to the length of
> interface identifiers and consequently to the length of subnet prefixes and
> their relationship to the validity of on-link prefix determination.
>
> 1. In the “conservative” alternative, interface identifiers are required
> to have a standard length according to the type of link, and 64 bits is the
> recommended length for use in future standards, citing RFC 7421. I believe
> this to be consistent with what RFC 4291 says today, but also at variance
> with what many participants would prefer and not fully consistent with what
> some people also say is the letter and spirit of RFC 4861 and RFC 4862
> (including the authors of those documents).
>
> 2. In the “liberal” alternative, the length of interface identifiers is
> unspecified, and 64 bits is the RECOMMENDED length, citing RFC 7421. I
> believe this to be a significant technical change to the current
> requirements set by RFC 4291, with additional complications that need to be
> described and understood, but it would be more in keeping with the letter
> and spirit of RFC 4861 (but not entirely with RFC 4862) and I believe more
> preferable to the participants who object to the current draft (and likely
> my conservative alternative too).
>
> 3. In both alternatives, I’ve proposed a new subsection to describe
> briefly the concept of neighbor discovery, to discuss the distinction (from
> RFC 5942) between subnet prefixes and on-link prefixes and their
> relationships to interface identifiers. I think this will help clear up the
> ambiguity that I discussed previously at length in a recent message to the
> working group.
>
> For the record, I’m still very much in favor of my proposed “conservative"
> alternative, but I provide the “liberal" alternative as well in the hope of
> offering some constructive improvement over the current draft despite my
> reservations about choosing that alternative.
>
> > Currently, IPv6 continues the IPv4 model in that a subnet prefix is
> associated with one link. Multiple subnet prefixes may be assigned to the
> same link.
>
> > The relationship between links and IPv6 subnet prefixes is not the same
> as in the IPv4 model. As explained in The IPv6 Subnet Model [RFC5942], the
> most important differences are that multiple subnet prefixes may be
> assigned to the same link, and that unicast addresses are not automatically
> associated with an on-link prefix.
>
>
> Reasoning: RFC 5942 is Proposed Standard and without errata. Its abstract
> explicitly says that IPv6 diverges from the IPv4 subnet model rather than
> continuing it. This correction reflects the truth of that. This change
> would also add an informative reference to RFC 5942.
>
> > When writing both a node address and a prefix of that node address
> (e.g., the node's subnet prefix), the two can be combined as follows:
> >
> Reasoning: eliding the example of “subnet prefix” here avoids the
> suggestion that link types have already been defined (at the time of
> publication) for which 68 bits is a valid length for interface identifiers.
>
> > IPv6 unicast routing is based on prefixes of any valid length up to 128
> [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on
> inter-router point-to-point links. However, the Interface ID of all unicast
> addresses, except those that start with the binary value 000, is required
> to be 64 bits long.  The rationale for the 64 bit boundary in IPv6
> addresses can be found in [RFC7421]
>
> > IPv6 unicast routing is based on prefixes of any valid length up to 128
> [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on
> inter-router point-to-point links.
>
> Reasoning: In the current text, the sentence beginning with “However,”
> uses the phrase “Interface ID” before it is adequately defined (along with
> the concept of the subnet prefix) in the subsequent text. (See below, where
> the elided language in this paragraph is restored in the conservative
> alternative.)
>
> Current:
> > A slightly sophisticated host (but still rather simple) may additionally
> be aware of subnet prefix(es) for the link(s) it is attached to, where
> different addresses may have different values for n:
> >
> >    |          n bits               |           128-n bits            |
> > A slightly sophisticated node (e.g. one capable of neighbor discovery)
> may additionally be aware of subnet prefix(es) for the link(s) to which it
> attaches, where the length (n) of the interface ID field may vary with
> different types of link:
> >
> >    |       128-n bits              |           n bits                |
> > Note: according to the reasoning presented in Analysis of the 64-bit
> Boundary in IPv6 Addressing [RFC7421], the length of the Interface ID field
> in all unicast IPv6 addresses is 64 bits, except for addresses beginning
> with binary value 000 and except in cases where otherwise specified in
> future IETF standard actions.
>
> Reasoning: this (conservative) change clarifies that interface identifiers
> have a length that is a function of the link type, which defines the length
> of the interface identifier, which is a constant for all links of that
> type. And it cites RFC 7421 to explain why 64 bits is required for most
> interface identifiers. And it replaces “host” with “node” in one case where
> that’s more accurate.
>
> Proposed (liberal):
> > A slightly sophisticated node (e.g. capable of neighbor discovery) may
> additionally be aware of subnet prefix(es) for the link(s) to which it
> attaches, where the length (n) of the interface ID field may vary for each
> subnet prefix:
> >
> >    |       128-n bits              |           n bits                |
> > Note: according to the reasoning presented in Analysis of the 64-bit
> Boundary in IPv6 Addressing [RFC7421], interface identifiers are
> recommended to be 64 bits in length.
>
> Reasoning: this (liberal) change relaxes the requirement that interface
> identifiers have any fixed length, citing RFC 7421 to recommend 64 bits
> (but not require it). And it replaces “host” with “node” in one case where
> that’s more accurate.
>
> > 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 is recommended that the same interface identifier not be
> assigned to different nodes on a link. They may also be unique over a
> broader scope. The same interface identifier may be used on multiple
> interfaces on a single node, as long as they are attached to different
> subnets.
>
> Proposed (conservative):
> > Interface identifiers in IPv6 unicast addresses are used to identify
> interfaces on a link. They are required to be of a standard length for the
> type of the link and unique among all the nodes on the link using the same
> subnet prefix. It is recommended that the same interface identifier not be
> assigned to different nodes on the same link. They may also be unique over
> a broader scope. The same interface identifier may be used on multiple
> interfaces on a single node, as long as they are used with different subnet
> prefixes.
>
> Reasoning: this (conservative) change improves clarity by ensuring the
> term “subnet” is always used in the phrase “subnet prefix” and not as a
> shorthand for a subset of the nodes on a link using addresses that share
> the same subnet prefix. It also clarifies that standards dictate the valid
> length(s) of interface identifiers for each link type.
>
> Proposed (liberal):
> > Interface identifiers in IPv6 unicast addresses are used to identify
> interfaces on a link. They are required to be unique among all the nodes on
> the link using the same subnet prefix. It is recommended that the same
> interface identifier not be assigned to different nodes on a link. They may
> also be unique over a broader scope. The same interface identifier may be
> used on multiple interfaces on a single node, as long as they are used with
> different subnet prefixes.
>
> Reasoning: this (liberal) change only improves clarity by ensuring the
> term “subnet” is always used in the phrase “subnet prefix” and not as a
> shorthand for a subset of the nodes on a link using addresses that share
> the same subnet prefix. It leaves open the variable length of interface
> identifiers.
>
> > where the global routing prefix is a (typically
> hierarchically-structured) value assigned to a site (a cluster of
> subnets/links), the subnet ID is an identifier of a link within the site,
> and the interface ID is as defined in Section 2.4.1.
> >
> > As noted in Section 2.4, all Global Unicast addresses other than those
> that start with binary 000 have a 64-bit interface ID field (i.e., n + m =
> 64), formatted as described in Section 2.4.1. Global Unicast addresses that
> start with binary 000 have no such constraint on the size or structure of
> the interface ID field.
> >
> > Examples of Global Unicast addresses that start with binary 000 are the
> IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An
> example of global addresses starting with a binary value other than 000
> (and therefore having a 64-bit interface ID field) can be found in
> [RFC3587].
>
> Proposed (conservative):
> > where the global routing prefix is a (typically
> hierarchically-structured) value assigned to a site (a cluster of subnet
> prefixes assigned to links), the subnet ID is an identifier of a link
> within the site, and the interface ID is as defined in Section 2.4.1.
> >
> > As noted in Section 2.4, all Global Unicast addresses other than those
> that start with binary 000 have a 64-bit interface ID field (i.e., n = 64),
> formatted as described in Section 2.4.1. Global Unicast addresses that
> start with binary 000 have no such constraint on the size or structure of
> the interface ID field.
> >
> > Examples of Global Unicast addresses that start with binary 000 are the
> IPv6 address with embedded IPv4 addresses described in Section 2.4.5. An
> example of global addresses starting with a binary value other than 000
> (and therefore having a 64-bit interface ID field) can be found in
> [RFC3587].
>
> Reasoning: the only changes here are to make the field headings in the
> structure diagram consistent with those proposed for the similar diagram in
> §2.4, to use “subnet” only in the phrase “subnet prefix” and not as cognate
> of link, and to update the explanatory parenthetical in the second
> paragraph, “(i.e. n = 64)”, to reflect it accordingly.
>
> Proposed (liberal):
> > where the global routing prefix is a (typically
> hierarchically-structured) value assigned to a site (a cluster of subnet
> prefixes assigned to links), the subnet ID is an identifier of a link
> within the site, and the interface ID is as defined in Section 2.4.1.
>
> Reasoning: the field headings in the structure diagram are made consistent
> with those for the similar diagram in §2.4, and the two final paragraphs
> about addresses that start with binary 000 are elided in accordance with
> the proposed (liberal) change to §2.4. Also, the word “subnet” is used
> properly in the phrase “subnet prefix” where it is more clearly defined.
>
> > Nodes can send packets directly to other nodes with interfaces on the
> same link, without forwarding by a router, when they can identify the
> link-layer addresses associated with the unicast IPv6 addresses that share
> on-link subnet prefixes assigned to the interface. Neighbor discovery is
> conceptually the process of resolving such associations as necessary.
> >
> > Nodes may be configured manually with on-link subnet prefixes for each
> of their interfaces. Also, routers may inform hosts automatically of the
> set of on-link subnet prefixes by a process related to neighbor discovery.
> Nodes sending packets to unicast addresses with subnet prefixes that are
> not on-link must direct those packets to a router for forwarding to their
> destination.
> >
> > Every on-link prefix is a subnet prefix, and subnet prefixes for all
> global unicast addresses beginning with a binary value other than 000 are
> required according to Section 2.4 to be 64 bits in length.
>
>
> Reasoning: this text provides clarification that on-link prefixes are
> subnet prefixes for which neighbor discovery can be used by nodes to
> communicate directly without forwarding packets through a router. It also
> repeats the requirement that all subnet prefixes other than those beginning
> with 0b000 are 64 bits long.
>
> Proposed (liberal):
> > Nodes can send packets directly to other nodes with interfaces on the
> same link, without forwarding by a router, when they can identify the
> link-layer addresses associated with the unicast IPv6 addresses that share
> on-link prefixes assigned to the interface. Neighbor discovery is
> conceptually the process of resolving such associations as necessary.
>
> >
> > Nodes may be configured manually with on-link prefixes for each of their
> interfaces. Also, routers may inform hosts automatically of the set of
> on-link prefixes by a process related to neighbor discovery. Nodes sending
> packets to unicast addresses without an on-link prefix must direct those
> packets to a router for forwarding to their destination.
> >
> > An important distinction is made between subnet prefixes, which are
> defined in Section 2.4 as the part of a unicast address that precedes the
> interface identifier, and on-link prefixes which do not necessarily have
> structure in the part of unicast addresses that follows them. In
> particular, an on-link prefix may be shorter than the one or more subnet
> prefixes that share it, in which case the part that follows the on-link
> prefix consists of some additional bits that precede the interface
> identifier. Likewise, an on-link prefix may be longer than a subnet prefix
> it shares with one or more other on-link prefixes, in which case the part
> that follows the on-link prefix is only a portion of an interface
> identifier and hence may not itself necessarily have all the properties of
> an interface identifier as defined in Section 2.4.1, therefore it must not
> be used alone, in that case, to identify an interface on a link.
>
> Reasoning: this text is similar to the text in the conservative
> alternative except that it does not assert that every on-link prefix is a
> subnet prefix or specify any requirement for the length of either on-link
> or subnet prefixes. However, it does include an additional paragraph that
> discusses the necessary distinction between on-link and subnet prefixes in
> substantial detail, and it forbids the use of the part of a unicast address
> following an on-link prefix as identification for an interface on a link
> unless it is sufficiently long to meet the requirements of §2.4.
>
> > Some other possible uses are to identify the set of routers attached to
> a particular subnet, or the set of routers providing entry into a
> particular routing domain.
>
> > Some other possible uses are to identify the set of routers attached to
> a link for use by nodes at addresses sharing a particular subnet prefix, or
> to identify the set of routers providing entry into a particular routing
> domain.
>
> Reasoning: this change improves clarity by ensuring the term “subnet” is
> always used in the phrase “subnet prefix” and not as a shorthand for a
> subset of the nodes on a link using addresses that share the same subnet
> prefix.
>
> > The "subnet prefix" in an anycast address is the prefix that identifies
> a specific link. This anycast address is syntactically the same as a
> unicast address for an interface on the link with the interface identifier
> set to zero.
> >
> > Packets sent to the Subnet-Router anycast address will be delivered to
> one router on the subnet. All routers are required to support the
> Subnet-Router anycast addresses for the subnets to which they have
> interfaces.
>
> > The Subnet-Router anycast address is predefined for each subnet prefix.
> Its structure, as shown below, is the same as a unicast address with the
> same subnet prefix and with zero for the interface identifier.
> >
> >    |                      128-n bits                |   n bits       |
> > Packets sent to the Subnet-Router anycast address are destined for any
> router on the link that is assigned a unicast address with the
> corresponding subnet prefix. All routers are required to assign
> Subnet-Router anycast addresses to their interfaces for each subnet prefix
> used on the link.
>
> Reasoning: this change (which is essentially a complete rewrite of §2.5.1)
> improves clarity by making the field headers in the structure diagram
> consistent with §2.4, and by ensuring the term “subnet” is always used in
> the phrase “subnet prefix” and not as a shorthand for a subset of the nodes
> on a link using addresses that share the same subnet prefix.
>
> Commentary: it’s not clear to me what is the real purpose of the
> Subnet-Router anycast address, even in the conservative case, but
> especially so in the liberal case where on-link prefixes are not required
> to have the same length as subnet prefixes. It seems okay that a single
> Subnet-Router anycast address should be defined as the destination for any
> router with an address where more than one on-link prefix has a shorter
> subnet prefix in common. It seems much less okay that multiple
> Subnet-Router anycast addresses should be defined as destinations for any
> router with addresses having more than one subnet prefix sharing a common
> on-link prefix. Still, I don’t see how it breaks anything important, so I'm
> saying: let's try not to do any further damage.
>
> ——
>
> In summary, I believe when publishing the successor to RFC 4291 it may be
> possible for IETF to further clarify the IPv6 address architecture so that
> controversies over the validity of on-link prefixes used in neighbor
> discovery do not arise, either A) in the conservative case, because all
> on-link prefixes are also subnet prefixes and subnet prefixes are
> constrained to standard size(s) for each link type and to 64 bits for all
> prefixes beginning with 0b000, or B) in the liberal case, because neither
> on-link prefixes nor subnet prefixes are constrained to any standard size
> nor even required to be the same length.
>
> I hope this proposal will be seen correctly as my sincere attempt to
> provide a constructive basis for resolving this ongoing controversy into a
> rough consensus.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Mar 2017 08:26:40 -0800

Hi David,

Thank you very much for giving my proposal a fair hearing. This is just a quick response to one point you made. I may have more to say about the rest later.

On Mar 9, 2017, at 06:27, David Farmer <[email-masked]> wrote:
> 
> The conservative version of the proposal at least needs to be adjusted to allow for RFC6164 /127 point-to-point router links as an exception to on-link prefixes always being /64, there seems to be a conflict here in the conservative version.

I agree. While RFC 6164 does use the word “subnet” in a confusing way a few times, it seems reasonable to read it as a standard exception to the rule that on-link prefixes are always subnet prefixes (under my “conservative” proposal).

Hence, here is my revised proposal (conservative) for §2.4.8 Neighbor Discovery.

Proposed (conservative):
> Apart from standard exceptions, every on-link prefix is required to be a subnet prefix, and subnet prefixes for all global unicast addresses beginning with a binary value other than 000 are required according to Section 2.4 to be 64 bits in length. One standard exception to this is Using 127-Bit IPv6 Prefixes on Inter-Router Links [RFC6164].

Reasoning: this text provides clarification that, apart from standard exceptions, on-link prefixes are subnet prefixes for which neighbor discovery can be used by nodes to communicate directly without forwarding packets through a router. It also repeats the requirement that all subnet prefixes other than those beginning with 0b000 are 64 bits long. It provides an explicit reference to RFC6164 as a standard exception.

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Mar 2017 08:42:41 -0800

On Mar 9, 2017, at 03:16, Philip Homburg <[email-masked]> wrote:
> 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.

In my proposed clarification (both liberal and conservative versions), I preserve the distinction that subnet prefixes precede IIDs, whereas other routing prefixes, e.g. on-link prefixes, do not. If that doesn’t seem clear in my proposal for §2.4.8 Neighbor Discovery, then I could see adding text to that effect. Right now, it seems clear enough to me, so I’m holding off.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Philip Homburg <[email-masked]>
Date: Thu, 09 Mar 2017 19:30:11 +0100

>    On Mar 9, 2017, at 03:16, Philip Homburg
>    <[1][email-masked]> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Mar 2017 08:28:17 +1300

<rant format="short">
Isn't it time we all shut up and wait for the document editor to propose text?
</rant>

Regards
   Brian Carpenter

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 9 Mar 2017 19:28:48 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg

> 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 it, any slaac-iid that is based on (pseudo)-random
> number has to be at least 64 bits. I don't see any reason for more
> than 64 so exactly 64 sounds about right.

If you want random, a PRNG can create any length of IID. A 48-bit IID would be just as reasonable, and it could be formed from a randomly changing link layer address.

I would stay away, at this point, from any mention of 64 as a constant. We are (I think) beyond that, even for a particular 2000::/3 subset of globally unique unicast addresses.

Secondly, RFC 4862 states:

      Note that a future revision of the address architecture [RFC4291]
      and a future link-type-specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers. 

Which is where we are today, in fact.

> In theory, a link that has hardware MAC addresses with less than 64
> bits could define a slaac-iid that is shorter, however that precludes
> the use of pseudo-random slaac-iids.

I don't think it does.

Bert

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Mar 2017 11:31:30 -0800

Hi Philip,

This is just a brief response that I believe goes straight to your argument.

> related to stateless address configuration.

That’s because interface identifiers are not just for stateless address configuration. They’re for all forms of address configuration, whether SLAAC, DHCPv6 or manual. In all cases, they are required by RFC 4291 and predecessors to have the uniqueness properties first introduced in RFC 2513 and carried forward into I-D.ietf-6man-rfc4291bis today. The bits following any other form of routing prefix, including on-link prefixes, are not required to have any such uniqueness properties, and they never have been.

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Mar 2017 11:34:29 -0800

On Mar 9, 2017, at 11:31, james woodyatt <[email-masked]> wrote:
> […]  the uniqueness properties first introduced in RFC 2513 […]

RFC 2373, apologies.

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Mar 2017 11:34:34 -0800

<rant-response>
>         Isn't it time we all shut up and wait for the document editor to propose text?
If I were the document editor, after all this noise, I might wish that someone would tell me the half-of-a-sentence change that would have made this discussion unnecessary.
</rant-response>

---

From: [email-masked]
Date: Thu, 09 Mar 2017 21:25:04 +0100 (CET)

> That's because interface identifiers are not just for stateless
> address configuration. They're for all forms of address
> configuration, whether SLAAC, DHCPv6 or manual.

Well, if IIDs are for all forms of address configuration the document
cannot say that IIDs are 64 bit and at the same time reflect reality.
You get to choose one or the other, not both.

Steinar Haug, AS2116

---

From: 神明達哉 <[email-masked]>
Date: Thu, 9 Mar 2017 13:11:39 -0800

At Thu, 09 Mar 2017 19:30:11 +0100,

[...]
> stateless address configuration from other uses.

+1.  I've also been feeling that one source of seeming confusion in
this discussion may be confusion between "subnet prefixes" and
prefixes for on-link determination as described in RFC4861.  In fact,
the latter (I'll use the term "onlink prefix" in this message) has
nothing to do with "subnet prefixes" - it simply specifies a set of
addresses that should be supposed to be on-link for the corresponding
link.  Whether or not we adopt "conservative" or "liberal" view of the
length of IIDs or "subnet prefix" in the context of addressing
architecture, an onlink prefix can be longer or shorter than a
subnet prefix even if these two share some leading bits.

So, for example:
- if we adopt the "conservative" address architecture,
  The subnet prefix for 2001:db8:1:2:3:4:5:6 must be 2001:db8:1:2::/64.
- if we adopt the "liberal" address architecture,
  The subnet prefix for 2001:db8:1:2:3:4:5:6 can be 2001::/16,
  2001:db8::/32, 2001:db8:1::/48, 2001:db8:1:2::/64,
  ...2001:db8:1:2:3:4:5:0/120, etc.
and, in either case,
- onlink prefx in this link advertised via an RA with L=1 can be
  2001::/16, 2001:db8::/32, 2001:db8:1::/48, ...2001:db8:1:2:3:4:5:0/120, etc.

In particular, the fact that onlink prefix can be of any length
doesn't mean it violates the conservative address architecture.

Perhaps one source of confusion is the fact or expectation that RA PIO
often both sets A and L bits on.  So, in the above example, if we have
a PIO for 2001:db8:1::/48 or 2001:db8:1:2:3:4:5:0/120 with both L and
A bits on, these are valid on link prefix.  But they can't be used for
SLAAC (assuming its link-layer spec specifies the consistent IID length
with the "conservative" address architecture, i.e., 64).  That is, for
the same PIO,
- if we consider it as on-link prefix, it can coexist with any of the
  address architecture
- if we consider it for SLAAC, it can only coexist with the
  conservative architecture, or liberal one with an exception of
  requiring 64-bit subnet prefix length specifically for SLAAC

>> Isn't it time we all shut up and wait for the document editor to

I don't want to contribute to making this thread even longer, so I
promise I'll stop here.  But I wanted to make this one remark since
I believe it's important to clarify that ("on-link prefix" is
irrelevant to the address architecture discussion) and I see why this
can be so confusing.  Even if this attempt of mine fails, I'll shut up
now (maybe I should write a separate draft just focusing on this
particular confusion).

--
JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 10 Mar 2017 03:57:03 +0000

> On Mar 9, 2017, at 2:28 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> <rant format="short">

Thanks Brian. That is the plan. It has been hard to summarize the last call and the way forward due to the continuing discussion on the 4291bis document. Expect something in the next day or two.
 
Regards
Suresh

---

From: [email-masked]
Date: Sat, 11 Mar 2017 09:57:07 +0100

Jinmei,

Is there anything here that isn't covered by 5942?

And creating an artificial separation of prefixes used for address assignment (SLAAC) and prefixes used for on-link determination seems fraught with dangers. E.g. from a router perspective you need a connected route aka an onlink prefix for the prefix used for address assignment, otherwise you have no reachability.

O.

> On 9 Mar 2017, at 22:11, 神明達哉 <[email-masked]> wrote:
>

---

From: Philip Homburg <[email-masked]>
Date: Sat, 11 Mar 2017 12:49:23 +0100

> And creating an artificial separation of prefixes used for address
> assignment (SLAAC) and prefixes used for on-link determination
> seems fraught with dangers. E.g. from a router perspective you need
> a connected route aka an onlink prefix for the prefix used for
> address assignment, otherwise you have no reachability.

It seems to me that RFC 5942 doesn't say a lot about stateless
address configuration. So if we want to say something like 'the IID used
for SLAAC should be 64 bits' then RFC 5942 is not of help.

The classical example where a prefix is not onlink is NBMA networks.
But I can imagine that once IPv4 is out of the way, people will find 
more creative uses where it helps if a prefix that is used for SLAAC is not
onlink.

Note that in the context of ND, onlink prefixes is mostly about host
behavior, because routers are (in practice) not using them to configure
what is onlink or not. Also note that hosts may consider a prefix not onlink
whereas the router considers the prefix onlink. ND can handle that.

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Mar 2017 23:10:23 +1100

> more creative uses where it helps if a prefix that is used for SLAAC is not

See slide 18 onwards.

https://www.slideshare.net/MarkSmith214/ipv6-ras-mostly-necessary

---

From: Philip Homburg <[email-masked]>
Date: Sat, 11 Mar 2017 13:17:55 +0100

> If you want random, a PRNG can create any length of IID. A 48-bit
> IID would be just as reasonable, and it could be formed from a
> randomly changing link layer address.

The way I see it is that for pseudo-random IIDs we should set the minimum
length such that statistically a collision between addresses never happens.
Obviously collossions will happend due to implementation errors, but I
think the abstract model should have an extremely low chance of collossions,
ever.

It is easy enough to argue that 64 bits is enough. It is also easy enough
to argue that 32 bits is not enough. Would 48 bits work? That's a matter
of estimating how big the IPv6 network will grow. 

Another way of looking at this, why would we need IIDs that are less than
64 bits? The current IPv6 address architecture has no problems supporting
64 bit IIDs. There doesn't seem to be any technical reason to risk a higher
chance of collissions by lowering the number of bits.

Instead, the argument used for those is that some operators did something
stupid and assign only a single /64 to a collection of links. This,
despite all efforts initially to make sure that /48s were assigned. 

So it is reasonable to assume that if we would fully support /80 prefixes
in SLAAC, that some operators would again not read/understand our address
architecture and just assign a single /80 and we a back to square one.

So modifying hosts to generate IIDs smaller than 64 bits would have benefits
in the short run, but it the long run trades an increase in risk of
collission for no benefit at all.

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Mar 2017 23:51:49 +1100

> If you want random, a PRNG can create any length of IID. A 48-bit IID would be just as reasonable, and it could be formed from a randomly changing link layer address.

You two have read

"Analysis of the 64-bit Boundary in IPv6 Addressing"
https://tools.ietf.org/html/rfc7421

haven't you?

48 bit IIDs were given up between RFC1883 and RFC2373.

<snip>

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 11 Mar 2017 17:49:32 +0100

Le 11/03/2017 à 09:57, [email-masked] a écrit :
> assignment (SLAAC) and prefixes used for on-link determination seems
> fraught with dangers. E.g. from a router perspective you need a
> connected route aka an onlink prefix for the prefix used for address
> assignment, otherwise you have no reachability.

Further, I disagree that a distinction between on-link prefix and SLAAC
prefix favors continuation of the 64bit IID, and of the 64bit limit for
that matter.

A situation can be created where a SLAAC prefix is /64 and  a distinct
on-link prefix is of plen /65 on that same link.  But this situation is
not desirable.

Because a Host that configures itself an address within the /64 may in
some cases not be visible to the ND of another Host on that same link;
that other Host used on-link determination with a /65 to find out
whether it is on link or not.

This problem of visibility is very clear especially if a default router
is absent on that link (subnets isolated from the Internet).  If a
default router is present, then this visibility problem may not be that
obvious.

This is why the distinction between the plens of an on-link prefix and
of a SLAAC prefix on same link is not something good.  These two plens
should be the same.

And when they are the same (the prefix for on-link determination, and
the prefix for SLAAC), they must have the same plen.  And that plen can
be anything from 1 to 128.

Finally, yes, it is possible to have multiple prefixes on same link.
But these prefixes should be paired: on-link prefix1 and SLAAC prefix1,
onlink prefix2 and SLAAC prefix2, and so on.

Alex

>> At Thu, 09 Mar 2017 19:30:11 +0100, Philip Homburg
>>> 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.
>> [...]
>>> 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.
>>
>> prefixes for on-link determination as described in RFC4861.  In
>> fact, the latter (I'll use the term "onlink prefix" in this
>> message) has nothing to do with "subnet prefixes" - it simply
>> specifies a set of addresses that should be supposed to be on-link
>> for the corresponding link.  Whether or not we adopt
>> "conservative" or "liberal" view of the length of IIDs or "subnet
>> prefix" in the context of addressing architecture, an onlink prefix
>> can be longer or shorter than a subnet prefix even if these two
>> share some leading bits.
>>
>> So, for example: - if we adopt the "conservative" address
>> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 must be
>> 2001:db8:1:2::/64. - if we adopt the "liberal" address
>> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 can be
>> 2001::/16, 2001:db8::/32, 2001:db8:1::/48, 2001:db8:1:2::/64,
>> ...2001:db8:1:2:3:4:5:0/120, etc. and, in either case, - onlink
>> prefx in this link advertised via an RA with L=1 can be 2001::/16,
>> 2001:db8::/32, 2001:db8:1::/48, ...2001:db8:1:2:3:4:5:0/120, etc.
>>
>> Perhaps one source of confusion is the fact or expectation that RA
>> PIO often both sets A and L bits on.  So, in the above example, if
>> we have a PIO for 2001:db8:1::/48 or 2001:db8:1:2:3:4:5:0/120 with
>> both L and A bits on, these are valid on link prefix.  But they
>> can't be used for SLAAC (assuming its link-layer spec specifies
>> the consistent IID length with the "conservative" address
>> architecture, i.e., 64).  That is, for the same PIO, - if we
>> consider it as on-link prefix, it can coexist with any of the
>> address architecture - if we consider it for SLAAC, it can only
>> coexist with the conservative architecture, or liberal one with an
>> exception of requiring 64-bit subnet prefix length specifically
>> for SLAAC
>>
>>  promise I'll stop here.  But I wanted to make this one remark
>> since I believe it's important to clarify that ("on-link prefix" is
>> irrelevant to the address architecture discussion) and I see why
>> this can be so confusing.  Even if this attempt of mine fails,
>> I'll shut up now (maybe I should write a separate draft just
>> focusing on this particular confusion).
>>
>> -- JINMEI, Tatuya
>>
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 11 Mar 2017 17:51:58 +0100

Le 11/03/2017 à 13:17, Philip Homburg a écrit :
> The way I see it is that for pseudo-random IIDs we should set the
> minimum length such that statistically a collision between addresses
> never happens. Obviously collossions will happend due to
> implementation errors, but I think the abstract model should have an
> extremely low chance of collossions, ever.
>
> It is easy enough to argue that 64 bits is enough. It is also easy
> enough to argue that 32 bits is not enough. Would 48 bits work?
> That's a matter of estimating how big the IPv6 network will grow.
>
> Another way of looking at this, why would we need IIDs that are less
> than 64 bits?

In order to run SLAAC on links on which a /63 is routed to.

Alex

> The current IPv6 address architecture has no problems supporting 64
> bit IIDs. There doesn't seem to be any technical reason to risk a
> higher chance of collissions by lowering the number of bits.
>
> Instead, the argument used for those is that some operators did
> something stupid and assign only a single /64 to a collection of
> links. This, despite all efforts initially to make sure that /48s
> were assigned.
>
> So it is reasonable to assume that if we would fully support /80
> prefixes in SLAAC, that some operators would again not
> read/understand our address architecture and just assign a single /80
> and we a back to square one.
>
> So modifying hosts to generate IIDs smaller than 64 bits would have
> benefits in the short run, but it the long run trades an increase in
> risk of collission for no benefit at all.
>