Internet DRAFT - draft-farmer-6man-routing-64
draft-farmer-6man-routing-64
6man Working Group D. Farmer
Internet-Draft Univ. of Minnesota
Updates: 4291 (if approved) January 6, 2019
Intended status: Standards Track
Expires: July 10, 2019
IPv6 Routing and its Relationship to
the 64-bit Boundary in the IPv6 Addressing Architecture
draft-farmer-6man-routing-64-02
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 this 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 10, 2019.
Copyright Notice
Copyright (c) 2019 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 10, 2019 [Page 1]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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 . . . . . . . . . . . . . . . . . . . . . . . 8
3. Updates to RFC 4291 . . . . . . . . . . . . . . . . . . . . . 9
4. Operational Guidance for the Configuration of Subnet Prefixes 9
4.1. Subnet Prefixes Other Than /64 . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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, and an
additional third form of interface identifiers, the Modified EUI-64
format.
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 on 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.
Farmer Expires July 10, 2019 [Page 2]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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 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 this 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.
Farmer Expires July 10, 2019 [Page 3]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
A slightly sophisticated host (but still rather simple) 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:
| 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 [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 10, 2019 [Page 4]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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.
[RFC7136] updates and [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.
Based on the above, the idea that a 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, most with a
standard 64-bit length, many more specifically in Modified EUI-64
format, and others are independent of any specific length. This
interpretation, at least as it applies to the Modified EUI-64 format,
is consistent with the updates in [RFC7136].
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.
Farmer Expires July 10, 2019 [Page 5]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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.
2.2. How the Two Forms are Used
Many aspects of the IPv6 specifications are 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...
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, [RFC7421], Section 4.1, lists many 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.
Farmer Expires July 10, 2019 [Page 6]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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
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] 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.
The fact that PIOs with the L flag set are not validated 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
[IPv6 ND]...
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
idea is also discussed in the IPv6 Addressing Architecture [RFC4291],
Section 2.5, paragraph 1, itself, which says;
IPv6 unicast addresses are aggregatable with prefixes of arbitrary
bit-length, similar to IPv4 addresses under Classless Inter-Domain
Routing.
And, this idea is further reinforced and clarified 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.
Farmer Expires July 10, 2019 [Page 7]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
2.3. Conclusion
As discussed above in Section 2.2 on-link determination and
autonomous address-configuration are logically separate functions in
IPv6, that are specified in separate documents, IPv6 ND and SLAAC
respectively, each with distinct and seemingly contradictory notions
about the length of subnet prefixes. It is tempting to try to
resolve this contradiction by applying the IPv6 Addressing
Architecture's requirement for the use of 64-bit interface
identifiers to subnet routing and on-link determination. However,
this requirement as implemented in the IPv6 protocol specifications
does not directly apply to IPv6 routing, including subnet routing and
on-link determination, and is inconsistent with not only statements
in IPv6 ND, but in both SLAAC and the IPv6 Addressing Architecture
themselves, as well as BCP 198, all quoted above in Section 2.2.
Notwithstanding the above and 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, especially SLAAC, 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. [RFC7421], Section 4.2, discusses some of these
situations.
Therefore, for consistency with the 64-bit boundary and most other
aspects of the IPv6 specifications, but despite the requirement for
64-bit interface identifiers not directly applying, 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 this 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.
Farmer Expires July 10, 2019 [Page 8]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
3. Updates to RFC 4291
Based on the discussion in Section 2, the 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 [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 [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 single 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, especially SLAAC, 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
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, either or
both, the autonomous address-configuration (A) flag 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
the configuration of these 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 other
mechanisms, such as the Dynamic Host Configuration Protocol for IPv6
(DHCPv6) [RFC8415] or even manual configuration. As a consequence,
Farmer Expires July 10, 2019 [Page 9]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
unless 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.
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.
Farmer Expires July 10, 2019 [Page 10]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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.
[RFC7421], Section 4.1, provides a non-exhaustive list of IPv6
features that depend on 64-bit Standard Interface Identifiers.
[RFC5375], Appendix B, discusses considerations for the use of subnet
prefixes other than /64, although some of the advice has been
obsoleted by [RFC6164] and [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-
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.
Farmer Expires July 10, 2019 [Page 11]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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. This guidance and the clarifications provided are not
expected to introduce any new security considerations.
However, if there are not IPv6 ND RA messages 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 [RFC3972],
[RFC4941], and [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 it more feasible to
perform IPv6 address scans. These and other related security and
privacy considerations are discussed in [RFC7707] and [RFC7721].
Nevertheless, the use of smaller subnets can provide effective
mitigation for neighbor cache exhaustion issues as discussed in
[RFC6164] and [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.
Farmer Expires July 10, 2019 [Page 12]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
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.
draft-farmer-6man-routing-64-02, 2019-January-6:
*Fixed typos, formatting and other editorial changes
*Further refined the argument for standard form of interface
identifiers.
*Added quote of RFC4291, Section 2.5, paragraph 1 in Section 2.2,
CIDR, etc...
*Further developed the conclusion, providing an argument why a
requirement is the incorrect relationship.
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>.
Farmer Expires July 10, 2019 [Page 13]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
[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>.
[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>.
Farmer Expires July 10, 2019 [Page 14]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
[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>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[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>.
Farmer Expires July 10, 2019 [Page 15]
Internet-Draft IPv6 Routing and the 64-bit Boundary January 2019
[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
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 10, 2019 [Page 16]
