IPv6 Routing and its Relationship the 64-bit Boundary in the IPv6 Addressing Architecture

The IPv6 Addressing Architecture 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, including subnet routing and on‑link determination, are based these general forms. 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. 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 the IPv6 Addressing Architecture requires the use of only /64 subnet prefixes for subnet routing and on‑link determination. 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 and on‑link determination, any length subnet prefixes, 0 to 128 bits, inclusive, are valid for IPv6 routing, including 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 and on‑link determination in most circumstances. This document clarifies the characterization of the relationship between IPv6 routing and the 64‑bit boundary in the IPv6 Addressing Architecture, which is that of a recommendation for the use of /64 subnet prefixes for subnet routing and on‑link determination 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.

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 when, and only when, they appear in all capitals, as shown here.

The IPv6 Addressing Architecture , 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 more complex node may additionally be aware of subnet prefix(es) for the link(s) it is attached to, where different addresses may have different values for n:

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, 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 , 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 , 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. RFC 7136 updates and RFC 8064 effectively deprecates the requirement that standard form interface identifiers are constructed in Modified EUI‑64 format. However, the original RFC 4291 version of the text is quoted here 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. 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. The idea that a distinct standard form of interface identifiers is being created by the above paragraph is also reinforced by the IPv6 Addressing Architecture , section 2.5.4, paragraph 2, where it 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. 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.

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) 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 , 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, Section 4, 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 , Section 5.2, and further clarified in the IPv6 Subnet Model , subnet routing and on-link determination depend on the general form subnet prefixes to 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. However, unlike SLAAC that validates PIOs with the A flag set, as discussed in IPv6 ND , 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 , 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 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.

Despite the fact that IPv6 routing, including 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 and on-link determination, there is a risk some IPv6 features will produce unpredictable results and others will not work outright. RFC 7421, Section 4.2, discusses some of these situations. Therefore, for consistency with the 64#8209;bit boundary and most other aspects of the IPv6 specifications, standard form subnet prefixes, that is /64 subnet prefixes, are RECOMMENDED for subnet routing and on-link determination in most circumstances. The formal exceptions to this recommendation are subnet prefixes that begin with the binary value 000 and inter#8209;router point#8209;to#8209;point links with 127#8209;bit prefixes . 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 and on-link determination 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.

Based on the discussion in , IPv6 Addressing Architecture , 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. 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 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.

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 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 and further clarified in the IPv6 Subnet Model . Briefly, as discussed in , 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 , 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) 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 . 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 and , /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 . 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. 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.

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, Section 4, provides a non‑exhaustive list of IPv6 features that depend on 64‑bit Standard Interface Identifiers. RFC 5375, Appendix B, discusses considerations for use of subnet prefixes other than /64, although some of the advice has been obsoleted by RFC 6164 and RFC 7136. 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-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 . 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.

This document includes no request to IANA.

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, RFC 4941, and RFC 7217. 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 it more feasible to perform IPv6 address scans. These and other related security and privacy considerations are discussed in RFC 7707 and RFC 7721. Nevertheless, the use of smaller subnets can provide effective mitigation for neighbor cache exhaustion issues as discussed in RFC 6164 and RFC 6583. The relative weights applied in these trade‑offs 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 several years, including discussions around the following; , BCP 198, , , , and . All revolving around the discussion of and its advancement to Internet Standard. This document was produced using the xml2rfc tool . The author would like to thank Tatuya Jinmei and Ole Troan for particularly useful comments on and discussion of that directly inspired the creation of this document. The author would like to thank the following, in alphabetical order, for their contributions and comments:

draft-farmer-6man-routing-64-00, 2018-December-3: Original version.