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

[james woodyatt <[e-mail]>]

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 <[e-mail]>