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

[David Farmer <[e-mail]>]

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 <[e-mail]> 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.
>
> 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]>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



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