Preference for IPv6 ULAs over IPv4 addresses in RFC6724
draft-ietf-6man-rfc6724-update-08
| Document | Type | Active Internet-Draft (6man WG) | |
|---|---|---|---|
| Authors | Nick Buraglio , Tim Chown , Jeremy Duncan | ||
| Last updated | 2024-04-09 | ||
| Replaces | draft-buraglio-6man-rfc6724-update | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-6man-rfc6724-update-08
6MAN N. Buraglio
Internet-Draft Energy Sciences Network
Updates: 6724 (if approved) T. Chown
Intended status: Standards Track Jisc
Expires: 10 October 2024 J. Duncan
Tachyon Dynamics
8 April 2024
Preference for IPv6 ULAs over IPv4 addresses in RFC6724
draft-ietf-6man-rfc6724-update-08
Abstract
When RFC 6724 was published it defined an address selection algorithm
along with a default policy table, and noted a number of examples
where that policy table might benefit from adjustment for specific
scenarios. It also noted that it is important for implementations to
provide a way to change the default policies as more experience is
gained. This update draws on several years of operational experience
to refine RFC 6724 further, with particular emphasis on preference
for the use of ULA addresses over IPv4 addresses and the addition of
mandatory support for Rule 5.5. The update also demotes the
preference for 6to4 addresses. The changes to default behavior
improve supportability of common use cases, including automatic /
unmanaged scenarios. It is recognized that some less common
deployment scenarios may require explicit configuration or custom
changes to achieve desired operational parameters.
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 10 October 2024.
Buraglio, et al. Expires 10 October 2024 [Page 1]
Internet-Draft Update on ULAs in RFC 6724 April 2024
Copyright Notice
Copyright (c) 2024 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Issues Regarding Preference for IPv4 addresses over
ULAs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Preference of 6to4 addresses . . . . . . . . . . . . . . . . 5
5. Adjustments to RFC 6724 . . . . . . . . . . . . . . . . . . . 6
5.1. Policy Table Update . . . . . . . . . . . . . . . . . . . 6
5.2. Rule 5.5 . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Automatic insertion of prefixes in the policy table . . . 7
6. Configuration of the default policy table . . . . . . . . . . 8
7. Intended behaviors . . . . . . . . . . . . . . . . . . . . . 8
7.1. GUA-GUA preferred over IPv4-IPv4 . . . . . . . . . . . . 8
7.2. GUA-GUA preferred over ULA-ULA . . . . . . . . . . . . . 8
7.3. ULA-ULA preferred over IPv4-IPv4 . . . . . . . . . . . . 8
7.4. IPv4-IPv4 preferred over ULA-GUA . . . . . . . . . . . . 9
8. Discussion of ULA source with GUA or remote ULA
destination . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. The ULA Label and its Precedence . . . . . . . . . . . . 10
8.2. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . . 11
8.3. Try the Next Address . . . . . . . . . . . . . . . . . . 11
9. Following ULA operational guidelines in RFC 4193 . . . . . . 11
9.1. Filtering ULA-source addresses at site borders . . . . . 12
9.2. Avoid using ULA addresses in the global DNS . . . . . . . 12
10. The practicalities of implementing address selection
support . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Limitations of RFC 6724 . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
15. Summary of changes and additional text since RFC 6724 . . . . 14
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
16.1. Normative References . . . . . . . . . . . . . . . . . . 14
Buraglio, et al. Expires 10 October 2024 [Page 2]
Internet-Draft Update on ULAs in RFC 6724 April 2024
16.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Since its publication in 2012, [RFC6724] has become an important
mechanism by which nodes can perform address selection, deriving the
most appropriate source and destination address pair to use from a
candidate set by following the procedures defined in the RFC. Part
of the process involves the use of a policy table, where the
precedence and labels for address prefixes are listed, and for which
a default table is defined.
It was always expected that the default policy table may need to be
changed based on operational experience; section 2.1 says "It is
important that implementations provide a way to change the default
policies as more experience is gained" and points to the examples in
Section 10, which include Section 10.6 where a ULA example is
presented.
This document is written on the basis of such operational experience,
in particular for scenarios where ULAs are used for their intended
purpose as stated in [RFC4193], i.e., they are designed to be routed
inside of a local site and by default not received from or advertised
externally. The document defines how preference for ULAs may be
elevated for appropriate, common scenarios.
It also includes updated requirements on support for RFC 6724 Rule
5.5. The goal of the document is to improve behavior for common
scenarios, and to assist in the phasing out of use of IPv4, while
noting that some specific scenarios may still require explicit
configuration.
An IPv6 deployment, whether enterprise, residential or other, may use
combinations of IPv6 GUAs, IPv6 ULAs, IPv4 globals, IPv4 RFC 1918
addressing, and may or may not use some form of NAT. However, this
document makes no comment or recommendation on how ULAs are used, or
on the use of NAT in an IPv6 network.
2. Terminology
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.
GUA: Global Unicast Addressing as defined in [RFC3587]
Buraglio, et al. Expires 10 October 2024 [Page 3]
Internet-Draft Update on ULAs in RFC 6724 April 2024
ULA: Unique Local Addressing as defined in [RFC4193]
Known-local ULA: A ULA prefix that is determined to be local to a
given node
3. Operational Issues Regarding Preference for IPv4 addresses over ULAs
With multiaddressing being the norm for IPv6, moreso where nodes are
dual-stack, the ability for a node to pick an appropriate address
pair for communication is very important.
Where getaddrinfo() or a comparable API is used, the sorting behavior
should take into account both the source addresses of the requesting
node as well as the destination addresses returned, and sort the
candidate address pairs following the procedures defined in RFC 6724.
The current default policy table leads to preference for IPv6 GUAs
over IPv4 globals, which is widely considered preferential behavior
to support greater use of IPv6 in dual-stack environments. This
helps allow sites to phase out IPv4 as its evidenced use becomes ever
lower.
However, the same default policy table also puts IPv6 ULAs below all
IPv4 addresses, including [RFC1918] addresses. For many site
operators this behavior will be counter-intuitive, given the IPv6 GUA
preference, and may create difficulties with respect to planning,
operational, and security implications for environments where ULA
addressing is used in IPv4/IPv6 dual-stack network scenarios. The
expected default prioritization of IPv6 traffic over IPv4 by default,
as happens with IPv6 GUA addressing, does not happen for ULAs.
As a result, the use of ULAs is not a viable option for dual-stack
networking transition planning, large scale network modeling, network
lab environments or other modes of large scale networking that run
both IPv4 and IPv6 concurrently with the expectation that IPv6 will
be preferred by default.
This document describes two methods by which a node can implement
elevated or differential preference for ULAs.
The general method is by updating the default policy table to elevate
the preference for ULAs such that ULAs will be preferred over all
IPv4 addresses, providing more consistent and less confusing behavior
for operators, and to assist operators in phasing out IPv4 from dual-
stack environments, since by this update IPv6 GUAs and ULAs will be
preferred over any IPv4 addresses. This is an important enabler for
sites seeking to move from dual-stack to IPv6-only networking.
Buraglio, et al. Expires 10 October 2024 [Page 4]
Internet-Draft Update on ULAs in RFC 6724 April 2024
RFC 6724 defined a method by which nodes may provide more fine-
grained support for elevating the preference for specific ULA
prefixes that are known to be local, while leaving other general ULA
prefixes at their existing precedence. This document upgrades the
requirement in RFC 6724 for nodes to insert a higher precedence entry
in the policy table for observed ULA prefixes that are known to be
local, referred to in this document as "known-local" ULAs, from a MAY
to a SHOULD. Nodes implementing this behaviour would see ULA
prefixes known to be local to the node's site having precedence over
both IPv6 GUA and IPv4 addresses, while other general ULAs would not.
AUTHORS' NOTE: The authors have had feedback suggesting this
requirement should be a MUST, which would mean that known-local ULAs
would take precedence on compliant implementations over all IPv6 GUAs
and all IPv4 addresses, but other general ULAs would not. We would
very much like further feedback on this potential change to the
document, or from those who may have implementations of such an
approach.
This change aims to improve the default handling of address selection
for common cases, and unmanaged / automatic scenarios rather than
those where DHCPv6 is deployed. Sites using DHCPv6 for host
configuration management can make use of implementations of [RFC7078]
to apply changes to the [RFC6724] policy table.
The changes are discussed in more detail in the following sections,
with a further section providing a summary of the proposed updates.
4. Preference of 6to4 addresses
The anycast prefix for 6to4 relays was formally deprecated by
[RFC7526] in 2015, and since that time the use of 6to4 addressing has
further declined, with very little evidence of its use on the public
internet. Note that RFC 7526 does not deprecate the 6to4 IPv6 prefix
2002::/16, it only deprecates the 6to4 Relay IPv4 prefix.
This document therefore demotes the precedence of the 6to4 prefix in
the policy table to the same precedence as carried by the Teredo
prefix. Leaving this entry in the default table will cause no
problems and will help if any deployments still exist, and ensure
6to4 prefixes are differentiated from general GUAs.
The discussion regarding the adding of 6to4 site prefixes in section
10.7 of RFC6724 remains valid.
Buraglio, et al. Expires 10 October 2024 [Page 5]
Internet-Draft Update on ULAs in RFC 6724 April 2024
5. Adjustments to RFC 6724
This update makes three specific changes to RFC 6724: first to update
the default policy table, second to change Rule 5.5 on prefering
addresses in a prefix advertised by the next-hop to a MUST, and third
to upgrade the requirement to automatically insert known-local ULAs
into a node's policy table from a MAY to a SHOULD.
5.1. Policy Table Update
This update alters the default policy table listed in Rule 2.1 of RFC
6724.
The table below reflects the current RFC 6724 state on the left, and
the updated state defined by this RFC on the right:
RFC 6724 Updated
Prefix Precedence Label Prefix Precedence Label
::1/128 50 0 ::1/128 50 0
::/0 40 1 ::/0 40 1
::ffff:0:0/96 35 4 ::ffff:0:0/96 20 4 (*)
2002::/16 30 2 2002::/16 5 2 (*)
2001::/32 5 5 2001::/32 5 5
fc00::/7 3 13 fc00::/7 30 13 (*)
::/96 1 3 ::/96 1 3
fec0::/10 1 11 fec0::/10 1 11
3ffe::/16 1 12 3ffe::/16 1 12
(*) value(s) changed in update
The update moves 2002::/16 to de-preference its status in line with
[RFC7526] and moves the precedence of fc00::/7 above legacy IPv4,
with ::ffff:0:0/96 now set to precedence 20.
5.2. Rule 5.5
The heuristic for address selection defined in Rule 5.5 of Section 5
of RFC 6724 to prefer addresses in a prefix advertised by a next-hop
router has proven to be very useful.
The text in RFC 6724 states that the Rules MUST be followed in order,
but also includes a discussion note under Rule 5.5 that says that an
IPv6 implementation is not required to remember which next-hops
advertised which prefixes and thus that Rule 5.5 is only applicable
to implementations that track this information.
This document elevates the requirement to prefer addresses in a
prefix advertised by a next-hop router to a MUST for all nodes.
Buraglio, et al. Expires 10 October 2024 [Page 6]
Internet-Draft Update on ULAs in RFC 6724 April 2024
5.3. Automatic insertion of prefixes in the policy table
Section 2.1 of RFC 6724 states that "an implementation MAY
automatically add additional site-specific rows to the default table
based on its configured addresses, such as for Unique Local Addresses
(ULAs)".
It is advantageous when preferring ULAs over IPv4 addresses to have
the highest confidence that the ULA is local to the node, and
reachable through ULA addressing, to avoid connection failures or
time-outs. If a node can determine which ULA prefix(es) are known to
be local, it can provide differential treatment for those over
general ULAs, and add these to the policy table at a higher
precedence while keeping all general ULA prefixes to a lower
precedence.
This document thus elevates the MAY requirement above to a SHOULD for
known-local ULAs.
Therefore where a node learns of a ULA prefix known to be local it
SHOULD give such known-local prefixes a precedence of 45, and SHOULD
also reduce the precedence of other ULA addresses, i.e., the general
fc00::/7 prefix, to precedence 10, such that IPv4 would be preferred
to ULA prefixes that have not been explicitly added.
Such known-local ULA prefixes include /48 prefixes containing a ULA
address assigned to any interface via manual configuration, DHCPv6
NA_IA, or SLAAC or learned from a PIO received on any interface,
regardless of how the PIO flags are set. Additionally, type C hosts,
as defined in [RFC4191] section 3, include any ULA prefixes learned
from RIOs as known-local ULAs.
Any such inserted "known local" ULA entries should also have a
different, but common, label, rather than the default ULA label, 13.
This document defines a label of 14 for such inserted known-local ULA
prefixes.
A node MUST remove inserted entries from its policy table when
announced prefixes are deprecated.
Where support is added for the insertion of known-local ULA prefixes,
it MUST default to on, but a mechanism SHOULD be supported to
administratively toggle the behaviour off and on.
EDITORS' NOTE: as stated above, we seek feedback on whether this
SHOULD should be elevated to a MUST.
Buraglio, et al. Expires 10 October 2024 [Page 7]
Internet-Draft Update on ULAs in RFC 6724 April 2024
6. Configuration of the default policy table
As stated in Section 2.1 of RFC 6724 "IPv6 implementations SHOULD
support configurable address selection via a mechanism at least as
powerful as the policy tables defined here".
Based on operational experience to date, it is important that node
policy tables can be changed once deployed to support future emerging
use cases. This update thus re-states the importance of such
configurability.
7. Intended behaviors
In this section we review the intended default behaviors after this
update is applied.
7.1. GUA-GUA preferred over IPv4-IPv4
This is the current behaviour, and remains unaltered. The rationale
is to promote use of IPv6 GUAs in dual-stack environments.
7.2. GUA-GUA preferred over ULA-ULA
This is the current behaviour, and remains unaltered. Both cases
have matching labels, with GUAs having higher precedence.
However, where a node inserts a known-local ULA into its policy table
with a precedence of 45, such ULA-ULA traffic will take priority over
GUA-GUA, because both pairs will have matching labels but here the
inserted ULA will have higher precedence.
7.3. ULA-ULA preferred over IPv4-IPv4
This is a change introduced by this update. RFC 6724 as originally
defined would lead to IPv4 being preferred over ULAs, which is
contrary to the spirit of the GUA preference over IPv4, and to the
goal of removing evidenced use of IPv4 in a dual-stack site before
transitioning to IPv6-only.
Where a node supports insertion of known-local ULAs, only those ULAs
will be preferred to IPv4 addresses, since general ULAs under
fc00::/7 will only carry precedence 10 where IPv4 carries precedence
20.
Buraglio, et al. Expires 10 October 2024 [Page 8]
Internet-Draft Update on ULAs in RFC 6724 April 2024
7.4. IPv4-IPv4 preferred over ULA-GUA
An IPv6 ULA address will only be preferred over an IPv4 address if
both IPv6 ULA source and destination addresses are available. With
Rule 5 of Section 6 of RFC 6724 and the ULA-specific label added in
[RFC6724] (which was not present in [RFC3484]) an IPv4 source and
destination will be preferred over an IPv6 ULA source and an IPv6 GUA
destination address, even though generally IPv6 ULA addresses are
preferred over IPv4 in the policy table as proposed in this update.
The IPv4 matching label trumps ULA-GUA.
8. Discussion of ULA source with GUA or remote ULA destination
In this section we present a discussion on the specific cases where a
ULA source may be communicating with a GUA or ULA destination.
A potential problem exists when a ULA source attempts to communicate
with GUA or remote ULA destinations. In these scenarios, the ULA
source as stated earlier is by default intended for communication
only with the local network, meaning an individual site, several
sites that are part of the same organization, or multiple sites
across cooperating organizations, as detailed in [RFC4193]. As a
result, most GUA and ULA destinations are not attached to the same
local network as the ULA source and are, therefore, not reachable
from the ULA source.
When only a ULA source is available for communication with GUA
destinations, this generally implies no connectivity to the IPv6
Internet is available. Otherwise, a GUA source would have been made
available and selected for use with GUA destinations. As a result,
the ULA source will typically fail when it attempts to communicate
with most GUA destinations. However, corner cases exist where the
ULA source will not fail, such as when GUA destinations are attached
to the same local network as the ULA source.
Receiving a DNS response for a ULA destination that is not attached
to the local network, in other words, a remote ULA destination, is
considered a misconfiguration in most cases, or at least this
contradicts the operational guidelines provided in Section 4.4 of
[RFC4193]. Nevertheless, this can occur, and the ULA source will
typically fail when it attempts to communicate with ULA destinations
that are not attached to the same local network as the ULA source.
This case provides a rationale for implementing support for known-
local ULA prefix insertion in the policy table, such that
differential behaviour can be applied for known-local versus general
ULA prefixes.
Buraglio, et al. Expires 10 October 2024 [Page 9]
Internet-Draft Update on ULAs in RFC 6724 April 2024
The remainder of this section discusses several complementary
mechanisms involved with these scenarios.
8.1. The ULA Label and its Precedence
RFC 6724 added (in obsoleting RFC 3484) a separate label for ULA
(fc00::/7), whose default precedence is raised by this update. This
separate label interacts with Rule 5 of Section 6 of RFC 6724, which
says:
Rule 5: Prefer matching label.
If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB),
then prefer DA.
Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) =
Label(DB), then prefer DB.
The ULA source label will not match the GUA destination label in the
first scenario. Therefore, an IPv4 destination, if available, will
be preferred over a GUA destination with a ULA source, even though
the GUA destination has higher precedence than the IPv4 destination
in the policy table. This means the IPv4 destination will be moved
up in the list of destinations over the GUA destination with the ULA
source.
If the ULA (fc00::/7) label is removed from the policy table, a GUA
destination with a ULA source will be preferred over an IPv4
destination, as GUA and ULA will be part of the same label (::/0).
The ULA source label will match the ULA destination label in the
second scenario; therefore, whether part of the local network or not,
a ULA destination will be preferred over an IPv4 destination.
Where known-local ULA prefix insertion is supported, the known-local
ULA will have a higher precedence (45) than either IPv6 GUAs (40) or
IPv4 (20), while general ULAs will have the lowest precedence (10).
If the ULA label (fc00::/7) has its precedence lowered below IPv4 or
the IPv4 precedence is raised above ULA, an IPv4 destination will be
preferred over all ULA destinations.
Buraglio, et al. Expires 10 October 2024 [Page 10]
Internet-Draft Update on ULAs in RFC 6724 April 2024
8.2. Happy Eyeballs
Regardless of the preference resulting from the above discussion,
Happy Eyeballs version 1 [RFC6555] or version 2 [RFC8305], if
implemented, will try both the GUA or ULA destination with the ULA
source and the IPv4 destination and source pairings. The ULA source
will typically fail to communicate with most GUA or remote ULA
destinations, and IPv4 will be preferred if IPv4 connectivity is
available unless the GUA or ULA destinations are attached to the same
local network as the ULA source.
8.3. Try the Next Address
As stated in Section 2 of RFC 6724:
"Well-behaved applications SHOULD NOT simply use the first address
returned from an API such as getaddrinfo() and then give up if it
fails. For many applications, it is appropriate to iterate through
the list of addresses returned from getaddrinfo() until a working
address is found. For other applications, it might be appropriate to
try multiple addresses in parallel (e.g., with some small delay in
between) and use the first one to succeed."
Therefore, when an IPv4 destination is preferred over GUA or ULA
destinations, IPv4 will likely succeed if IPv4 connectivity is
available, and the GUA or ULA destination may only be tried if Happy
Eyeballs is implemented.
On the other hand, if the GUA or ULA destination with the ULA source
is preferred, the ULA source will typically fail to communicate with
GUA or ULA destinations that are not connected to the same local
network as the ULA source. However, if the operational guidelines in
Section 4.3 of RFC 4193 are followed, recognizing this failure can be
accelerated, and transport layer timeouts (e.g., TCP) can be avoided.
The guidelines will cause a Destination Unreachable ICMPv6 Error to
be received by the source device, signaling the next address in the
list to be tried, as discussed above.
9. Following ULA operational guidelines in RFC 4193
This section re-emphasises two important operational requirements
stated in [RFC4193] that should be followed by operators.
Buraglio, et al. Expires 10 October 2024 [Page 11]
Internet-Draft Update on ULAs in RFC 6724 April 2024
9.1. Filtering ULA-source addresses at site borders
Section 4.3 states "Site border routers and firewalls should be
configured to not forward any packets with Local IPv6 source or
destination addresses outside of the site, unless they have been
explicitly configured with routing information about specific /48 or
longer Local IPv6 prefixes".
And further that "Site border routers should respond with the
appropriate ICMPv6 Destination Unreachable message to inform the
source that the packet was not forwarded".
As stated in the above discussion, such ICMPv6 messages can assist in
fast failover for TCP connections.
9.2. Avoid using ULA addresses in the global DNS
Section 4.3 of RFC 4193 states that "AAAA and PTR records for locally
assigned local IPv6 addresses are not recommended to be installed in
the global DNS."
This is particularly important given the general method presented in
this document elevates the priority for ULAs above IPv4. However,
where support for insertion of known-local prefixes is implemented,
such "rogue" ULAs in the global DNS are no longer a concern for
address selection as they would have the lowest precedence.
10. The practicalities of implementing address selection support
As with most adjustments to standards, and using the introduction of
RFC 6724 as a measuring stick, the updates defined in this document
will likely take several years to become common enough for consistent
behavior within most operating systems. At the time of writing, it
has been over 10 years since RFC 6724 has been published but we
continue to see existing commercial and open source operating systems
exhibiting RFC 3484 behavior.
While it should be noted that RFC 6724 defines a solution to adjust
the address preference selection table that is functional
theoretically, operationally the solution is operating system
dependent and in practice policy table changes cannot be signaled by
any currently deployed network mechanism. While RFC 7078 defines
such a DHCPv6 option, it is not widely implemented. This lack of an
intra-protocol or network-based ability to adjust address selection
preference, along with the inability to adjust a notable number of
operating systems either programmatically or manually, renders
operational scalability of such a mechanism challenging.
Buraglio, et al. Expires 10 October 2024 [Page 12]
Internet-Draft Update on ULAs in RFC 6724 April 2024
It is especially important to note this behavior in the long
lifecycle equipment that exists in industrial control and operational
technology environments due to their very long mean time to
replacement/lifecycle.
11. Limitations of RFC 6724
The procedures defined in RFC 6724 do not give optimal results for
all scenarios. As stated in the introduction, the aim of this update
is to improve the behavior for the most common scenarios.
It is widely recognised in the IETF 6man WG that the whole 3484/6724/
getaddrinfo() model is fundamentally inadequate for optimal address
selection. A model that considers address pairs directly, rather
than sorting on destination addresses with the best source for that
address, would be preferable, but beyond the scope of this document.
To simplify address selection, operators may instead look to deploy
IPv6-only, and may choose to only use GUA addresses and no ULA
addresses. Other approaches to reduce the use of IPv4, e.g., through
use of DHCPv4 Option 108 as defined in [RFC8925], also helps simplify
address selection for nodes.
12. Acknowledgements
The authors would like to acknowledge the valuable input and
contributions of the 6man WG including (in alphabetic order) Erik
Auerswald, Dale Carder, Brian Carpenter, Tom Coffeen, Lorenzo
Colitti, Chris Cummings, David Farmer (in particular for the ULA to
GUA/ULA discussion text), Bob Hinden, Scott Hogg, Ed Horley, Ted
Lemon, Jen Linkova, Michael Richardson, Kyle Rose, Ole Troan, Eduard
Vasilenko, Eric Vyncke, Paul Wefel, Timothy Winters, and XiPeng Xiao.
13. Security Considerations
There are no direct security considerations in this document.
The mixed preference for IPv6 over IPv4 from the default policy table
in RFC 6724 represents a potential security issue, given an operator
may expect ULAs to be used when in practice RFC 1918 addresses are
used instead.
The requirements of RFC 4193, stated earlier in this document, should
be followed for optimal behavior.
Operators should be mindful of cases where communicating nodes have
differing behaviours for address selection, e.g., RFC3484 behavior,
RFC6724, the updated RFC6724 behavior defined here, some other non-
Buraglio, et al. Expires 10 October 2024 [Page 13]
Internet-Draft Update on ULAs in RFC 6724 April 2024
IETF-standardized behavior, or even no mechanism. There may thus be
inconsistent behaviour for communications initiated in each
direction. Ultimately all nodes should be made compliant to the
updated specification described in this document.
14. IANA Considerations
None.
15. Summary of changes and additional text since RFC 6724
* Changed default policy table to move fc00::/7 to precedence 30,
above legacy IPv4.
* Changed default policy table to move the 6to4 address block
2002::/16 to the same precedence as the Teredo prefix.
* Changed ::ffff:0:0/96 to precedence 20.
* Changed Rule 5.5 to a MUST support.
* Added note on precedence for general ULAs where specific ULAs are
inserted in the policy table.
* Added text clarifying intended behaviors.
* Added text discussing ULA to GUA/ULA case.
* Added text for the security section.
16. References
16.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>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
Buraglio, et al. Expires 10 October 2024 [Page 14]
Internet-Draft Update on ULAs in RFC 6724 April 2024
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy Using DHCPv6", RFC 7078,
DOI 10.17487/RFC7078, January 2014,
<https://www.rfc-editor.org/info/rfc7078>.
[RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast
Prefix for 6to4 Relay Routers", BCP 196, RFC 7526,
DOI 10.17487/RFC7526, May 2015,
<https://www.rfc-editor.org/info/rfc7526>.
[RFC8925] Colitti, L., Linkova, J., Richardson, M., and T.
Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
RFC 8925, DOI 10.17487/RFC8925, October 2020,
<https://www.rfc-editor.org/info/rfc8925>.
[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>.
16.2. Informative References
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484,
DOI 10.17487/RFC3484, February 2003,
<https://www.rfc-editor.org/info/rfc3484>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <https://www.rfc-editor.org/info/rfc3587>.
Buraglio, et al. Expires 10 October 2024 [Page 15]
Internet-Draft Update on ULAs in RFC 6724 April 2024
Authors' Addresses
Nick Buraglio
Energy Sciences Network
Email: buraglio@forwardingplane.net
Tim Chown
Jisc
Email: Tim.Chown@jisc.ac.uk
Jeremy Duncan
Tachyon Dynamics
Email: jduncan@tachyondynamics.com
Buraglio, et al. Expires 10 October 2024 [Page 16]