Skip to main content

IPv6 Routing and its Relationship to the 64-bit Boundary in the IPv6 Addressing Architecture
draft-farmer-6man-routing-64-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author David Farmer
Last updated 2018-12-30
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-farmer-6man-routing-64-01
6man Working Group                                             D. Farmer
Internet-Draft                                        Univ. of Minnesota
Updates: 4291 (if approved)                            December 30, 2018
Intended status: Standards Track
Expires: July 3, 2019

  IPv6 Routing and its Relationship to the 64-bit Boundary in the IPv6
                        Addressing Architecture
                    draft-farmer-6man-routing-64-01

Abstract

   There is a common misconception that the IPv6 Addressing Architecture
   requires the use of only /64 subnet prefixes for subnet routing.
   This document clarifies the characterization of the relationship
   between IPv6 routing and the 64-bit boundary, which is that of a
   recommendation for the use of /64 subnet prefixes for subnet routing
   in most circumstances, not a requirement for such.  To further
   clarify the relationship, the document also provides operational
   guidance for the configuration of subnet prefixes and updates
   RFC 4291 accordingly.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 3, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of

Farmer                    Expires July 3, 2019                  [Page 1]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Two Forms of Subnet Prefixes and Interface Identifiers  .   3
     2.2.  How the Two Forms are Used  . . . . . . . . . . . . . . .   6
     2.3.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Updates to RFC 4291 . . . . . . . . . . . . . . . . . . . . .   8
   4.  Operational Guidance for the Configuration of Subnet Prefixes   8
     4.1.  Subnet Prefixes Other Than /64  . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Change log [RFC Editor: Please remove]  . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The IPv6 Addressing Architecture [RFC4291] defines the relationship
   between subnet prefixes and interface identifiers.  Furthermore, it
   effectively defines two forms of subnet prefixes and interface
   identifiers, a general form and a standard form of each.

   In their general form subnet prefixes have any length 0 to 128 bits,
   inclusive, and interface identifiers are independent of any specific
   length.  IPv6 routing is based these general forms, including both
   subnet routing and on-link determination.

   When the IPv6 Addressing Architecture also defines interface
   identifiers as being 64 bits in length, and historically constructed
   in Modified EUI-64 format, it is effectively creating a distinct
   standard form of interface identifiers.  Which also creates a
   distinct standard form of subnet prefixes that are 64 bits in length
   as well.  Autonomous address-configuration and most other aspects of
   the IPv6 specifications assume or depend on these standard forms.
   Additionally, most unicast addresses are intended to be formatted and
   assigned based on these standard forms.

Farmer                    Expires July 3, 2019                  [Page 2]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   These two forms of subnet prefixes and interface identifiers are
   currently not sufficiently distinguished in the IPv6 Addressing
   Architecture allowing them to be confused and conflated, creating the
   common misconception that it requires the use of only /64 subnet
   prefixes for subnet routing.  This confusion is compounded by a lack
   of definitive operational guidance for the configuration of subnet
   prefixes that would further clarify the controversy.

   Although /64 subnet prefixes are required for autonomous address-
   configuration and are most often configured for subnet routing, any
   length subnet prefixes, 0 to 128 bits, inclusive, are valid for IPv6
   routing, including both subnet routing and on-link determination.
   Nevertheless, for consistency with the 64-bit boundary and most other
   aspects of the IPv6 specifications, /64 subnet prefixes are
   recommended for subnet routing in most circumstances.

   This document clarifies the characterization of the relationship
   between IPv6 routing and the 64-bit boundary, which is that of a
   recommendation for the use of /64 subnet prefixes for subnet routing
   in most circumstances, not a requirement for such.  To further
   clarify the relationship, the document also provides operational
   guidance for the configuration of subnet prefixes and updates
   RFC 4291 accordingly.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Discussion

2.1.  Two Forms of Subnet Prefixes and Interface Identifiers

   The IPv6 Addressing Architecture [RFC4291], Section 2.5, paragraph 4,
   and the diagram following it, define the structure of IPv6 unicast
   addresses and the relationship between the general form of subnet
   prefixes and interface identifiers.  With the diagram implying at
   least in this general form, that subnet prefixes have any length
   between 0 and a 128 bits, inclusive.  Further, it implies that the
   general form of interface identifiers are independent of any specific
   length and are defined only by the length of their associated subnet
   prefix.

      A slightly sophisticated host (but still rather simple) may
      additionally be aware of subnet prefix(es) for the link(s) it is

Farmer                    Expires July 3, 2019                  [Page 3]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

      attached to, where different addresses may have different values
      for n:

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

   The idea that this paragraph is referring to a general form of subnet
   prefixes and interface identifiers and they are independent of any
   specific length is reinforced by the fact this text is unchanged from
   the text in RFC 1884 [RFC1884], Section 2.4.  Where in this earlier
   revision of the IPv6 Addressing Architecture, 48-bit interface
   identifiers were expected to be common.

   The IPv6 Addressing Architecture [RFC4291], Section 2.5.1, goes on to
   further define additional properties of the general form of interface
   identifiers, that are independent of any specific length.  Simply
   put, in their general form interface identifiers are the right-hand
   portion of IPv6 unicast addresses that uniquely identifies the
   interface of a node within a subnet prefix on a link, regardless of
   the length of the subnet prefix, which in turn are the left-hand
   portion of IPv6 unicast addresses.

      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.  In some cases, an
      interface's identifier will be derived directly from that
      interface's link-layer address.  The same interface identifier may
      be used on multiple interfaces on a single node, as long as they
      are attached to different subnets.

      Note that the uniqueness of interface identifiers is independent
      of the uniqueness of IPv6 addresses.  For example, a Global
      Unicast address may be created with a local scope interface
      identifier and a Link-Local address may be created with a
      universal scope interface identifier.

   However, when the IPv6 Addressing Architecture [RFC4291],
   Section 2.5.1, paragraph 3, defines the length of interface
   identifiers as 64 bits, it is also effectively creating a distinct
   standard form of interface identifiers, differentiated from the
   general form which is independent of any specific length.

Farmer                    Expires July 3, 2019                  [Page 4]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

      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.

   RFC 7136 [RFC7136] updates and RFC 8064 [RFC8064] effectively
   deprecates the requirement that interface identifiers are constructed
   in Modified EUI-64 format.  However, the original RFC 4291 version of
   the text is quoted above as it helps to explain and develop the idea
   that a distinct standard form of interface identifiers is being
   created as opposed to merely defining additional properties of all
   interface identifiers in general.  Several of the paragraphs
   following the above, discuss the details of "Modified EUI-64 format-
   based interface identifiers", seeming to imply that not all interface
   identifiers are in this format and distinguishing them from not only
   general form interface identifiers but even from other standard form
   interface identifiers that are 64 bits in length.

   Furthermore, the IPv6 Addressing Architecture [RFC4291],
   Section 2.5.4, paragraph 2, itself effectively distinguishes between
   the standard and general forms of interface identifiers based on if
   the unicast address starts with the binary value 000.

      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.5.1.  Global Unicast addresses
      that start with binary 000 have no such constraint on the size or
      structure of the interface ID field.

   With all that, the idea that the 64-bit length and the Modified
   EUI-64 format are fundamental properties of all interface identifiers
   in general, seems like a stretch and a more logical interpretation is
   that interface identifiers come in multiple forms, some with a
   standard 64-bit length, some even more specifically in Modified
   EUI-64 format, and others are independent of any specific length.
   Thus, when the IPv6 Addressing Architecture defines interface
   identifiers as being 64 bits in length, it is effectively creating a
   distinct standard form of interface identifiers differentiated from
   the general form of interface identifiers which are independent of
   any specific length.

   Finally, as a result of the tightly coupled relationship between
   subnet prefixes and interface identifiers, creating a standard form
   of interface identifiers also implies the creation of a standard form
   of subnet prefixes that are also 64 bits in length.

Farmer                    Expires July 3, 2019                  [Page 5]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

2.2.  How the Two Forms are Used

   Many aspects of the IPv6 specifications based or assume on these
   standard form of subnet prefixes and interface identifiers.  Most
   notably, Stateless Address Autoconfiguration (SLAAC) [RFC4862] which
   autonomously configures IPv6 addresses that are constructed by
   generating standard form interface identifiers that are combined with
   standard form subnet prefixes.  These subnet prefixes are advertised
   by routers and are learned by hosts through IPv6 ND RA messages
   containing PIOs with the autonomous address-configuration (A) flag
   set.

   As discussed in SLAAC [RFC4862], Section 5.5.3, bullet d, PIOs with
   the A flag set are validated against a single interface identifier
   length.  However, SLAAC itself does not define the interface
   identifier length used or assume it is 64 bits in length.  SLAAC
   utilizes the interface identifier length defined in separate
   link-type specific documents that are intended to be consistent with
   the standard form interface identifier specified in the IPv6
   Addressing Architecture.

      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]...

   Furthermore, there are currently no IPv6 link-type specific documents
   that specify an interface identifier length other than 64 bits.
   Therefore, SLAAC effectively requires standard form interface
   identifiers that are 64 bits in length, reinforcing the idea that
   autonomous address-configuration is based on standard form subnet
   prefixes and interface identifiers.

   Beyond SLAAC, RFC 7421 [RFC7421], Section 4.1, lists many of the
   other aspects of the IPv6 specifications that assume or depend on the
   standard form of subnet prefixes and interface identifiers.
   Furthermore, the IPv6 Addressing Architecture itself intends that
   most unicast addresses and all Link-Local addresses are formatted and
   assigned based on these standard forms of subnet prefixes and
   interface identifiers.  Finally, a rationale for using a single
   standard form interface identifier length is also provided in
   RFC 7421, Section 2.

   However, as discussed in IPv6 ND [RFC4861], Section 5.2, and further
   clarified in the IPv6 Subnet Model [RFC5942], subnet routing and on-
   link determination depend on the general form subnet prefixes to

Farmer                    Expires July 3, 2019                  [Page 6]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   determine the addresses that are deliverable using a node's attached
   interfaces.  These subnet prefixes are normally advertised by routers
   and learned by hosts through ND RA messages containing PIOs but with
   the on-link (L) flag set, or through the manual configuration of on-
   link prefixes directly on hosts and routers.

   Although unlike SLAAC that validates PIOs with the A flag set, as
   discussed in IPv6 ND [RFC4861], Section 6.3.4, PIOs with the L flag
   set, or manually configured on-link prefixes, are not validated
   against any particular subnet prefix length or interface identifier
   length.

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

   This is confirmed by SLAAC [RFC4862], Section 5.5.3, bullet d, where
   it says;

      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]...

   Therefore, these subnet prefixes have any length 0 to 128 bits,
   inclusive, reinforcing the idea that subnet routing and on-link
   determination are based on the general form of subnet prefixes.  This
   is further reinforced by BCP 198 [RFC7608] which says;

      Decision-making processes for forwarding MUST NOT restrict the
      length of IPv6 prefixes by design.  In particular, forwarding
      processes MUST be designed to process prefixes of any length up to
      /128, by increments of 1.

2.3.  Conclusion

   Despite the fact that IPv6 routing, including both subnet routing and
   on-link determination, is based on the general form of subnet
   prefixes, with any length 0 to 128 bits, inclusive, being valid, most
   other aspects of the IPv6 specifications assume or depend on the
   standard form of subnet prefixes and interface identifiers, both 64
   bits in length.  As a consequence, when standard form subnet prefixes
   are not also configured for subnet routing, there is a risk some IPv6
   features will produce unpredictable results and others will not work
   outright.  RFC 7421 [RFC7421], Section 4.2, discusses some of these
   situations.

Farmer                    Expires July 3, 2019                  [Page 7]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   Therefore, for consistency with the 64-bit boundary and most other
   aspects of the IPv6 specifications, standard form subnet prefixes,
   that is /64 subnet prefixes, are RECOMMENDED for subnet routing in
   most circumstances.  The formal exceptions to this recommendation are
   subnet prefixes that begin with the binary value 000 and inter-router
   point-to-point links with 127-bit prefixes [RFC6164].

   In conclusion, the proper characterization of the relationship
   between IPv6 routing and the 64-bit boundary in the IPv6 Addressing
   Architecture is that of a recommendation for the use of /64 subnet
   prefixes for subnet routing in most circumstances, not a requirement
   for such.  To further clarify the relationship, the remainder of this
   document updates RFC 4291 based on this discussion and provides
   operational guidance for the configuration of subnet prefixes
   consistent with this recommendation.

3.  Updates to RFC 4291

   Based on the discussion in Section 2, IPv6 Addressing Architecture
   [RFC4291], Section 2.5.1, paragraph 3, is updated by replacing it
   with the following;

      Standard Interface Identifiers are REQUIRED to be 64 bits long
      except if the first three bits of the unicast address are 000.
      The rationale for using for a single Standard Interface Identifier
      length can be found in RFC 7421 [RFC7421].  The Standard Interface
      Identifier length only implies a recommendation as to the subnet
      prefix lengths that are valid for routing in most circumstances.

   The term "Interface IDs" has been changed to "Standard Interface
   Identifiers" to distinguish the standard form of interface
   identifiers from the general form that is independent of any specific
   length, per RFC 8064 [RFC8064] the requirement that standard form
   interface identifiers are constructed in Modified EUI-64 format has
   been removed, and the sentence has also been rearranged.  Two
   additional sentences have been added to the paragraph; the first,
   referring to RFC 7421 for the rationale for using a Standard
   Interface Identifier length, and the second, clarifying the
   relationship between IPv6 routing and the 64-bit boundary without
   removing the requirement for other aspects of IPv6 to use 64-bit
   interface identifiers.

4.  Operational Guidance for the Configuration of Subnet Prefixes

   Unlike IPv4 where there is a single subnet mask parameter configured
   both on hosts and routers, with the two aspects of a subnet, address
   assignment and on-link determination, tightly coupled together; in
   IPv6 these two aspects of a subnet are split into two independent

Farmer                    Expires July 3, 2019                  [Page 8]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   parameters that are configured together or separately and normally
   only configured on routers.  These two parameters are defined and
   discussed in detail by IPv6 ND [RFC4861] and further clarified in the
   IPv6 Subnet Model [RFC5942].  Briefly, as discussed in Section 2.2,
   these two parameters are normally advertised by routers and learned
   by hosts through IPv6 ND RA messages containing PIOs with the
   autonomous address-configuration (A) flag and/or the on-link (L) flag
   set, or through the manual configuration of on-link prefixes directly
   on hosts.  This Section provides operational guidance for
   configuration of these two parameters by both means.

   As discussed in the IPv6 Node Requirements [RFC6434], Section 5.9,
   all hosts are required to support SLAAC for the configuration of IPv6
   unicast addresses, whereas hosts are not required to support the
   other mechanisms, such as the Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6) [RFC8415] or even manual configuration.  As a
   consequence, unless an IPv6 ND RA messages containing a PIO with the
   A flag set are advertised on a link, it is possible that some hosts
   will not be able to configure an IPv6 address for that link, other
   than a Link-Local address, additional consequences for the security
   and privacy of IPv6 users are discussed in Section 6.  Further, the
   most efficient way for two hosts in the same subnet to communicate is
   directly between each other on the common link between them, or in
   other words on-link.  Finally, as discussed in Section 2.2 and 2.3,
   /64 subnet prefixes are required for SLAAC and recommended for subnet
   routing and on-link determination in most circumstances.

   Therefore, routers SHOULD be configured to send IPv6 ND RA messages
   containing at least one /64 PIO with both the A and L flags set on
   each of a router's links.  Unless it is known that all host connected
   to a link support an IPv6 address configuration mechanism other than
   SLAAC and that mechanism has been configured for each host or direct
   communication between hosts on the same subnet is not desired.

   More operationally, when configuring these two parameters on a
   router, /64 PIOs are REQUIRED for all PIOs with the A flag set.
   Furthermore, /64 PIOs with both the A and L flags set are
   RECOMMENDED.  Finally, /64 PIOs are RECOMMENDED for all PIOs with the
   L flag set and /64 on-link prefixes are RECOMMENDED when manually
   configured on hosts and routers, except for subnet prefixes that
   begin with the binary value 000 and inter-router point-to-point links
   with 127-bit prefixes [RFC6164].

      Note: Typically when manually configuring an address on a host an
      on-link prefix length may also be included.  If not included, or
      possibly if the prefix length is /128, this effectively signifies
      that only an address is being manually configured on the interface
      and no on-link prefix has been configured for the interface.

Farmer                    Expires July 3, 2019                  [Page 9]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   As recommended above, /64 PIOs with both the A and L flags set are
   most often configured in practice; this is the default behavior for
   many routers.  However, /64 PIOs with only the A or L flag set, or
   the manual configuration of /64 on-link prefixes on hosts, are
   consistent with the IPv6 Addressing Architecture and they simply
   represent different configuration options for /64 subnet prefixes.
   While these options are not as frequently used, they are still valid
   configurations, and their use is considered normal practice under the
   proper circumstances.  If the A flag is not set, this means, SLAAC is
   not used to configure addresses for hosts on the subnet.  If the L
   flag is not set, this means, none of the addresses for the subnet are
   on-link from a hosts perspective and traffic is not sent directly to
   other hosts, but all traffic is sent to a router first.  Finally, if
   hosts are manually configured with on-link prefixes, then a router is
   not required on the link, at least for configuration purposes.

      Note: regardless if a router advertises a PIO, with the A or L
      flags set, the router itself MUST be configured with the on-link
      prefixes for all subnets on all the links it is connected to, this
      could be via manual configuration or another mechanism.  Two, or
      more, routers connected to the same link could have the same PIO
      with different flags set, each PIO is evaluated separately for
      each function, therefore effectively the sum of the flags across
      all identical PIOs are used.  Finally, a router MAY send an ND
      Redirect message for an address for which a PIO with the L flag
      set has not been advertised, any subsequent traffic for that
      address will be sent directly to that host instead of the router
      first.

4.1.  Subnet Prefixes Other Than /64

   In most circumstances, the use of subnet prefixes other than /64 are
   inconsistent with the IPv6 Addressing Architecture, are generally
   considered bad practice, and are NOT RECOMMENDED.  Furthermore,
   subnet prefixes other than /64 MUST NOT be used unless it is known
   that all nodes on a link do not need any IPv6 features that depend on
   /64 subnet prefixes or 64-bit Standard Interface Identifiers.
   RFC 7421 [RFC7421], Section 4.1, provides a non-exhaustive list of
   IPv6 features that depend on 64-bit Standard Interface Identifiers.
   RFC 5375 [RFC5375], Appendix B, discusses considerations for use of
   subnet prefixes other than /64, although some of the advice has been
   obsoleted by RFC 6164 [RFC6164] and RFC 7136 [RFC7136].

   Using subnet prefixes other than /64 for links servicing general-
   purpose end hosts seems like an especially bad idea, it is usually
   difficult to predict what IPv6 features such hosts will need,
   especially their future needs, therefore it seems doubtful the above
   conditions can be met for such hosts.  Whereas more tightly-

Farmer                    Expires July 3, 2019                 [Page 10]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   controlled infrastructure such as routers or special-purpose servers
   can have their needs better understood, and while still not
   recommended, it seems plausible that the above conditions could be
   met in their case.

   Again more operationally, the configuration of PIOs of any length
   other than /64, or the manual configuration of on-link prefixes other
   than /64, are NOT RECOMMENDED except for subnet prefixes that begin
   with the binary value 000 and inter-router point-to-point links with
   127-bit prefixes [RFC6164].  Furthermore, PIOs of any length other
   than /64 with the A flag set are invalid and a configuration error,
   they will not result in the auto-configuration of an address.  PIOs
   of any length other than /64 with the L flag set, or the manual
   configuration of on-link prefixes of any length other than /64, while
   they are NOT RECOMMENDED in most circumstances, they are still valid
   for routing.

      Note: the combination a PIO of /65 or longer with the L flag set
      and a covering /64 PIO with only the A flag set, configures a /64
      subnet prefix but with only part of the subnet considered on-link
      and the rest of the subnet not considered on-link.  This
      particular configuration, while technically valid, can be
      operationally challenging and problematic.  With this
      configuration a host on the same link and subnet could behave
      differently from another host on the same link and subnet, this
      can be confusing and difficult to troubleshoot.  Therefore in
      practice, this configuration is best avoided.

5.  IANA Considerations

   This document includes no request to IANA.

6.  Security Considerations

   This document clarifies the relationship between IPv6 routing and the
   64-bit boundary in the IPv6 Addressing Architecture.  Further, it
   provides operational guidance for the configuration of subnet
   prefixes.  The guidance and clarifications provided are not expected
   to introduce any new security considerations.

   However, if there is not a subnet prefix advertised with at least one
   /64 PIO with the A flag set on each link network, several techniques
   that are intended to increase the security and privacy of IPv6 users
   will be impacted negatively, specifically RFC 3972 [RFC3972],
   RFC 4941 [RFC4941], and RFC 7217 [RFC7217].  These techniques require
   the use of SLAAC, hence the recommendation to configure /64 PIOs with
   the A flag set in most circumstance.  Further, the use of subnet
   prefixes longer than /64 effectively creates smaller subnets making

Farmer                    Expires July 3, 2019                 [Page 11]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   it more feasible to perform IPv6 address scans.  These and other
   related security and privacy considerations are discussed in RFC 7707
   [RFC7707] and RFC 7721 [RFC7721].

   Nevertheless, the use of smaller subnets can provide effective
   mitigation for neighbor cache exhaustion issues as discussed in
   RFC 6164 [RFC6164] and RFC 6583 [RFC6583].  The relative weights
   applied in these trade-offs will vary from situation to situation.

7.  Acknowledgments

   This document was inspired by a series of discussions on the 6MAN and
   the V6OPS working group mailing lists over several years, including
   discussions around the following; [RFC7421], BCP 198 [RFC7608],
   [I-D.jinmei-6man-prefix-clarify], [I-D.bourbaki-6man-classless-ipv6],
   [I-D.jaeggli-v6ops-indefensible-nd], and
   [I-D.farmer-6man-exceptions-64].  All revolving around the discussion
   of [RFC4291bis] and its advancement to Internet Standard.

   This document was produced using the xml2rfc tool [RFC2629].

   The author would like to thank Tatuya Jinmei and Ole Troan for
   particularly useful comments on and discussion of
   [I-D.farmer-6man-exceptions-64] that directly inspired the creation
   of this document.

   The author would like to thank the following, in alphabetical order,
   for their contributions and comments:

      Brian Carpenter

8.  Change log [RFC Editor: Please remove]

   draft-farmer-6man-routing-64-00, 2018-December-30:

   *Original version.

   draft-farmer-6man-routing-64-01, 2018-December-30:

   *Fixed typos and other editorial changes
   *Added missing "to" to the Title.
   *Reduced some wordiness in the Abstract and Intro
   *Corrected quote of RFC4291, Section 2.5, paragraph 4, the previous
    was from RFC4291bis.
   *Further developed the argument for standard form of interface
    identifiers.
   *Further clarified the intent of the change to RFC4291.

Farmer                    Expires July 3, 2019                 [Page 12]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC5942]  Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
              Model: The Relationship between Links and Subnet
              Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010,
              <https://www.rfc-editor.org/info/rfc5942>.

   [RFC6164]  Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
              L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
              Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
              <https://www.rfc-editor.org/info/rfc6164>.

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", RFC 6434, DOI 10.17487/RFC6434, December
              2011, <https://www.rfc-editor.org/info/rfc6434>.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <https://www.rfc-editor.org/info/rfc7136>.

   [RFC7608]  Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
              Length Recommendation for Forwarding", BCP 198, RFC 7608,
              DOI 10.17487/RFC7608, July 2015,
              <https://www.rfc-editor.org/info/rfc7608>.

Farmer                    Expires July 3, 2019                 [Page 13]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              RFC 8064, DOI 10.17487/RFC8064, February 2017,
              <https://www.rfc-editor.org/info/rfc8064>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

9.2.  Informative References

   [I-D.bourbaki-6man-classless-ipv6]
              Bourbaki, N., "IPv6 is Classless", draft-bourbaki-6man-
              classless-ipv6-04 (work in progress), September 2018.

   [I-D.farmer-6man-exceptions-64]
              Farmer, D., "Exceptions to the Standard Subnet Boundary in
              IPv6 Addressing", draft-farmer-6man-exceptions-64-09 (work
              in progress), August 2018.

   [I-D.jaeggli-v6ops-indefensible-nd]
              Jaeggli, J., "Indefensible Neighbor Discovery", draft-
              jaeggli-v6ops-indefensible-nd-01 (work in progress), July
              2018.

   [I-D.jinmei-6man-prefix-clarify]
              Jinmei, T., "Clarifications on On-link and Subnet IPv6
              Prefixes", draft-jinmei-6man-prefix-clarify-00 (work in
              progress), March 2017.

   [RFC1884]  Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
              Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
              December 1995, <https://www.rfc-editor.org/info/rfc1884>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <https://www.rfc-editor.org/info/rfc2629>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,
              <https://www.rfc-editor.org/info/rfc3972>.

Farmer                    Expires July 3, 2019                 [Page 14]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   [RFC4291bis]
              Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", draft-ietf-6man-rfc4291bis-09 (work in
              progress), July 2017,
              <https://tools.ietf.org/id/draft-ietf-6man-rfc4291bis>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC5375]  Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
              and C. Hahn, "IPv6 Unicast Address Assignment
              Considerations", RFC 5375, DOI 10.17487/RFC5375, December
              2008, <https://www.rfc-editor.org/info/rfc5375>.

   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583,
              DOI 10.17487/RFC6583, March 2012,
              <https://www.rfc-editor.org/info/rfc6583>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC7421]  Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
              Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
              Boundary in IPv6 Addressing", RFC 7421,
              DOI 10.17487/RFC7421, January 2015,
              <https://www.rfc-editor.org/info/rfc7421>.

   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
              <https://www.rfc-editor.org/info/rfc7707>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <https://www.rfc-editor.org/info/rfc7721>.

Author's Address

Farmer                    Expires July 3, 2019                 [Page 15]
Internet-Draft    IPv6 Routing and the 64-bit Boundary     December 2018

   David Farmer
   University of Minnesota
   Office of Information Technology
   2218 University Ave SE
   Minneapolis, MN  55414
   US

   Phone: +16126260815
   Email: farmer@umn.edu
   URI:   http://www.umn.edu/

Farmer                    Expires July 3, 2019                 [Page 16]