Internet DRAFT - draft-farmer-6man-exceptions-64

draft-farmer-6man-exceptions-64







6man Working Group                                             D. Farmer
Internet-Draft                                        Univ. of Minnesota
Intended status: Standards Track                          August 9, 2018
Expires: February 10, 2019


     Exceptions to the Standard Subnet Boundary in IPv6 Addressing
                   draft-farmer-6man-exceptions-64-09

Abstract

   This document clarifies exceptions to the standard subnet boundary in
   IPv6 addressing.  The exceptions include unicast IPv6 addresses with
   the first three bits 000, manually configured addresses, DHCPv6
   assigned addresses, IPv6 on-link determination, and the possibility
   of an exception specified in separate IPv6 link-type specific
   documents.  Further, operational guidance is provided, and Appendix A
   discusses the valid options for configuring the parameters of an IPv6
   subnet.

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 February 10, 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
   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



Farmer                  Expires February 10, 2019               [Page 1]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   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 . . . . . . . . . . . . . . . . . .   4
   2.  Exceptions to the Standard Subnet Boundary  . . . . . . . . .   4
     2.1.  Unicast Addresses with the First Three Bits 000 . . . . .   4
     2.2.  Manually Configured Addresses . . . . . . . . . . . . . .   5
     2.3.  DHCPv6 Assigned Addresses . . . . . . . . . . . . . . . .   5
     2.4.  IPv6 On-link Determination  . . . . . . . . . . . . . . .   6
     2.5.  IPv6 Link-type Specific Documents . . . . . . . . . . . .   6
   3.  Operational Guidance  . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Change log [RFC Editor: Please remove]  . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Options for Configuring IPv6 Subnets . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   The standard subnet boundary in IPv6 addressing provides the basis
   for unicast addresses to be autonomously generated, using stateless
   address auto-configuration (SLAAC) [RFC4862], and assigned to
   interfaces on host.  SLAAC allows hosts to connect to link networks
   without any pre-configuration, which is especially useful for
   general-purpose hosts and mobile devices.  In this circumstance,
   unicast addresses have an internal structure composed of standard
   64-bit interface identifiers (IIDs) and therefore 64-bit subnet
   prefixes, as described in the IPv6 Addressing Architecture [RFC4291]
   Section 2.5.  For additional discussion of the standard subnet
   boundary in IPv6 addressing see RFC 7421 [RFC7421].

   However, in other circumstances, such as with manually configured
   addresses or DHCPv6 [RFC3315] assigned addresses, unicast addresses
   are assigned to interfaces on nodes as opaque 128-bit quantities
   without any knowledge of the internal structure or the subnets
   present on the link network.  These circumstances are also described
   in IPv6 Addressing Architecture [RFC4291] Section 2.5, "a node may
   consider that unicast addresses (including its own) have no internal
   structure."




Farmer                  Expires February 10, 2019               [Page 2]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   Further, unlike IPv4 where there is a single subnet mask parameter
   with the two aspects of a subnet, address assignment and on-link
   determination, tightly coupled together, while in IPv6 they are split
   into two logically separate parameters serving the two aspects
   independently.  The subnet assignment prefix is used for performing
   autonomous address assignment by SLAAC.  Separately, the on-link
   prefix is used to determine if an address can be delivered using a
   directly connected link network.  IPv6 Neighbor Discovery (ND)
   [RFC4861], the IPv6 Subnet Model [RFC5942], and SLAAC [RFC4862]
   describe and specify the use of these parameters in detail.

   Briefly, unicast addresses assigned to interfaces on nodes are not
   considered on-link unless covered by an on-link prefix advertised
   through ND Router Advertisement (RA) messages containing Prefix
   Information Options (PIOs) with the on-link (L) flag set or by manual
   configuration.  Whereas autonomous address assignment uses subnet
   assignment prefixes that are also advertised through the same ND RA
   messages and PIOs but with the autonomous (A) flag set instead.
   While they act independently, most frequently subnets are configured
   using subnet assignment prefixes with identical on-link prefixes, see
   Appendix A for further decision of this and the other valid options
   for configuring the parameters of an IPv6 subnet.  However, unlike
   subnet assignment prefixes, which are effectively required to be 64
   bits in length, on-link prefixes may have any length between 0 and
   128 bits, inclusive.  Nevertheless, for consistency with the standard
   subnet boundary, 64-bit on-link prefix lengths are recommended in
   most circumstances.

   Reinforcing the ideas that on-link prefixes are logically separate
   and may have any length.  On-link prefixes are part of the next-hop
   determination process, described in IPv6 ND [RFC4861] Section 5.2,
   which is intrinsically part of routing and forwarding within IPv6,
   and BCP 198 [RFC7608] says, "forwarding processes MUST be designed to
   process prefixes of any length up to /128, by increments of 1."

   Finally, SLAAC is currently designed to utilize a single IID length
   to validate the length of the subnet assignment prefixes provided to
   it.  However, SLAAC itself does not define the IID length or assume
   it is 64 bits in length.  It utilizes the IID length defined in
   separate link-type specific documents that are intended to be
   consistent with the standard 64-bit IID length specified in the IPv6
   Addressing Architecture [RFC4291] Section 2.5.1.  While this is a
   possible exception to the standard subnet boundary, currently there
   are no IPv6 link-type specific documents that specify an IID length
   other than 64 bits.  Effectively requiring 64-bit IIDs and therefore
   64-bit subnet assignment prefixes are used for performing autonomous
   address assignment by SLAAC.




Farmer                  Expires February 10, 2019               [Page 3]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   In summary, the essential theory of this document is that the two
   parameters that define IPv6 subnets, the subnet assignment prefix and
   the on-link prefix, interact with the standard subnet boundary in
   subtle but complex ways.  IPv6 subnets are primarily configured using
   subnet assignment prefixes and when they are used IPv6 subnets and
   IIDs are both effectively required to be 64 bits in length.  However,
   it is also possible to configure IPv6 subnets solely using on-link
   prefixes, which may have any length between 0 and 128 bits,
   inclusive.  Nevertheless, for consistency with the standard subnet
   boundary, 64-bit on-link prefix lengths are recommended in most
   circumstances.  Therefore, when IPv6 subnets are configured solely
   using on-link prefixes, IPv6 subnets and IIDs are both only
   recommended to be 64 bits in length.

   By clarifying the following exceptions to the standard subnet
   boundary and providing clear operational guidance, this document
   intends to provide clarity to and a better understanding of this
   subtle but complex interaction between the standard subnet boundary
   in IPv6 addressing and how IPv6 subnets are defined and implemented
   by the protocols in question.

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.  Exceptions to the Standard Subnet Boundary

2.1.  Unicast Addresses with the First Three Bits 000

   These are all currently special-purpose IPv6 addresses or are
   otherwise reserved.  Also, they are generally not assigned to
   interfaces on hosts, especially not to general-purpose hosts.
   Examples of these addresses are the unspecified address, the loopback
   address, and the IPv4-Mapped IPv6 Address from RFC 4291 [RFC4291]
   Sections 2.5.2, 2.5.3, and 2.5.5.2 respectively.

   Most of these addresses have no internal structure and are considered
   opaque 128-bit quantities.  However, some of these addresses could be
   presumed to have structure, such as the IPv4-mapped IPv6 address.
   This structure comes from embedding an IPv4 address within an IPv6
   address, but this structure is unrelated to and different from the
   internal structure, composed of standard IIDs and subnets created by
   the standard subnet boundary.




Farmer                  Expires February 10, 2019               [Page 4]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   Historically, reservations were also made in this range for the
   mapping of OSI NSAP and IPX address into IPv6 addresses.  They had
   structures similar to the IPv4-mapped IPv6 address discussed above.
   However, they have since been deprecated.

      Note: ever since RFC 2373 [RFC2373] addresses with the first three
      bits 000 have been an exception to the standard subnet boundary,
      and addresses with the first three bits 001 through 111, except
      for multicast addresses, have been expected to be consistent with
      the standard 64-bit IID length and the standard subnet boundary.
      However, currently only 2000::/3 has been allocated as global
      unicast address space and released to the IANA for distribution to
      the Regional Internet Registries (RIRs).  The applicability of the
      standard subnet boundary to future allocations will be determined
      at the time the allocations are release to the IANA.
      Nevertheless, implementations of IPv6 should assume the standard
      subnet boundary applies to future allocations and that 2000::/3 is
      not special in this regard.

2.2.  Manually Configured Addresses

   IPv6 addresses manually configured on a node's interface, sometimes
   known as statically configured, are an exception to the standard
   subnet boundary as they are considered opaque 128-bit quantities and
   are assigned to node interfaces without any knowledge of the internal
   structure or the subnets present on the link network.

   Manually configured addresses MAY also include an associated on-link
   prefix length.  This on-link prefix length (n) MAY have any value
   between 0 and 128 bits, inclusive.  If an on-link prefix length is
   included, the most significant, or leftmost, n bits of the manually
   configured address are considered the on-link prefix.  Otherwise, if
   an on-link prefix length is not included, an on-link prefix MUST NOT
   be automatically assumed, but an on-link prefix may be learned from a
   PIO with the L flag set.  Nevertheless, for consistency with the
   standard subnet boundary, 64-bit on-link prefix lengths are
   recommended in most circumstances.  See Section 3 for operational
   guidance regarding on-link prefix lengths.

2.3.  DHCPv6 Assigned Addresses

   IPv6 addresses assigned to a host's interface via DHCPv6 [RFC3315]
   (Identity Association for Non-temporary Addresses (IA_NA) or Identity
   Association for Temporary Addresses (IN_TA)) are an exception to the
   standard subnet boundary as they are considered opaque 128-bit
   quantities and are assigned to host interfaces without any knowledge
   of the internal structure or the subnets present on the link network.
   Further, DHCPv6 assigned addresses MUST NOT automatically assume an



Farmer                  Expires February 10, 2019               [Page 5]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   on-link prefix, but an on-link prefix may be learned from a PIO with
   the L flag set.

2.4.  IPv6 On-link Determination

   IPv6 on-link determination is an exception to the standard subnet
   boundary, in that IPv6 ND [RFC4861] does not require on-link prefixes
   to be 64 bits in length.  To the contrary, on-link prefixes MAY have
   any length between 0 and 128 bits, inclusive.  Nevertheless, for
   consistency with the standard subnet boundary, 64-bit on-link prefix
   lengths are recommended in most circumstances.  See Section 3 for
   operational guidance regarding on-link prefix lengths.

2.5.  IPv6 Link-type Specific Documents

   Separate IPv6 link-type specific documents, sometimes known as
   "IPv6-over-FOO" documents, specify the IID length utilized by SLAAC
   to validate the length of subnet assignment prefixes provided.  The
   IID length defined SHOULD be consistent with the standard 64-bit IID
   length specified in the IPv6 Addressing Architecture [RFC4291].
   However, these documents may create an exception to the standard
   64-bit IID length scoped to a specific link-type technology when
   justified.  Although currently, there are no IPv6 link-type specific
   documents that specify an IID length other than 64 bits.

   When an exception to the standard 64-bit IID is specified in a
   link-type specific document, valid justification needs to be
   documented in some detail.

   Further, SLAAC is currently designed to validate against only a
   single IID length per link-type technology.  As a result, a link-type
   technology that specifies a non-standard IID length cannot be
   directly bridged with another link-type technology that specifies the
   standard 64-bit IID length without creating confusion about the IID
   length that is to be used for validation.  Therefore, if this type of
   direct bridging is allowed, then a mechanism to ensure there is no
   confusion about which IID length SLAAC is to validate against needs
   to be provided.

3.  Operational Guidance

   At a high-level, this document recommends the following principles
   for the configuration of IPv6 subnets.  The configuration of subnet
   assignment prefixes is recommended, allowing hosts to use autonomous
   address assignment.  With this configuration, subnet assignment
   prefixes are required to be 64 bits in length, requiring 64-bit
   subnets in this circumstance.  Further, identical on-link prefixes
   are recommended, but on-link prefixes are required to be 64 bits or



Farmer                  Expires February 10, 2019               [Page 6]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   shorter.  Otherwise, if a subnet assignment prefix is not configured,
   then hosts will have to use manually configured addresses or DHCPv6
   assigned addresses and these subnets are solely configured by on-link
   prefixes.  These on-link prefixes are recommended to be 64 bits in
   length, therefore only recommending 64-bit subnets in this
   circumstance.  There are two exceptions to these principles, the
   possible future specification of a link-type specific document based
   on an IID length that is not 64 bits and inter-router point-to-point
   links with 127-bit prefixes [RFC6164].  Further, each subnet must be
   configured on a single link network and must not overlap subnets on
   other link networks.

   More formally;

      Network operators SHOULD configure routers to advertise to each
      link network at least one subnet assignment prefix (a PIO with the
      A flag set).  If a subnet assignment prefix is advertised, it MUST
      be (128 - N) bits in length, and an identical on-link prefix (a
      PIO with the L flag set) SHOULD also be advertised.  If an on-link
      prefix is advertised and is covered by a subnet assignment prefix,
      the on-link prefix MUST NOT be longer than (128 - N) bits in
      length.

      Otherwise, if a subnet assignment prefix is not advertised,
      network operators SHOULD configure routers to advertise to each
      link network at least one on-link prefix (a PIO with the L flag
      set) that is (128 - N) bits in length or provide the same manually
      configured on-link prefix to each node on the link network that is
      (128 - N) bits in length.

      Where N = 64 or the IID length specified in the link-type specific
      document for the link network in question.

      Alternatively, network operators MAY configure point-to-point
      router links with on-link prefixes that SHOULD be 127 bits in
      length, typically by manual configuration, and with no subnet
      assignment prefix.  See RFC 6164 [RFC6164] Section 6 for address
      selection considerations.

      Further, each on-link prefix and each subnet assignment prefix
      MUST be uniquely configured on a single link network and MUST NOT
      overlap on-link prefixes or subnet assignment prefixes configured
      on any other link networks.  On-link prefixes MAY overlap subnet
      assignment prefixes configured on the same link network.

   Appendix A discusses in further detail the valid options for
   configuring the parameters of IPv6 subnet.




Farmer                  Expires February 10, 2019               [Page 7]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


4.  IANA Considerations

   This document includes no request to IANA.

5.  Security Considerations

   This document clarifies exceptions to the standard subnet boundary in
   IPv6 addressing.  These clarifications are not security related and
   therefore are not expected to introduce any new security
   considerations.

   The use of subnets solely configured by on-link prefixes negatively
   impacts techniques that are intended to increase the security and
   privacy of users RFC 4941 [RFC4941] and RFC 7217 [RFC7217], as they
   depend on the use of SLAAC, hence the recommendation to configure
   subnet assignment prefixes allowing the use of SLAAC.  Further, the
   use of subnets solely configured by on-link prefixes also permits
   longer on-link prefixes effectively allowing smaller subnets and
   making 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].

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

6.  Acknowledgments

   This document was inspired by a series of discussions on the 6MAN and
   the V6OPS working group mailing lists over a period of approximately
   two years, including discussions around the following drafts;
   [I-D.jinmei-6man-prefix-clarify], [I-D.bourbaki-6man-classless-ipv6],
   and [I-D.jaeggli-v6ops-indefensible-nd].  All revolving around the
   discussion of RFC 4291bis [RFC4291bis] and its advancement to
   Internet Standard.

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

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

      Brian Carpenter, Bruce Curtis, Fernando Gont, Craig Miller,
      Alexandre Petrescu, and Tatuya Jinmei







Farmer                  Expires February 10, 2019               [Page 8]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


7.  Change log [RFC Editor: Please remove]

   draft-farmer-6man-exceptions-64-09, 2018-August-9:

   o  Another try on formatting changes

   draft-farmer-6man-exceptions-64-08, 2018-August-9:

   o  Another try on formatting changes

   draft-farmer-6man-exceptions-64-07, 2018-August-9:

   o  Formatting changes

   draft-farmer-6man-exceptions-64-06, 2018-August-9:

   o  Added to the note in Section 2.1, about the applicability of
      standard subnet boundary to future allocations.
   o  Wordsmithed the two exceptions in the formal guidance.
   o  Added a subnet uniqueness requirement in the operational guidance.
   o  Other miscellaneous editorial changes.

   draft-farmer-6man-exceptions-64-05, 2018-August-6:

   o  Fixed typo in organization tag from version 4

   draft-farmer-6man-exceptions-64-04, 2018-August-6:

   o  Changed references for RFC4291bis to RFC4291 except in
      Acknowledgments
   o  Missed a 64-bit boundary, changing it to standard subnet boundary,
      in the note in Section 2.1.
   o  Added that only 2000::/3 has bee release for allocations, in the
      note in Section 2.1.
   o  Other miscellaneous editorial changes and typos fixed.
   o  Changes to Author's address

   draft-farmer-6man-exceptions-64-03, 2018-August-3:

   o  Several editorial changes to manual configuration and DHCPv6
      sections
   o  Changed 64-bit boundary to standard subnet boundary in the title
      and through the document.
   o  Several editorial changes to the operational guidance section and
      changed from 64-bit to 128-N and N=64 in the formal guidance.
   o  Added titles for the M and O flags.
   o  Other miscellaneous editorial changes.




Farmer                  Expires February 10, 2019               [Page 9]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   draft-farmer-6man-exceptions-64-02, 2018-July-31:

   o  Rewrote summary paragraph of the Introduction, using both subnets
      and IIDs.
   o  Added that privacy addresses require SLAAC in the Security
      Considerations.
   o  Added that manual config and DHCPv6 can also be used with Options
      1-3 of Appendix A.
   o  Added quick mention of M and O flags to discussion of DHCPv6 in
      Option 4 of Appendix A.
   o  Fixed typos introduced in version 01.
   o  More formatting changes.
   o  Editorial changes.

   draft-farmer-6man-exceptions-64-01, 2018-July-24:

   o  Numerous formatting changes.
   o  Editorial changes.
   o  Moved Acknowledgments to just before change log.

   draft-farmer-6man-exceptions-64-00, 2018-July-23:

   o  Original version.

8.  References

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

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <https://www.rfc-editor.org/info/rfc3315>.

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





Farmer                  Expires February 10, 2019              [Page 10]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


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

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

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

8.2.  Informative References

   [I-D.bourbaki-6man-classless-ipv6]
              Bourbaki, N., "IPv6 is Classless", draft-bourbaki-6man-
              classless-ipv6-03 (work in progress), March 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.

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
              <https://www.rfc-editor.org/info/rfc2373>.

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




Farmer                  Expires February 10, 2019              [Page 11]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 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>.

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

   [RFC8273]  Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
              per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
              <https://www.rfc-editor.org/info/rfc8273>.

Appendix A.  Options for Configuring IPv6 Subnets

   As discussed in the Introduction, IPv6 subnets are defined by two
   separate parameters, acting independently, the subnet assignment
   prefix and the on-link prefix.  It is possible to configure these two
   parameters with several different relationships to each other.  These
   parameters are primarily advertised in ND RA messages by PIOs, with



Farmer                  Expires February 10, 2019              [Page 12]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   the A and L flags designating the purpose of the PIO.  However,
   on-link prefixes may also be manually configured.

   SLAAC [RFC4862] Section 5.5.3 bullet d, validates subnet assignment
   prefixes against the IID length specified in separate link-type
   specific documents that are intended to be consistent with the
   standard 64-bit IID length.  Currently, there are no link-type
   specific documents that specify a non-standard IID length.  Therefore
   subnet assignment prefixes are effectively required to be 64 bits in
   length.  Further, to simplify the following discussion the
   possibility that a link-type specific document could specify a
   non-standard IID length is ignored.

   Whereas on-link prefixes have no such validation specified in IPv6 ND
   [RFC4861], this is also confirmed in SLAAC [RFC4862] Section 5.5.3
   bullet d.  Therefore on-link prefixes are not required to be 64 bits
   in length; they may have any length between 0 and 128 bits,
   inclusive.  Nevertheless, for consistency with the standard subnet
   boundary, 64-bit on-link prefixes lengths are recommended, except for
   inter-router point-to-point links with 127-bit prefixes.

   The following are the valid options for configuring the two
   parameters that define an IPv6 subnet;

   1.  Subnet assignment prefixes with identical on-link prefixes
   2.  Subnet assignment prefixes with shorter covering on-link prefixes
   3.  Only subnet assignment prefixes with no on-link prefixes
   4.  Only on-link prefixes with no subnet assignment prefixes

   Options 1 through 3, all define subnet assignment prefixes,
   designating the use of autonomous address assignment, performed by
   SLAAC, and effectively requiring subnets that are 64 bits in length.
   However, manually configured addresses or DHCPv6 assigned addresses
   may also be used in addition to autonomous address assignment.

   Option 1 is both the most frequently used and the only recommended
   option, except for inter-router point-to-point links with 127-bit
   prefixes, it has identical subnet assignment prefixes and on-link
   prefixes of 64 bits in length.  The 64-bit subnets used for
   autonomous address assignment are considered to be on-link.  This
   option is particularly recommended for networks that are made
   available to the general public or networks that intend to connect
   general-purpose hosts or mobile devices.

   Option 2 is not recommended, but is still a valid configuration; it
   has on-link prefixes shorter than 64 bits, between 0 and 63 bits,
   inclusive, but covering the subnet assignment prefixes included.  The
   64-bit subnets used for autonomous address assignment are considered



Farmer                  Expires February 10, 2019              [Page 13]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   on-link, along with other numerically adjacent subnets.  However,
   these other numerically adjacent subnets are not used for autonomous
   address assignment unless additional separate 64-bit subnet
   assignment prefixes are also included.

   Option 3 is not recommended, but is still a valid configuration; it
   has subnet assignment prefixes but no on-link prefixes.  Therefore
   the 64-bit subnets used for autonomous address assignment are not
   considered on-link, and all traffic for the subnets, including host-
   to-host traffic, must be sent to a default router.  See RFC 8273
   [RFC8273] for an example of this option.

   Option 4 is not recommended, but is still a valid configuration; it
   has on-link prefixes, but no subnet assignment prefixes, and
   therefore manually configured addresses or DHCPv6 assigned addresses
   must be used.  The on-link prefixes may have any length between 0 and
   128 bits, inclusive.  However, 64-bit on-link prefixes are
   recommended, except for inter-router point-to-point links with
   127-bit prefixes.  This option effectively results in subnets that
   are defined only by the on-link prefixes, and therefore the subnets
   may have any lengths, even though 64 bits is recommended.

   Furthermore, Option 4 essentially allows for the use of subnets
   longer than 64 bits.  While this violates the spirit of the standard
   subnet boundary, technically it is not a violation; manually
   configured addresses, DHCPv6 assigned addresses, and on-link
   determination are all exceptions to the standard subnet boundary
   defined in this document.  Nevertheless, for consistency with the
   standard subnet boundary, 64-bit on-link prefix lengths are
   recommended, effectively recommending 64-bit subnets, except for
   inter-router point-to-point links with 127-bit prefixes.

   There can be operationally valid reasons for configuring subnets
   longer than 64 bits, and when a subnet is solely configured by an
   on-link prefix, longer subnets while not recommended are not
   prohibited either.  RFC 6164 [RFC6164] explicitly allows 127-bit
   prefixes for inter-router point-to-point links.  Hence the explicit
   exceptions included for it.  Additionally, RFC 6583 [RFC6583]
   discusses "sizing subnets to reflect the number of addresses actually
   in use" as an operational mitigation for neighbor cache exhaustion
   issues.  RFC 7421 section 3 [RFC7421] discusses these issues in more
   detail, but there could be other reasons as well.  Nevertheless,
   address conservation by itself is never considered a valid reason for
   configuring subnets longer than 64 bits.  Accordingly, if a site
   needs additional subnets, additional 64-bit subnets are expected to
   be provided.





Farmer                  Expires February 10, 2019              [Page 14]

Internet-Draft   Exceptions to the IPv6 Subnet Boundary      August 2018


   When DHCPv6 is used a DHCPv6 server or DHCPv6 relay agent will also
   be needed on the link network.  Further, the managed address
   configuration (M) flag in IPv6 ND RA messages signals to hosts that
   DHCPv6 should be used for IPv6 address assignment and the other
   configuration (O) flag signals that other configuration information
   is available via DHCPv6.  However, some hosts do not implement DHCPv6
   and other hosts do not provide a mechanism for manually configuring
   an address on an interface.  Hosts that implement neither, only
   implementing SLAAC, do exist and do not operate on subnets configured
   based on Option 4 regardless of the length of the on-link prefix
   configured.

   It is possible to simultaneously configure multiple different
   subnets, associated with a single link network, each based on the
   same or different options described above.  For example, there could
   be two different subnets based on Option 1 and one based on Option 4,
   all associated with the same link network.

   Logically there is another option that could define a subnet, "Subnet
   assignment prefixes with longer covered on-link prefixes," but it
   does not result in an operationally valid subnet.  While SLAAC and ND
   accept this configuration, it is particularly problematic and is
   considered an invalid configuration by the operational guidance
   provided in Section 3.  It would have on-link prefixes longer than 64
   bits, between 65 and 128 bits, inclusive, that are covered by an
   included 64-bit subnet assignment prefix.  This configuration results
   in the 64-bit subnet used for autonomous address assignment being
   inconsistently considered on-link for some address and not on-link
   for other addresses within the same subnet.  This inconsistency
   creates a performance differential between addresses within the same
   subnet, which is inefficient and difficult to troubleshoot.

Author's Address

   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 February 10, 2019              [Page 15]