IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

[David Farmer <[e-mail]>]

On Sat, Jul 8, 2017 at 3:35 PM, Brian E Carpenter <
[e-mail]> wrote:

> On 08/07/2017 17:47, Lorenzo Colitti wrote:
> > On Tue, Jul 4, 2017 at 5:22 AM, David Farmer <[e-mail]> wrote:
> >>
> >>    Interface Identifiers are 64 bit long except if the first three bits
> >>    of the address are 000, or when the addresses are manually
> >>    configured, or by exceptions defined in standards track documents.
> >>
> >>
> > I don't think we should say "by exceptions defined in standards track
> > documents". Whatever document wants to allow non-64-bit prefixes should
> > formally update RFC 4291. Anything else will be confusing for
> implementers.
>
> We're trying to find a compromise between excessive rigidity and excessive
> flexibility. I don't see any confusion in the present text: if you've read
> 4291bis and you come upon a standards track document specifying a value
> !=64, you can use it. If you've only read RFC4291, you're out of date.
>
> You can certainly argue that RFC6164 should have formally updated RFC4291.
>

I don't think a simple statement that is a "compromise between excessive
rigidity and excessive flexibility" is going to work.  I think we need a
more nuanced statement that makes clear that address assignment is ridged
at 64 bits, but routing is flexible anywhere between 0 and 128 bits.

Lets step back from RFC4291bis for a moment and look at how IPv6 subnets,
routing, neighbor discovery, SLAAC and addressing are all interrelated.

RFC5942 the IPv6 Subnet Model, says compared to IPv4;

-  The behavior of IPv6 as specified in Neighbor Discovery (ND)
   [RFC4861] is quite different.  The on-link determination is separate
   from the address assignment.  A host can have IPv6 addresses without
   any related on-link prefixes or can have on-link prefixes that are
   not related to any IPv6 addresses that are assigned to the host.  Any
   assigned address on an interface should initially be considered as
   having no internal structure as shown in [RFC4291].

-      The assignment of an IPv6 address -- whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
       or manual configuration -- MUST NOT implicitly cause a prefix
       derived from that address to be treated as on-link and added to
       the Prefix List.  A host considers a prefix to be on-link only
       through explicit means, such as those specified in the on-link
       definition in the Terminology section of [RFC4861] (as modified
       by this document) or via manual configuration.  Note that the
       requirement for manually configured addresses is not explicitly
       mentioned in [RFC4861].

RFC4861 Neighbor Discovery (ND), says;

-  When sending a packet to a destination, a node uses a combination of
   the Destination Cache, the Prefix List, and the Default Router List
   to determine the IP address of the appropriate next hop, an operation
   known as "next-hop determination".  Once the IP address of the next
   hop is known, the Neighbor Cache is consulted for link-layer
   information about that neighbor.

   Next-hop determination for a given unicast destination operates as
   follows.  The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is the
   same as the packet's destination address.  Otherwise, the sender
   selects a router from the Default Router List

-  Address resolution is the process through which a node determines the
   link-layer address of a neighbor given only its IP address.  Address
   resolution is performed only on addresses that are determined to be
   on-link and for which the sender does not know the corresponding
   link-layer address.

-  Stateless address autoconfiguration [ADDRCONF] ... may impose
   certain restrictions on the prefix length for address configuration
   purposes.  Therefore, the prefix might be rejected by [ADDRCONF]
   implementation in the host.  However, the prefix length is still valid
for
   on-link determination when combined with other flags in the prefix
option.

RFC7608 IPv6 Prefix Length Recommendation for Forwarding, says;

-  Forwarding processes MUST be designed to process prefixes of any
   length up to /128, by increments of 1.

RFC4862 IPv6 Stateless Address Autoconfiguration, says;

-     If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.  An implementation MAY wish to log a system management
      error in this case.  The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with the address architecture [RFC4291].

      It is the responsibility of the system administrator to ensure
      that the lengths of prefixes contained in Router Advertisements
      are consistent with the length of interface identifiers for that
      link type.  It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  In fact, the
      advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.  Thus, it
      should be safe to validate the advertised prefix length here, in
      order to detect and avoid a configuration error specifying an
      invalid prefix length in the context of address autoconfiguration.

RFC4291 IPv6 Addressing Architecture, say;

-  IPv6 unicast addresses are aggregatable with prefixes of arbitrary
   bit-length, similar to IPv4 addresses under Classless Inter-Domain
   Routing.

-  For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

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

   Though a very simple router may have no knowledge of the internal
   structure of IPv6 unicast addresses, routers will more generally have
   knowledge of one or more of the hierarchical boundaries for the
   operation of routing protocols.  The known boundaries will differ
   from router to router, depending on what positions the router holds
   in the routing hierarchy.

   Except for the knowledge of the subnet boundary discussed in the
   previous paragraphs, nodes should not make any assumptions about the
   structure of an IPv6 address.

----

The fact that RFC4291 uses the term subnet confuses things a lot, but
RFC5942 is quite explicit that the two aspects of a subnet (on-link
determination and address assignment) are split in IPv6. So,  I'm going to
use the terms on-link prefix and address assignment prefix as separate
entities, and not the term subnet.

What does all that mean:

-  It can be inferred from the 64 bit IID requirement that address
assignment prefixes are
   64 bits in length.

-  SLAAC assigns 64 bit IIDs and they are combined with 64 bit address
assignment
   prefixes.

-  Routing and neighbor discovery are both based on on-link prefixes of any
length, up to
   128 bits.

-  IIDs within an address assignment prefix are not valid neighbors unless
they are also
   covered by an on-line prefix.

-  Link-local addresses by definition are alway valid neighbors or in other
words the
   on-link prefix for link-local is 64 bits by definition.

How is the seeming contradiction between a fixed 64 bit address assignment
prefix and a variable length on-link prefix reconciled?

The easiest way to reconcile this is;

  A common 64 bit prefix can be used for both the on-link prefix and the a
ddress
  assignment prefix for a link.

However, that is not the only way, another way to reconcile this is to view
it is as constraining which links address assignment prefixes and
on-link prefixes
are associated with.

  All 64 bit or longer on-link prefixes must be associated with the same
link as
  the covering 64 bit address assignment prefix. And, all of the 64 bit a
ddress
  assignment prefixes must be associated with the same link as a covering 63
bit
  or shorter on-link prefix.

----

Examples;

1. A link has an address assignment prefix of 2001:db8:1::/64, and on-link
prefix of 2001:db8:1::/64

This one is easy and as humans we like easy, so this is going to be the
most common situation. However;

2. A link has an address assignment prefix of 2001:db8:1::/64, and on-link
prefixes of 2001:db8:1::1:0/112 and 2001:db8:1::2:0/112

So the address 2001:db8:1::4:5 is not on-link in this example. While
2001:db8:1::/64 is assigned to be used for this link, without a covering
on-link prefix 2001:db8:1::4:5 is not a valid neighbor. The assignment
prefix just means that this address would have to be on this link if it was
a valid neighbor, but only on-link prefixes determine what is a valid
neighbor. So, If 2001:db8:1::4:5 were assigned to a node, the node could
use it's link-local address but no other nodes would be able to communicate
with it using the address 2001:db8:1::4:5, again it's not a valid neighbor
because there is no covering on-link prefix.

3.  A link has an on-link prefix of 2001:db8:0::/63, and address assignment
prefixes of 2001:db8:0::/64 and 2001:db8:1::/64

In reality this is almost as simple as #1, just summarize the two address
assignment prefixes in to one on-link prefix.

----

A few observations:

Except for RFC4291, most of the specification of IPv6 seem clear that
on-link prefixes are any length 0-128 bits, even SLAAC seems quite specific
that on-link prefixes can be any length.  Therefore, it seems unlikely that
RFC4291's specification of 64 bit IIDs are intended to be interpreted as
saying anything about on-link prefixes or to constrain routing or neighbor
discovery in any way. It seems RFC4291's specification of 64 bit IIDs
should only be interpreted as constraining address assignment and not
on-link determination. Further, this seems consistent with RFC4291's title
"IPv6 Addressing Architecture", therefore the scope of it's statements
should be constrained to address assignment or addressing in general,
unless it specifically says something has a broader scope.

It seems clear from RFC5942 that when a prefix length is specified with a
manual configured address it should be interpreted as an on-link prefix not
an address assignment prefix.

If SLAAC is used with an on-link prefix other than 64 bits, all of the
available IIDs will not be valid neighbors, this likely not consistent the
normal intended use of SLAAC. However, when addresses are assigned with
DHCPv6 or manual configuration, it is seems easily possible consider
on-link prefixes of any length.

Further, the use of a common address assignment prefix and on-link prefix
seems the simplest way to resolve the apparent conflict between a fixed 64
bit address assignment prefix and a variable length on-link prefix, However
this is not required.

Therefore it seems like a good idea to provide general guidance that
"on-link prefixes identical to address assignment prefixes are
recommended", but again this is not required.

----

So, What should we say in RFC4291bis? Personally I'd prefer we eliminate
the term subnet from RFC4291bis, but assuming that won't happen how about
the following;

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 differs
from the IPv4 model in that the prefixes used for on-link determination are
separate and may differ from the assigned subnet prefixes. However, on-link
prefixes identical with assigned subnet prefixes are recommended. A prefix
length associated with a manually configured address determines the on-link
prefix associated with the manually configured address. See [RFC5942] "The
IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes" for
more details.


Note: Any on-link prefixes longer than a covering assigned subnet prefix
must be associated with the same link as the assigned subnet prefix. Also,
any assigned subnet prefixes longer than a covering on-link prefix must be
associated with the same link as the on-link prefix.


----

IPv6 unicast routing is based on on-link prefixes of any valid length up to
128 [BCP198], which are not necessarily the same as the subnet prefixes
assigned to a link.


----

When forming or assigning unicast addresses, except those that start with
the binary value 000, Interface IDs are required to be 64 bits long.  The
rationale for using 64 bit Interface Identifiers can be found in [RFC7421].

Note: the previous paragraph implies nothing about on-link determination
which as discussed in section 2.1 is separate from subnet assignment in
IPv6.


Throw the rotten vegetables now!

Thanks!




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