Internet DRAFT - draft-buraglio-v6ops-ula-use-cases
draft-buraglio-v6ops-ula-use-cases
Network Working Group N. Buraglio
Internet-Draft Energy Sciences Network
Intended status: Informational R. White
Expires: 22 July 2023 Juniper Networks
18 January 2023
IPv6 Unique Local Addressing Deployment Details and Operational Use
Cases
draft-buraglio-v6ops-ula-use-cases-01
Abstract
Use of unique local addressing (ULA) as an addressing practice brings
with it distinctive and specialized use cases that may be counter to
more widely deployed use cases using Global Unicast Addressing (GUA)
in some operational scenarios.
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 22 July 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.
Buraglio & White Expires 22 July 2023 [Page 1]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Defining Operational Deployment Models With ULA . . . . . . . 2
3. Operational Considerations . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Because of the perceived similarities between Unique Local Addressing
and [RFC1918], there may emerge a desire to deploy ULA as an analog
to private (non-glocally routable) IPv4 addressing within networking
domains attempting to model an IPv4/IPv6 dual-stacked environment
with private addressing. As detailed in draft-ietf-v6ops-ula,
however, by default the process to choose between using IPv4 or IPv6
addresses is different when deploying ULA vs. GUA IPv6 address
spaces.
This document outlines use cases in which IPv6 ULA address space may
be used with IPv4 addressing or as a stand alone addressing schema,
describing the results of each of these use cases in address
slection.
2. Defining Operational Deployment Models With ULA
Per [RFC6724], the definition is incomplete for ULA precedence if a
host is operating in a dual-stack environment. As written, [RFC6724]
section 10.3 states:
| The default policy table gives IPv6 addresses higher precedence
| than IPv4 addresses. The practical result of this is that
| applications reliant on the default operating system address
| selection mechanism will use IPv6 in preference to IPv4 when the
| two are equally suitable. An administrator may change the policy
| table to prefer IPv4 addresses by giving the ::ffff:0.0.0.0/96
| prefix a higher precedence.
Based on this text, operators may expect ULA address space be
preferred over legacy IPv4; however this is not the case. This
presents an acute issue with any environment that will use ULA
addressing along side any legacy IPv4 addressing and does not have
the capability or knowledge of the requirement of adjusting the
Buraglio & White Expires 22 July 2023 [Page 2]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
policy table, and is counter to the standard expectations for legacy
IPv4 / IPv6 dual-stack behavior of preferring IPv6, as is performed
in the prevailing deployment model of GUA addressing.
Further, [RFC6724] Section 10.6 states that this is resolvable by
adding a site-specific policy to cause ULAs within a site to be
preferred over global addresses. While theoretically possible, this
presents significant issues on devices with inaccessable
configuration files, or large-scale deployments as detailed below.
Based on the known considerations in address selection, it is only
advisable to deploy ULA addressing in select scenarios. Each of
these scenarios has specific use cases and should not be considered a
prototypical IPv6 deployment, having special use cases that are
defined by distinct needs and requirements for their respective
environments.
Single stacked, IPv6-only networks. Most of the deployment models
center around the absense of legacy addressing due to the described
difficulty in adjusting the address selection criteria at scale and
across platforms. However, ULA addressing is perfectly suited for
single stacked networks requiring, or precluding external
connectivity such as:
Management networks Networks designed and depoloyed as single-stacked
IPv6 networks with the putpose of providing tightly controlled access
for management of a given system. Access may come in the form of
bastion hosts, dual or single (GUA) stacked VPN concentrators, or
multi-homed routers providing no external access for the management
network in question. These networks may be isolated by their
respective access devices, or may have limited or tightly controlled
access for the ULA single-stacked hosts or devices via application
layer gateways. In all cases the ULA addressed devices are not
available outside of their well known management plane and access
mechanisms.
Air-gapped or externally isolated networks. Air-Gapped networks are
similar in nature to management networks but exist in a totally air-
gapped system with no non-physical access mechanism. Examples of
these networks are speciality networks existing in locations such as
highly secure enclaves, control systems, or networks such that may
exist on submarines, aircraft, or other vessels or facilities
requiring highly comparmentalized, access controlled networked
systems. Sensor networks may also fall into this category, with an
example being power, water or other utility or highly specialized
metering devices.
Buraglio & White Expires 22 July 2023 [Page 3]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
Dual-stacked networks with highly automated hosts. These networks
may also be configured with legacy IPv4, but are specifically built
with homogonous systems that enable highly automated workflows and
management of all endpoints. In this use case, it is required that
the address selection mechanism be available and easily changed en-
masse to allow for ULA to be preferred and used over legacy IPv4.
Another version of this type of deployment is one in which DNS is
utilized and only contains AAAA records thus forcing a given host to
resolve a ULA address and forego connectivity via legacy IPv4. A
similar deployment model using ULA addressing is one that simply has
no expectation of IPv6 utilization without user or programmatic
intervention.
3. Operational Considerations
There are demonstrated and easily repeatible uses cases of ULA not
being preferred in many commercially available and open source
operating systems and network equipment over legacy IPv4 that
necessitate the immediate update to [RFC6724] to better reflect the
original intent of the RFC. As with most adjustments to standards,
and using [RFC6724] itself as a measurment, this update will likely
take between 8-20 years to become pervasive enough for consistent
behavior within operating systems. As a reference, as of the time of
this writing, it has been 10 years since [RFC6724] has been published
but we continue to see existing commercial and open source operating
systems exhibiting [RFC3484] behavior. While it should be noted that
[RFC6724] defines a solution that is academically functional,
operationally the solution of adjusting the address preference
selection table is both operating system dependent and currently
unable to be signalled by any network mechanism such as within a
router advertisement, DHCPv6 option, or the like. 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 functionally untenable.
Buraglio & White Expires 22 July 2023 [Page 4]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
Based on the history of address selection standards, it is
anticipated that any update of [RFC6724]would require an additional
8-20 years to be fully realized and properly implemented in a
majority of network connected systems. In addition, in the current
versions of Linux, the priority table (gai.conf) still makes
reference to [RFC3484], further demonstrating the long timeframe to
have updates reflected in a current, modern operating system.
Examples of such out-of-date behavior can be found in printers,
cameras, fixed devices, IoT sensors, and longer lifecycle equipment
such as operational technology devices. It is especially important
to note this behavior in the long lifecycle equipment that exists in
industrial control and operational techology environments due to
their very long mean time to replacement. The core issue is the
stated interpretation from gai.conf that has the following default:
#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
Figure 1
Notice that the current interpretationm of the the legacy IPv4
address range as "scopev4" and the prefix ::ffff:0.0.0.0/96 has a
higher precedence (35) in [RFC6724] than the ULA prefix of fc00::/7
(3). This results in legacy IPv4 being preferred over IPv6 ULA.
The operational outcome is the move to dual-stack with ULA is
inconsistent and imparts unnecessary difficulty for both
troubleshooting and creating the baseline expected behavior which are
both requirements for long-term, supportable deployments. This
results in operational and engineering teams not gaining IPv6
experience as limited traffic is actually using IPv6, and security
baseline expectations are inconsistent at best and haphazard at
worst.
In practice, [RFC6724] imposes several operational shortcomings
preventing both consistent and desired behavior. If we define
"desired behavior" as IPv6 preference over legacy IPv4 for address
and protocol selection, then the resulting implemented behavior,
based on [RFC6724] , will fall short of that intent. Based on the
current verbiage, dual-stacked hosts configured with both a legacy
Buraglio & White Expires 22 July 2023 [Page 5]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
IPv4 address and an IPv6 ULA address, the resulting behavior will
manifest as a host choosing IPv4 over ULA IPv6. This behavior
deviates from the current goal of a host with legacy IPv4 address and
also with an IPv6 GUA address preferring IPv6 over IPv4.
Operationally and strategically, this manifests as an impediment to
deployment of IPv6 for many non-service provider and mobile networks
phasing in dual-stacked (both legacy IPv4 and IPv6) networking with
the expectation of consistent behavior (alway use IPv6 before legacy
IPv4).
Other operational considerations are the use of the policy table
detailed in section 2.1 of [RFC6724] . While conceptually the intent
was for a configurable, longest-match table to be adjusted as-needed.
In practice, modifying the prefix policy table remains difficult
across platforms, and in some cases impossible. Embedded,
proprietary, closed source, and IoT devices are especially difficult
to adjust and are, in many cases, incapable of any adjustment
whatsoever. Large scale manipulation of the policy table also
remains out of the realm of realistic support for small and medium
scale operators due to lack of ability to manipulate all the hosts
and systems, or a lack of tooling and access.
Below is an example of a gai.conf file from a modern Linux
installation as of 03 April 2022:
# 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.
#
# 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
Buraglio & White Expires 22 July 2023 [Page 6]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
#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
#
# 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
Figure 2
Buraglio & White Expires 22 July 2023 [Page 7]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
Several assumptions are made here and are largely based on
interpretations of [RFC6724] but are not operationally relevant in
modern networks. As this file or an equivalent structure within a
given operating system is referenced, it dictates the behavior of the
getaddrinfo() or analogous process. More specifically, where
getaddrinfo() or 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 addressing, 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.
Here are some example failure modes:
1. ULA per [RFC6724] 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.
Per number 3, even a host choosing a destination with A and AAAA DNS
records, the host in question will choose the A record to get an
legacy IPv4 address for the destination, meaning ULA IPv6 is rendered
completely unused. It is also notable that Happy Eyeballs ([RFC8305]
) will not change the source address selection process on a host.
Happy Eyeballs will only modify the destination sorting process.
As a direct result of the described failure modes, and in addition to
the aforementioned operational implications, use of ULA is not a
viable option for dual-stack \ networking transition planning, large
scale network modeling, network lab environments or other modes of
emulating a large scale networking that runs both IPv4 and IPv6
concurrently.
4. IANA Considerations
None at this time.
Buraglio & White Expires 22 July 2023 [Page 8]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
5. Security Considerations
Such unexpected behavior can result in unexpected operational
outcomes which can result in serious security and compliance issues
and could, in some cases, result in disabling of IPv6 to acheive
compliance and consistency, as we have seen in the past. .
6. Acknowledgements
The authors acknowledge the work of Brian Carpenter, XiPeng Xiao,
David Farmer, Bob Hinden, Mark Andrews, Vasilenko Eduardand, and Mark
Smith for participation in the technical discussions leading to this
finding and Michael Ackermann, Tom Coffeen, Kevin Myers, and Ed
Horley for providing further testing and operational input.
7. References
7.1. Normative References
[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>.
[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>.
[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>.
7.2. Informative References
[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>.
Authors' Addresses
Nick Buraglio
Energy Sciences Network
Email: buraglio@forwardingplane.net
Buraglio & White Expires 22 July 2023 [Page 9]
Internet-Draft IPv6 Unique Local Addressing Deployment January 2023
Russ White
Juniper Networks
Email: russ@riw.us
Buraglio & White Expires 22 July 2023 [Page 10]
