Subject: Section 2.4 of rfc4291bis

From: David Farmer <[email-masked]>
Date: Mon, 31 Jul 2017 17:32:34 -0500

Recent discussion on the list have convinced me that section 2.4 really
needs to discuss on-link prefixes in some detail.  It needs to describe
their format similar to how the format of subnet prefixes are described,
and describe how on-link prefixes are used by nodes. Also, a description of
how subnet prefixes are used is needed to differentiate the two types of
prefixes are used.  Several other changes were needed to integrate these
major changes with the rest of the text, with other additional editorial
changes.

In my opinion the current text gives the false impression that there is
always a common prefix for address assignment and on-link determination, or
the subnet prefix and the on-link prefix are the same, which they
frequently are, but are not require to be.

I have use Interface Identifier as the right-hand side of the on-link
prefix, but this could have a different name if that is the consensus of
the work group, but I think Interface Identifier makes the most sense.

A few additional points;
- Section 2.1 is quite clear "IPv6 addresses of all types are assigned to
interfaces, not nodes." So, I think the "node address" in the first diagram
should be renamed to "interface address".

-  Include are changes to the 4th paragraph of section 2.4.1, based on this
rewrite of section 2.4, scoping the definition of 64 bit Interface
Identifiers to "When automatically assigning a unicast address to an
interface". with that most of exceptions are not needed any longer.

-  Include is an additional paragraph for the Link-Local section 2.4.6,
based on his rewrite of section 2.4, saying that "by definition all nodes
are aware of the
Link-Local prefix and used it as if it is a subnet and on-link prefix".

I suggest the following text for section 2.4, use as you see fit;

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

IPv6 unicast routing and on-link determination are based on prefixes
of any valid length up to 128 bits[BCP198], which are typically, but
not necessarily, the same as the subnet prefixes used to
automatically assign an address to an interface.

There are several types of unicast addresses in IPv6, in particular,
Global Unicast, Local unicast, and Link-Local unicast.  There are
also some special-purpose subtypes of Global Unicast, such as IPv6
addresses with embedded IPv4 addresses.  Additional address types or
subtypes can be defined in the future.

IPv6 nodes may have considerable or little knowledge of the internal
structure of the IPv6 address, depending on the role the node plays
(for instance, host versus router). Further, the internal structure
of a unicast address varies subtly based how the address is being
used (for instance, when automatically assigning an address to an
interface versus delivering packets).

Except as described below, and at a minimum, a node will consider
that unicast addresses (including those for its own interfaces) have
no internal structure:

|                           128 bits                              |
+-----------------------------------------------------------------+
|                       interface address                         |
+-----------------------------------------------------------------+

A node may be aware of subnet prefix(es) for the link(s) it is
attached to. By default such nodes will automatically assign unicast
addresses to the interface(s) that are attached to those link(s), by
prepending the subnet prefix(es) to the Interface Identifier(s) for
those link(s). Where different link(s) may have different values for
n:

|           n bits              |           128-n bits            |
+-------------------------------+---------------------------------+
|        subnet prefix          |          interface ID           |
+-------------------------------+---------------------------------+

A node may also be aware of on-link prefix(es) for the link(s) it is
attached to. Such nodes may use the on-link prefix(es) to determine
the unicast addresses for which packets may be locally delivered on
the attached link(s). Where different link(s) may have different
values for n:

|           n bits              |           128-n bits            |
+-------------------------------+---------------------------------+
|       on-link prefix          |          interface ID           |
+-------------------------------+---------------------------------+

A node may be aware of router(s) available on the link(s) it is
attached to. Such nodes may send packets to the router(s) for
delivery, especially for the unicast address for which packets cannot
be locally delivered on a node's attached link(s).

A router may have no more knowledge of the internal structure of
unicast addresses than any other node. However, generally routers
are attached to more links than other nodes and will usually have
knowledge of one or more hierarchical boundaries through the
operation of routing protocols.  The known boundaries will differ
from router to router, depending on what position the router holds
in the routing hierarchy.

Nodes should not make any assumptions about the structure of an

address. Unicast addresses have no internal structure, except for

knowledge of subnet prefixes, when automatically assigning an

address to an interface, or knowledge of on-link prefixes and other

routing boundaries, when delivering packets, as discussed in the

previous paragraphs.

----

I also suggest the following text for 4th paragraph of section 2.4.1;

When automatically assigning a unicast address to an interface,
Interface Identifiers are 64 bits long except if the first three bits
of the address are 000. The rationale for using 64 bit Interface
Identifiers can be found in [RFC7421].

-----

And that the following is added as the 3rd paragraph of section 2.4.6;

Link-Local addresses are different than other types of Unicast
addresses, in that by definition all nodes are aware of the
Link-Local prefix and used it as if it is a subnet and on-link prefix
for each link a node has, as described in section 2.4. Therefore, by
default all nodes automatically assign Link-Local addresses on each
interface and always treat Link-Local address as on-link for each
interface.

What do others think?

Thanks

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Aug 2017 09:27:31 +1000

I still don't understand what your "on-link prefix" is.

"on-link" is a bit that is only significant to the decision as to whether a
device believes the destination is directly reachable over the link or via
a router.

Different devices can have a different opinion of this, even if they were
attached to the same link. Unlikely if the on-link state is expressed via
RA PIOs, however there is no requirement that all devices have the same
on-link belief about a range of addresses covered by a prefix.

It is only significant to ND and forwarding operation, which is why it is
defined in RFC4861, rather than RFC4291. A more accurate name of 'on-link'
and 'off-link' would really be 'directly link reachable' or 'remotely
reachable via router'.

The exception is Link Local destinations, which default to on-link/directly
link reachable. That cannot currently be overridden.
https://tools.ietf.org/html/draft-smith-6man-link-locals-off-link-00
proposed how LL destinations could be flipped to being considered remotely
reachable for cases where it would be useful.

Your text below is making it sound far more significant and also sounds a
bit like something different to an ND related operational bit. It sounds
like you're describing something different.

Regards,
Mark.

On 1 Aug. 2017 08:32, "David Farmer" <[email-masked]> wrote:

> interfaces, not nodes." So, I think the "node address" in the first
> diagram should be renamed to "interface address".
>
> -  Include are changes to the 4th paragraph of section 2.4.1, based on
> this rewrite of section 2.4, scoping the definition of 64 bit Interface
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: David Farmer <[email-masked]>
Date: Mon, 31 Jul 2017 22:25:35 -0500

> I still don't understand what your "on-link prefix" is.

Oh, come on, you seem to understand me just fine.

> "on-link" is a bit that is only significant to the decision as to whether
> a device believes the destination is directly reachable over the link or
> via a router.
>

No, it is only a bit within a PIO, hosts maintain a Prefix List, which it
seems quite logical to call a member of this list a "on-link prefix".

>From Section 5.1 or RFC 4861;

      Prefix List  - A list of the prefixes that define a set of
                     addresses that are on-link.  Prefix List entries
                     are created from information received in Router
                     Advertisements.  Each entry has an associated
                     invalidation timer value (extracted from the
                     advertisement) used to expire prefixes when they
                     become invalid.  A special "infinity" timer value
                     specifies that a prefix remains valid forever,
                     unless a new (finite) value is received in a
                     subsequent advertisement.

Or, from Section 3 of RFC 5942;

       Any node attached to the link can send a datagram directly
       to an on-link address without forwarding the datagram through a
       router.  However, in order for a node to know that a destination
       is on-link, it must obtain configuration information to that
       effect.  In IPv6, there are two main ways of maintaining
       information about on-link destinations.  First, a host maintains
       a Prefix List that identifies ranges of addresses that are to be
       considered on-link.  Second, Redirects can identify individual
       destinations that are on-link; such Redirects update the
       Destination Cache.

       The Prefix List is populated via the following means:

       *  Receipt of a valid Router Advertisement (RA) that specifies a
          prefix with the L-bit set.  Such a prefix is considered
          on-link for a period specified in the Valid Lifetime and is
          added to the Prefix List.  (The link-local prefix is
          effectively considered a permanent entry on the Prefix List.)

       *  Indication of an on-link prefix (which may be a /128) via
          manual configuration, or some other yet-to-be-specified
          configuration mechanism.

       A Redirect can also signal whether an address is on-link.  If a
       host originates a packet, but the first-hop router routes the
       received packet back out onto the same link, the router also
       sends the host a Redirect.  If the Target and Destination Address
       of the Redirect are the same, the Target Address is to be treated
       as on-link as specified in Section 8 of [RFC4861].  That is, the
       host updates its Destination Cache (but not its Prefix List --
       though the impact is similar).

> and 'off-link' would really be 'directly link reachable' or 'remotely

RFC 4291bis is talking about routing in section 2.4 (section 2.5 in RFC
4291) and implying that is based on the subnet prefix. Further, by using
the term "subnet prefix" it is also implying that on-link determination is
based on this prefix, which is not necessarily the case. Continued below;

> The exception is Link Local destinations, which default to
> on-link/directly link reachable. That cannot currently be overridden.

Your document seem to acknowledge that hosts maintain an "Prefix List" of
on-link prefixes, and you are removing things from this list of on-link
prefixes.

> like you're describing something different.

Further if you believe that a subnet prefix must be 64 bits long because an
IID is defined as 64 bits, and at least for SLAAC I believe that is true.
However, even SLAAC is quit clear that on-link determination is any length,
and therefore the prefix used for on-link determination needs to be
distinguished from a subnet prefix some how, that's what I'm trying to do.
Otherwise you need to be explicit a subnet prefixes can be any length when
used for on-link determination. If you want to go that route, I'd be fine
with that, but you and others have objected to that.

>From Section 5.5.3. of RFC 4862;

      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] (see
      Section 2).

      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.

> Mark.

Thanks.

---

From: Mark Smith <[email-masked]>
Date: Tue, 1 Aug 2017 16:10:16 +1000

Ok, going back to your original email.

their format

What is this format? I can't guess what it is.

As RFC5942 says, On-link or offlink is a property associated with a subnet
prefix. It doesn't change the format of the subnet prefix.

If anything, "on-link prefix" is short for "on-link subnet prefix".

>similar to how the format of subnet prefixes are described, and describe
how on-link prefixes are used by nodes. Also, a description of how subnet
prefixes are used is needed to differentiate the two types of prefixes are
used.  Several other changes were needed to integrate these major changes
with the rest of the text, with other additional editorial changes.

RFC5942 does all that, reference it.

This is confusing. What address generation and configuration method is
being used? DHCPv6, SLAAC or manual configuration?

I don't understand how the subnet prefix and the onlink (subnet) prefix can
be different.

I can't guess what property is being described that could have a different
name.

If stateful DHCPv6 is the unstated context, is what you and others
describing the range of addresses the DHCPv6 server hands out?

That is a parameter of the DHCPv6 server's config, not something more
abstract to addresses regardless of how they're configured. It could be
given a DHCPv6 specific name in rfc3315bis if necessary.

The lower portions of those addresses are still interface identifiers,
because they identify interfaces attached to a link. That is a generic
property of an address regardless of if it was configured using SLAAC,
DHCPV6 or manually configured.

In these emails that I find confusing, I think people are sometimes not
stating necessary context, and are conflating concepts and properties that
are generic to addresses, regardless of how they're generated and
configured with things that are specific to how addresses are generated and
configured.

There are properties of addresses that are generic, regardless of how the
address is generated, configured and used. The location of the boundary
between subnet prefix and IID portions is an examples. The place for their
definition is RFC4291.

There are properties specific to how addresses are generated. There are
properties specific to how addresses are configured. Sometimes they'll be
tightly coupled together because the generation method depends on
properties of the configuration method. The range of addresses a DHCPv6
server hands out is a property specific to DHCPv6 based address
configuration. It means nothing to SLAAC, SLAAC uses the full IID space in
the subnet prefix.

For these properties, they're best described in address
generation/configuration specific RFCs, e.g., 4862, 3315, 4941.

There are properties of addresses that are specific to where the address is
used, yet not related to how it was generated or configured.
On-link/off-link is a specific example, described in RFC4862 and RFC5942.

Regards,
Mark.

A few additional points;

|                           128 bits                              |

|           n bits              |           128-n bits            |

|           n bits              |           128-n bits            |

previous paragraphs.

----

-----

What do others think?

Thanks