| 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-06
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.
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 (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 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.
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.
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."
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 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.
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.
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.
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 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.
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.
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.
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 on‑link prefix, but an on‑link prefix may be learned from a PIO with the L flag set.
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.
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.
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 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;
Appendix A discusses in further detail the valid options for configuring the parameters of IPv6 subnet.
This document includes no request to IANA.
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 and RFC 7217, 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 and RFC 7721.
However, the use of smaller subnets can be effective mitigation for neighbor cache exhaustion issues as discussed in RFC 6164 and RFC 6583. The relative weights applied in this trade‑off will vary from situation to situation.
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 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:
| [I-D.bourbaki-6man-classless-ipv6] | Bourbaki, N., "IPv6 is Classless", Internet-Draft draft-bourbaki-6man-classless-ipv6-03, March 2018. |
| [I-D.jaeggli-v6ops-indefensible-nd] | Jaeggli, J., "Indefensible Neighbor Discovery", Internet-Draft draft-jaeggli-v6ops-indefensible-nd-01, July 2018. |
| [I-D.jinmei-6man-prefix-clarify] | Jinmei, T., "Clarifications on On-link and Subnet IPv6 Prefixes", Internet-Draft draft-jinmei-6man-prefix-clarify-00, March 2017. |
| [RFC2373] | Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998. |
| [RFC2629] | Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999. |
| [RFC4291bis] | Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", Internet-Draft draft-ietf-6man-rfc4291bis-09, July 2017. |
| [RFC4941] | Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007. |
| [RFC6583] | Gashinsky, I., Jaeggli, J. and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012. |
| [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. |
| [RFC7421] | Carpenter, B., 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. |
| [RFC7707] | Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016. |
| [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. |
| [RFC8273] | Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017. |
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 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;
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 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 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 explicitly allows 127‑bit prefixes for inter‑router point‑to‑point links. Hence the explicit exceptions included for it. Additionally, RFC 6583 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 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.
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.