Internet DRAFT - draft-buraglio-6man-rfc6724-update
draft-buraglio-6man-rfc6724-update
6MAN N. Buraglio
Internet-Draft Energy Sciences Network
Updates: 6724 (if approved) T. Chown
Intended status: Standards Track Jisc
Expires: 18 February 2024 J. Duncan
Tachyon Dynamics
17 August 2023
Preference for IPv6 ULAs over IPv4 addresses in RFC6724
draft-buraglio-6man-rfc6724-update-03
Abstract
This document updates RFC 6724 based on operational experience gained
since its publication over ten years ago. In particular it updates
the preference of Unique Local Addresses (ULAs) in the default
address selection policy table, which as originally defined by RFC
6724 has lower precedence than legacy IPv4 addressing. The update
places both IPv6 Global Unicast Addresses (GUAs) and ULAs ahead of
all IPv4 addresses on the policy table to better suit operational
deployment and management of ULAs in production. In updating the RFC
6724 default policy table, this document also demotes the preference
for 6to4 addresses. These changes to default behavior improve
supportability of common use cases such as, but not limited to,
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 18 February 2024.
Buraglio, et al. Expires 18 February 2024 [Page 1]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
Copyright Notice
Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Unintended Operational Issues Regarding IPv6 Preference and
ULAs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Operational Implications . . . . . . . . . . . . . . . . 4
4. Preference of 6to4 addresses . . . . . . . . . . . . . . . . 7
5. Adjustments to RFC 6724 . . . . . . . . . . . . . . . . . . . 7
6. The practicalities of implementing address selection
support . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Notes on the 6Man Working Group list discussion . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Appendix A. Changes since RFC6724 . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
When [RFC6724] was published in 2012 it was expected that the default
policy table may need to be updated from 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, including Section 10.6 which
considers a ULA example.
This document is written on the basis of such operational experience,
in particular for scenarios where ULAs are used within a site.
Buraglio, et al. Expires 18 February 2024 [Page 2]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
The current default policy table in RFC 6724 leads to preference for
IPv6 GUAs over IPv4 globals, which is widely considered to be
preferential behavior to support greater use of IPv6 in dual-stack
environments, and to allow sites to phase out IPv4 as its use becomes
ever lower.
However, the default policy table also puts IPv6 ULAs below all IPv4
addresses, including [RFC1918] addresses. For many site operators
this behavior will be counter-intuitive, and may create difficulties
with respect to planning, operational, and security implications for
environments where ULA addressing is used in certain IPv4/IPv6 dual-
stack network scenarios. The expected prioritization of IPv6 traffic
over IPv4 by default, as happens with IPv6 GUA addressing, will not
happen for ULAs.
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.
This document makes no comment or recommendation on how ULAs are
used, or on NAT, but notes that, as the default policy table stands,
operationally where GUAs and ULAs are used alongside RFC 1918
addressing, an IPv6 GUA would be selected to reach an IPv6 GUA
destination, but where only ULAs and RFC1918 addressing are used, RFC
1918 addresses will be preferred.
This document updates 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.
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 RFC 6724 policy table.
The changes should also assist operators in phasing out IPv4 from
dual-stack environments, since IPv6 GUAs and ULAs will be preferred
over any IPv4 addresses, and is thus an important enabler towards
IPv6-only networking.
The changes are discussed in more detail in the following sections,
with a further section providing a summary of the proposed updates.
Authors' note for the -02 version: this draft also captures and
refined based on discussions during and after presentation at IETF
117. One specific element discussed was the addition of setting
Buraglio, et al. Expires 18 February 2024 [Page 3]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
RFC1918 space (three IPv4 prefixes) to a lower preference is
currently omitted and should be discussed within the 6man list. This
section will be removed prior to publication.
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.
3. Unintended Operational Issues Regarding IPv6 Preference and ULAs
The preference for use of IPv6 addressing over IPv4 addressing in
[RFC6724] is inconsistent. As written, RFC 6724 section 10.3 states:
"The default policy table gives IPv6 addresses higher precedence than
IPv4 addresses. This means that applications will use IPv6 in
preference to IPv4 when the two are equally suitable. An
administrator can change the policy table to prefer IPv4 addresses by
giving the ::ffff:0.0.0.0/96 prefix a higher precedence".
The expected behavior would be that ULA address space would be
preferred over legacy IPv4, however this is not the case. This
presents an issue with any environment that will use ULA addressing
alongside legacy IPv4, whether global or RFC 1918. This is counter
to the standard expectations for legacy IPv4 / IPv6 dual-stack
behavior in preferring IPv6, which is the case for GUA addressing.
3.1. Operational Implications
There are demonstrated and easily repeatable uses cases of ULAs not
being preferred in some OS and network equipment over legacy IPv4
addresses that necessitate an update to RFC 6724 to better reflect
the original intent of the RFC in order to facilitate the
depreciation and eventual removal of IPv4 in network environments
where such a configuration is desired or required.
Below is an example of a gai.conf file from a modern Linux
installation as of 25 May 2023:
# Configuration for getaddrinfo(3).
#
# So far only configuration for the destination address sorting is needed.
# RFC 3484 governs the sorting. But the RFC also says that system
# administrators should be able to overwrite the defaults. This can be
# achieved here.
Buraglio, et al. Expires 18 February 2024 [Page 4]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
#
# All lines have an initial identifier specifying the option followed by
# up to two values. Information specified in this file replaces the
# default information. Complete absence of data of one kind causes the
# appropriate default information to be used. The supported commands include:
#
# reload <yes|no>
# If set to yes, each getaddrinfo(3) call will check whether this file
# changed and if necessary reload. This option should not really be
# used. There are possible runtime problems. The default is no.
#
# label <mask> <value>
# Add another rule to the RFC 3484 label table. See section 2.1 in
# RFC 3484. The default is:
#
#label ::1/128 0
#label ::/0 1
#label 2002::/16 2
#label ::/96 3
#label ::ffff:0:0/96 4
#label fec0::/10 5
#label fc00::/7 6
#label 2001:0::/32 7
#
# This default differs from the tables given in RFC 3484 by handling
# (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
# The reason for this difference is that these addresses are never
# NATed while IPv4 site-local addresses most probably are. Given
# the precedence of IPv6 over IPv4 (see below) on machines having only
# site-local IPv4 and IPv6 addresses a lookup for a global address would
# see the IPv6 be preferred. The result is a long delay because the
# site-local IPv6 addresses cannot be used while the IPv4 address is
# (at least for the foreseeable future) NATed. We also treat Teredo
# tunnels special.
#
# precedence <mask> <value>
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#
#precedence ::1/128 50
#precedence ::/0 40
#precedence 2002::/16 30
#precedence ::/96 20
#precedence ::ffff:0:0/96 10
#
# For sites which prefer IPv4 connections change the last line to
#
#precedence ::ffff:0:0/96 100
Buraglio, et al. Expires 18 February 2024 [Page 5]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
#
# scopev4 <mask> <value>
# Add another rule to the RFC 6724 scope table for IPv4 addresses.
# By default the scope IDs described in section 3.2 in RFC 6724 are
# used. Changing these defaults should hardly ever be necessary.
# The defaults are equivalent to:
#
#scopev4 ::ffff:169.254.0.0/112 2
#scopev4 ::ffff:127.0.0.0/104 2
#scopev4 ::ffff:0.0.0.0/96 14
The legacy IPv4 address range in the gai.conf file is "scopev4" and
the prefix ::ffff:0.0.0.0/96 which has a higher precedence (35) in
RFC 6724 than the ULA prefix of fc00::/7 (3). This results in legacy
IPv4 being preferred over IPv6 ULA. While not inherently
undesirable, the operational outcome when utilizing dual-stack with
ULA is inconsistent and imparts unnecessary difficulty for both
troubleshooting and creating the requisite baseline of the expected
behavior which are both requirements for supportable production
deployments. Depending on the host implementation, security baseline
expectations can be inconsistent at best and haphazard at worst.
As the gai.conf file, or an equivalent within a given operating
system, is referenced it dictates the behavior of the getaddrinfo()
or analogous process. More specifically, where getaddrinfo() or a
comparable API is used, the sorting behavior should take into account
both the source address of the requesting host as well as the
destination addresses returned and sort according to both source and
destination addresses, i.e, when a ULA address is returned, the
source address selection should return and use a ULA address if
available. Similarly, if a GUA address is returned the source
address selection should return a GUA source address if available.
However, there are clearly evidenced example of three failure
scenarios:
1. ULA per RFC 6724 is less preferred (the Precedence value is
lower) than all legacy IPv4 (represented by ::ffff:0:0/96 in the
aforementioned table).
2. Because of the lower Precedence value of fc00::/7, if a host has
legacy IPv4 enabled, it will use legacy IPv4 before using ULA.
3. A dual-stacked client will source the traffic from the legacy
IPv4 address, meaning it will require a corresponding legacy IPv4
destination address.
Buraglio, et al. Expires 18 February 2024 [Page 6]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
For scenario number 3, when a host resolves through DNS a destination
with A and AAAA DNS records, the host will choose the A record to get
an legacy IPv4 address for the destination, meaning ULA IPv6 is
rendered unused.
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.
4. Preference of 6to4 addresses
The anycast prefix for 6to4 relays was deprecated by [RFC7526] in
2015, and since that time the use of 6to4 addressing has further
declined to the point where it is generally not seen and can be
considered to all intents and purposes deprecated in use.
This document therefore demotes the preference of the 6to4 prefix in
the policy table to the same minimum preference as carried by the
deprecated site local and 6bone address prefixes.
5. Adjustments to RFC 6724
Rule 2.1 of RFC 6724 states:
If an implementation is not configurable or has not been configured,
then it SHOULD operate according to the algorithms specified here in
conjunction with the following default policy table:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
This document updates RFC 6724 section 2.1 to the following:
Buraglio, et al. Expires 18 February 2024 [Page 7]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
If an implementation is not configurable or has not been configured,
then it SHOULD operate according to the algorithms specified here in
conjunction with the following default policy table:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
fc00::/7 30 13
::ffff:0:0/96 20 4
2001::/32 5 5
2002::/16 5 2
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
This preference table update moves 2002::/16 to de-preference its
status in line with RFC 7526 and changes the default address
selection to move fc00::/7 above legacy IPv4, with ::ffff:0:0/96 now
set to precedence 20.
6. The practicalities of implementing address selection support
As with most adjustments to standards, and using RFC 6724 itself as a
measuring stick, the updates defined in this document will likely
take between 8-20 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 [RFC3484] behavior.
While it should be noted that RFC 6724 defines a solution that is
functional theoretically, operationally the solution of adjusting the
address preference selection table is both operating system dependent
and unable to be signaled by any network mechanism such as within a
router advertisement or DHCPv6 option (while [RFC7078] defines such a
DHCPv6 option, it is not by any means 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.
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.
Buraglio, et al. Expires 18 February 2024 [Page 8]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
In practice this means that network operators and those who design
networks need to keep these considerations in mind. One workaround
should the ULA and IPv4 preference issue be of concern is to use
IPv6-only networking, and to simply not deploy dual-stack. Another
is to only use GUA IPv6 addresses, which are preferred by default
over all IPv4 addresses.
7. Notes on the 6Man Working Group list discussion
Authors' note for the -00 version: this section captures some
interesting suggestions from the 300 or so emails in the past few
months in the 6man WG on this topic. These are noted, and captured
here to inform discussion of the draft should it move forward in the
WG. These notes will be deleted in the final version of the draft.
* The suggestion to automatically insert an observed ULA /48 into
the policy table to elevate a locally used ULA above IPv4 and GUA
addresses was quite popular, though kernel implementation may be
challenging for all platforms. This would be supported by
changing the “MAY" in Section 2.1 and the “might” in Section 10.6
of RFC 6724 to “SHOULD” (or even a MUST). The case for a MUST is
greater in order to allow for maximum network operator flexibility
if the source selection table is not modified by the operating
system. This could be an acceptable compromise, but requires two
additional additions to an IPv6 ULA network: router manufacturers
must now implement this new feature that is not a standard option
in IPv6 Router Advertisements (RAs) and operators must know that
the capability to add a tag for ULA prefixes in the source
selection table is an operational possibility and now part of an
architectural consideration. Network operators using managed
addressing may have not considered using a tagged ULA prefix in RA
as an option.
* The list discussed handling of corner cases, though what
constitutes a corner case is in itself not wholly clear. The
above suggestion for example would not cover the case where two
sites using ULAs merged, and multiple ULA prefixes needed to be
considered local. The open question is how deeply we consider
corner cases; is some requirement for explicit configuration of
certain cases inevitable? Is improving the current situation
sufficient?
* A suggestion to use an RA PIO with A=0 and L=0, based on an
interpretation of Section 2.1 of RFC 8028, was proposed but
considered something of a stretch. That said, it could be an RA-
based starting point to give some configurability for non-DHCPv6
networks.
Buraglio, et al. Expires 18 February 2024 [Page 9]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
8. Acknowledgements
The authors would like to acknowledge the valuable input and
contributions of the 6man WG including Brian Carpenter, XiPeng Xiao,
Eduard Vasilenko, David Farmer, Bob Hinden, Ed Horley, Tom Coffeen,
Scott Hogg, Chris Cummings, and Dale Carder.
9. 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.
When using the updated ULA source address selection defined in this
document, network operators MUST follow Section 4.3 of [RFC4193] for
firewall/packet filtering as "routers be configured by default to
keep any packets with Local IPv6 addresses from leaking outside of
the site and to keep any site prefixes from being advertised outside
of their site." Following this security practice is critical when
ULAs have more broad reachability.
In cases where one node is compliant with RFC 6724 as originally
published, and another node is compliant with the update presented in
this document, there may be inconsistent behaviour for communications
initaited in each direction. Operators should be mindful of this,
though it is no different in general principle to differences between
RFC 6724 and nodes that are (still) only RFC 3484 compliant.
10. IANA Considerations
None.
11. Appendix A. Changes since RFC6724
* Update to default preference table moving 6to4 address block
2002::/16 to de-preference status in line with [RFC7526]
* Change the default address selection to move fc00::/7 to
preference 30, above legacy IPv4,
* Change ::ffff:0:0/96 to preference 20.
12. References
12.1. Normative References
Buraglio, et al. Expires 18 February 2024 [Page 10]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
[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>.
[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>.
[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>.
[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>.
12.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>.
Authors' Addresses
Nick Buraglio
Energy Sciences Network
Email: buraglio@forwardingplane.net
Buraglio, et al. Expires 18 February 2024 [Page 11]
Internet-Draft Prefer ULAs over IPv4 addresses August 2023
Tim Chown
Jisc
Email: Tim.Chown@jisc.ac.uk
Jeremy Duncan
Tachyon Dynamics
Email: jduncan@tachyondynamics.com
Buraglio, et al. Expires 18 February 2024 [Page 12]
