draft-ietf-v6ops-ula-usage-considerations-01.txt   draft-ietf-v6ops-ula-usage-considerations-02.txt 
Internet Engineering Task Force B. Liu Internet Engineering Task Force B. Liu
Internet-Draft S. Jiang Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: February 18, 2017 August 17, 2016 Expires: September 14, 2017 March 13, 2017
Considerations For Using Unique Local Addresses Considerations For Using Unique Local Addresses
draft-ietf-v6ops-ula-usage-considerations-01 draft-ietf-v6ops-ula-usage-considerations-02
Abstract Abstract
This document provides considerations for using IPv6 Unique Local This document provides considerations for using IPv6 Unique Local
Addresses (ULAs). Based on an analysis of different ULA usage Addresses (ULAs). Based on an analysis of different ULA usage
scenarios, this document identifies use cases where ULA addresses are scenarios, this document identifies use cases where ULA addresses are
helpful as well as potential problems caused by using them, helpful as well as potential problems caused by using them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Analysis of ULA Features . . . . . . . . . . . . . . . . . . 3 3. General Considerations For Using ULAs . . . . . . . . . . . . 3
3.1. Automatically Generated . . . . . . . . . . . . . . . . . 3 3.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 3
3.2. Globally Unique . . . . . . . . . . . . . . . . . . . . . 3 3.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 4
3.3. Provider Independent Address Space . . . . . . . . . . . 3
3.4. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
3.5. Stable or Temporary Prefix . . . . . . . . . . . . . . . 4
4. Analysis and Operational Considerations for Scenarios Using 4. Analysis and Operational Considerations for Scenarios Using
ULAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 ULAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Isolated Networks . . . . . . . . . . . . . . . . . . . . 4 4.1. ULA-only in Isolated Networks . . . . . . . . . . . . . . 4
4.2. Connected Networks . . . . . . . . . . . . . . . . . . . 5 4.2. ULA+PA in Connected Networks . . . . . . . . . . . . . . 5
4.2.1. ULA-Only Deployment . . . . . . . . . . . . . . . . . 5 4.3. ULA-Only in Connected Networks . . . . . . . . . . . . . 7
4.2.2. ULAs along with PA Addresses . . . . . . . . . . . . 7 4.4. Some Specific Use Cases . . . . . . . . . . . . . . . . . 8
4.3. IPv4 Co-existence Considerations . . . . . . . . . . . . 9 4.4.1. Special Routing . . . . . . . . . . . . . . . . . . . 8
5. General Considerations For Using ULAs . . . . . . . . . . . . 10 4.4.2. Used as Identifier . . . . . . . . . . . . . . . . . 8
5.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 10 4.5. IPv4 Co-existence Considerations . . . . . . . . . . . . 9
5.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. ULA Usages Considered Helpful . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Used in Isolated Networks . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6.2. ULA along with PA . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Some Specific Use Cases . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.3.1. Special Routing . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 10
6.3.2. Used as NAT64 Prefix . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.3. Used as Identifier . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Unique Local Addresses (ULA) is defined in [RFC4193], and it is an Unique Local Addresses (ULA) is defined in [RFC4193], and it is an
alternative to site-local address (deprecated in [RFC3879]). But the alternative to site-local address (deprecated in [RFC3879]). ULAs
two kind of addresses are not the same. ULAs are defined as a global have the following features:
scope address space. However, they are not intended to be used
globally on the public Internet; in contrast, they are mostly used
locally, for example, in isolated networks, internal networks, or
VPNs.
Global scope yet local usage, this special feature has confused - Automatically Generated
network operators more or less. This document aims to introduce the
usage of ULAs in various scenarios, provide some operational ULA prefixes can be automatically generated using the algorithms
considerations, and clarify the advantages and disadvantages of the described in [RFC4193]. This feature allows automatic prefix
usage in each scenario. Thus, the administrators could choose to use allocation. Thus one can get a network working immediately
ULAs in a certain way that considered benificial for them. without applying for prefix(es) from an RIR/LIR (Regional Internet
Registry/Local Internet Registry).
- Globally Unique
ULAs are defined as a global scope address space. However, they
are not intended to be used globally on the public Internet; in
contrast, they are mostly used locally, for example, in isolated
networks, internal networks, or VPNs.
ULAs are intended to have an extremely low probability of
collision. The randomization of 40 bits in a ULA prefix is
considered sufficient enough to ensure a high degree of uniqueness
(refer to [RFC4193] Section 3.2.3 for details) and simplifies
merging of networks by avoiding the need to renumber overlapping
IP address space.
- Provider Independent Address Space
ULAs can be used for internal communications even without Internet
connectivity. They need no registration, so they can support on-
demand usage and do not carry any RIR/LIR burden of documentation
or fees.
- Well Known Prefix
The prefixes of ULAs are well known thus they are easily
identified and filtered.
This document aims to introduce the usage of ULAs in various
scenarios, provide some operational considerations, and clarify the
advantages and disadvantages of the usage in each scenario. Thus,
the administrators could choose to use ULAs in a certain way that
considered benificial for them.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in [RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key English meanings, and are not to be interpreted as [RFC2119] key
words. words.
3. Analysis of ULA Features 3. General Considerations For Using ULAs
3.1. Automatically Generated
ULA prefixes can be automatically generated using the algorithms
described in [RFC4193]. This feature allows automatic prefix
allocation. Thus one can get a network working immediately without
applying for prefix(es) from an RIR/LIR (Regional Internet Registry/
Local Internet Registry).
3.2. Globally Unique
ULAs are intended to have an extremely low probability of collision.
The randomization of 40 bits in a ULA prefix is considered sufficient
enough to ensure a high degree of uniqueness (refer to [RFC4193]
Section 3.2.3 for details) and simplifies merging of networks by
avoiding the need to renumber overlapping IP address space. Such
overlapping was a major drawback to the deployment of private
[RFC1918] addresses in IPv4.
Note that, as described in [RFC4864], applications may treat ULAs in
practice like global-scope addresses, but address selection
algorithms may need to distinguish between ULAs and Global-scope
Unicast Addresses (GUAs) to ensure bidirectional communications. As
a further note, the default address selection policy table in
[RFC6724]) responds to this requirement.
3.3. Provider Independent Address Space 3.1. Do Not Treat ULA Equal to RFC1918
ULAs can be used for internal communications even without Internet ULA and [RFC1918] are similar in some aspects. The most obvious one
connectivity. They need no registration, so they can support on- is as described in Section 3.1.3 that ULA provides an internal
demand usage and do not carry any RIR/LIR burden of documentation or address independence capability in IPv6 that is similar to how
fees. [RFC1918] is commonly used. ULA allows administrators to configure
the internal network of each platform the same way it is configured
in IPv4. Many organizations have security policies and architectures
based around the local-only routing of [RFC1918] addresses and those
policies may directly map to ULA [RFC4864].
3.4. Well Known Prefix But this does not mean that ULA is equal to an IPv6 version of
[RFC1918] deployment. [RFC1918] usually combines with NAT/NAPT for
global connectivity. But it is not necessary to combine ULAs with
any kind of NAT. Operators can use ULA for local communications
along with global addresses for global communications (see
Section 4.2). This is a big advantage brought by default support of
multiple-addresses-per-interface feature in IPv6. (People may still
have a requirement for NAT with ULA, this is discussed in
Section 4.3. But people also need to keep in mind that ULA is not
intentionally designed for this kind of use case.)
The prefixes of ULAs are well known thus they are easily identified Another important difference is the ability to merge two ULA networks
and filtered. without renumbering (because of the uniqueness), which is a big
advantage over [RFC1918].
This feature is convenient for management of security policies and 3.2. Using ULAs in a Limited Scope
troubleshooting. For example, network administrators can segregate
packets containing data which must stay in the internal network by
assigning ULAs to internal servers. Externally-destined data can be
sent to the Internet or telecommunication network by a separate
function, through an appropriate gateway/firewall.
3.5. Stable or Temporary Prefix A ULA is by definition a prefix that is never advertised outside a
given domain, and is used within that domain by agreement of those
networked by the domain.
A ULA prefix can be generated once, at installation time or factory So when using ULAs in a network, the administrators need to clearly
reset, and then possibly never be changed. Alternatively, it can be set the scope of the ULAs and configure ACLs on relevant border
regenerated regularly, depending on deployment requirements. routers to block them out of the scope. And if internal DNS is
enabled, the administrators might also need to use internal-only DNS
names for ULAs and might need to split the DNS so that the internal
DNS server includes records that are not presented in the external
DNS server.
4. Analysis and Operational Considerations for Scenarios Using ULAs 4. Analysis and Operational Considerations for Scenarios Using ULAs
4.1. Isolated Networks 4.1. ULA-only in Isolated Networks
IP is used ubiquitously. Some networks like industrial control bus IP is used ubiquitously. Some networks like industrial control bus
(e.g. [RS-485], [SCADA], or even non-networked digital interfaces (e.g. [RS-485], [SCADA], or even non-networked digital interfaces
like [MIL-STD-1397] have begun to use IP. In these kinds of like [MIL-STD-1397] have begun to use IP. In these kinds of
networks, the system may lack the ability to communicate with the networks, the system may lack the ability to communicate with the
public networks. public networks.
As another example, there may be some networks in which the equipment As another example, there may be some networks in which the equipment
has the technical capability to connect to the Internet, but is has the technical capability to connect to the Internet, but is
prohibited by administration or just temporarily not connected. prohibited by administration. These networks may include data center
These networks may include separate financial networks, lab networks. networks, separate financial networks, lab networks. machine-to-
machine-to-machine (e.g. vehicle networks), sensor networks, or even machine (e.g. vehicle networks), sensor networks, or even normal
normal LANs, and can include very large numbers of addresses. LANs, and can include very large numbers of addresses.
Serious disadvantages and impact on applications due to the use of ULA is a straightforward way to assign the IP addresses in the kinds
ambiguous address space have been well documented in [RFC1918]. of networks just described, with minimal administrative cost or
However, ULA is a straightforward way to assign the IP addresses in burden. Also, ULAs fit in multiple subnet scenarios, in which each
the kinds of networks just described, with minimal administrative subnet has its own ULA prefix. For example, when assigning vehicles
cost or burden. Also, ULAs fit in multiple subnet scenarios, in with ULAs, it is then possible to separate in-vehicle embedded
which each subnet has its own ULA prefix. For example, when networks into different subnets depending on real-time situation.
assigning vehicles with ULAs, it is then possible to separate in-
vehicle embedded networks into different subnets depending on real-
time situation.
However, each isolated network has the possibility to be connected in However, each isolated network has the possibility to be connected in
the future. Administrators need to consider the following before the future. Administrators need to consider the following before
deciding whether to use ULAs: deciding whether to use ULAs:
o If the network eventually connects to another isolated or private o If the network eventually connects to another isolated or private
network, the potential for address collision arises. However, if network, the potential for address collision arises. However, if
the ULAs were generated in the standard way, this will not be a the ULAs were generated in the standard way, this will not be a
big problem. big problem.
skipping to change at page 5, line 34 skipping to change at page 5, line 40
announce prefixes to each other. For example, in vehicle networks announce prefixes to each other. For example, in vehicle networks
with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) with infrastructure-less settings such as Vehicle-to-Vehicle (V2V)
communication, prior knowledge of the respective prefixes is communication, prior knowledge of the respective prefixes is
unlikely. Hence, a prefix announcement mechanism is needed to unlikely. Hence, a prefix announcement mechanism is needed to
enable inter-vehicle communications based on IP. As one enable inter-vehicle communications based on IP. As one
possibility, such announcements could rely on extensions to the possibility, such announcements could rely on extensions to the
Router Advertisement message of the Neighbor Discovery Protocol Router Advertisement message of the Neighbor Discovery Protocol
(e.g., [I-D.petrescu-autoconf-ra-based-routing] and (e.g., [I-D.petrescu-autoconf-ra-based-routing] and
[I-D.jhlee-mext-mnpp]). [I-D.jhlee-mext-mnpp]).
4.2. Connected Networks 4.2. ULA+PA in Connected Networks
4.2.1. ULA-Only Deployment
In some situations, nodes in one network are assigned ULAs but not
Global Unicast Addresses (GUAs), but the nodes also need to
communicate with the outside network. There could be two approaches:
o Using Network Prefix Translation (NPTv6)
NPTv6[RFC6296] is an experimental specification that provides a
stateless one-to-one mapping between internal addresses and
external addresses. Translating ULA prefixes into GUA prefixes
is an use case of this specification.
NPTv6 works differently from traditional stateful NAT/NAPT
(which is discouraged in [RFC5902]). So it does not create
several of the problems known to exsit with other kinds of NATs
as discussed in [RFC2993] and [RFC3027]. However, NPTv6
Translation does create difficulties for some kinds of
applications. (Please refer to Section 5 of [RFC6296] for
detailed analysis.)
o Using Application-Layer Proxies
In this approach, the proxies terminate the network-layer
connectivity of the hosts and associate separate internal and
external connections.
In some environments (e.g., information security sensitive
enterprises or government departments), central control is
exercised by allowing the endpoints to connect to the Internet
only through a proxy. With IPv4, using private address space
with proxies is an effective and common practice for this
purpose, and it is natural to pick ULA as its counterpart in
IPv6.
o Controversies of ULA-only Deployment
The comunity has strong controversies of ULA-only deployment in
connected networks.
The main reason of those who are in favor of using ULAs this
way is that it could get provider independent addresses or get
connected from the isolated stage without applying to any RIRs/
LIRs. This might be a essential benefit for the vast number of
small organizations, for saving time and address fee.
For those who are strongly against this usage, the main reason
is to avoid breaking the end-to-end transparence. Because
people have suffered from the NAT/Proxy middle boxes so much in
the IPv4 ear, there is no reason to continue the suffering when
IPv6 is available.
So, according to the controversy, this document does not
consider ULA+NPTv6/Proxy as a first choice for normal cases.
Rather, this document considers ULA+PA (Provider Aggregated) as
a better approach to connect to the global network when ULAs
are expected to be retained. The use of ULA+PA is discussed in
detail in Section 4.2.2 below.
Operational considerations:
o Firewall deployment: [RFC6296] points out that an NPTv6 translator
does not have the same security properties as a traditional NAT44,
and hence needs be supplemented with a firewall if security at the
boundary is an issue. The operator has to decide where to locate
the firewall.
- If the firewall is located outside the NPTv6 translator, then
filtering is based on the translated GUA prefixes, and when the
internal ULA prefixes are renumbered, the filtering rules do
not need to be changed. However, when the GUA prefixes of the
NPTv6 are renumbered, the filtering rules need to be updated
accordingly.).
- If the firewall is located inside the NPTv6 translator, the
filtering is then based on the ULA prefixes, and the rules need
to be updated correspondingly. There is no need to update when
the NPTv6 GUA prefixes are renumbered.
4.2.2. ULAs along with PA Addresses
Two classes of network might need to use ULA with PA (Provider Two classes of network might need to use ULA with PA (Provider
Aggregated) addresses: Aggregated) addresses:
o Home network. Home networks are normally assigned with one or o Home network. Home networks are normally assigned with one or
more globally routed PA prefixes to connect to the uplink of an more globally routed PA prefixes to connect to the uplink of an
ISP. In addition, they may need internal routed networking even ISP. In addition, they may need internal routed networking even
when the ISP link is down. Then ULA is a proper tool to fit the when the ISP link is down. Then ULA is a proper tool to fit the
requirement. [RFC7084] requires the CPE to support ULA. Note: requirement. [RFC7084] requires the CPE to support ULA. Note:
ULAs provide more benefit for multiple-segment home networks; for ULAs provide more benefit for multiple-segment home networks; for
skipping to change at page 9, line 23 skipping to change at page 7, line 44
delegation inside of their local control of ULA prefixes, a delegation inside of their local control of ULA prefixes, a
significant amount of information about the ULA population may significant amount of information about the ULA population may
leak to the outside world. Because reverse queries will be made leak to the outside world. Because reverse queries will be made
and naturally routed to the global reverse tree, so external and naturally routed to the global reverse tree, so external
parties will be exposed to the existence of a population of ULA parties will be exposed to the existence of a population of ULA
addresses. [ULA-IN-WILD] provides more detailed situations on addresses. [ULA-IN-WILD] provides more detailed situations on
this issue. Administrators may need a split DNS to separate the this issue. Administrators may need a split DNS to separate the
queries from internal and external for ULA entries and GUA queries from internal and external for ULA entries and GUA
entries. entries.
4.3. IPv4 Co-existence Considerations 4.3. ULA-Only in Connected Networks
Generally, this document does not consider IPv4 to be in scope. But
regarding ULA, there is a special case needs to be recognized, which
is described in Section 3.2.2 of [RFC5220]. When an enterprise has
IPv4 Internet connectivity but does not yet have IPv6 Internet
connectivity, and the enterprise wants to provide site-local IPv6
connectivity, a ULA is the best choice for site-local IPv6
connectivity. Each employee host will have both an IPv4 global or
private address and a ULA. Here, when this host tries to connect to
an outside node that has registered both A and AAAA records in the
DNS, the host will choose AAAA as the destination address and the ULA
for the source address according to the IPv6 preference of the
default policy table defined in the old address selection standard
[RFC3484]. This will clearly result in a connection failure. The
new address selection standard [RFC6724] has corrected this behavior
by preferring IPv4 than ULAs in the default policy table. However,
there are still lots of hosts using the old standard [RFC3484], thus
this could be an issue in real networks.
Happy Eyeballs [RFC6555] solves this connection failure problem, but
unwanted timeouts will obviously lower the user experience. One
possible approach to eliminating the timeouts is to deprecate the
IPv6 default route and simply configure a scoped route on hosts (in
the context of this document, only configure the ULA prefix routes).
Another alternative is to configure IPv4 preference on the hosts, and
not include DNS A records but only AAAA records for the internal
nodes in the internal DNS server. Then outside nodes have both A and
AAAA records and can be connected through IPv4 as default and
internal nodes can always connect through IPv6. But since IPv6
preference is default, changing the default in all nodes is not
suitable at scale.
5. General Considerations For Using ULAs
5.1. Do Not Treat ULA Equal to RFC1918
ULA and [RFC1918] are similar in some aspects. The most obvious one
is as described in Section 3.1.3 that ULA provides an internal
address independence capability in IPv6 that is similar to how
[RFC1918] is commonly used. ULA allows administrators to configure
the internal network of each platform the same way it is configured
in IPv4. Many organizations have security policies and architectures
based around the local-only routing of [RFC1918] addresses and those
policies may directly map to ULA [RFC4864].
But this does not mean that ULA is equal to an IPv6 version of
[RFC1918] deployment. [RFC1918] usually combines with NAT/NAPT for
global connectivity. But it is not necessary to combine ULAs with
any kind of NAT. Operators can use ULA for local communications
along with global addresses for global communications (see
Section 4.2.2). This is a big advantage brought by default support
of multiple-addresses-per-interface feature in IPv6. (People may
still have a requirement for NAT with ULA, this is discussed in
Section 4.2.1. But people also need to keep in mind that ULA is not
intentionally designed for this kind of use case.)
Another important difference is the ability to merge two ULA networks
without renumbering (because of the uniqueness), which is a big
advantage over [RFC1918].
5.2. Using ULAs in a Limited Scope
A ULA is by definition a prefix that is never advertised outside a
given domain, and is used within that domain by agreement of those
networked by the domain.
So when using ULAs in a network, the administrators need to clearly
set the scope of the ULAs and configure ACLs on relevant border
routers to block them out of the scope. And if internal DNS is
enabled, the administrators might also need to use internal-only DNS
names for ULAs and might need to split the DNS so that the internal
DNS server includes records that are not presented in the external
DNS server.
6. ULA Usages Considered Helpful
6.1. Used in Isolated Networks
As analyzed in Section 4.1, ULA is very suitable for isolated
networks. Especially when there are subnets in the isolated network,
ULA is a reasonable choice.
6.2. ULA along with PA In theory, a site numbered with ULAs only can get connected via a
NPTv6[RFC6296] (which is an experimental specification that provides
a stateless one-to-one mapping between internal addresses and
external addresses) or application-layer proxy. This approach could
get provider independent addresses or get connected from the isolated
stage without applying to any RIRs/LIRs. This might make small
organizations saving time and address fee.
As described in Section 4.2.2, using ULAs along with PA addresses to However, this approach breaks the end-to-end transparence. People
provide a logically separated local plane can benefit OAM functions have suffered from the NAT/Proxy middle boxes so much in the IPv4
and renumbering. ear, there is no reason to continue the suffering when IPv6 is
available. This document does not consider ULA+NPTv6/Proxy as a good
choice for normal cases. Rather, this document considers ULA+PA
(Provider Aggregated) as a better approach to connect to the global
network when ULAs are expected to be retained.
6.3. Some Specific Use Cases 4.4. Some Specific Use Cases
Along with the general scenarios, this section provides some specific Along with the general scenarios, this section provides some specific
use cases that could benefit from using ULA. use cases that could benefit from using ULA.
6.3.1. Special Routing 4.4.1. Special Routing
For various reasons the administrators may want to have private For various reasons the administrators may want to have private
routing be controlled and separated from other routing. For example, routing be controlled and separated from other routing. For example,
in the business-to-business case described in in the business-to-business case described in
[I-D.baker-v6ops-b2b-private-routing], two companies might want to [I-D.baker-v6ops-b2b-private-routing], two companies might want to
use direct connectivity that only connects stated machines, such as a use direct connectivity that only connects stated machines, such as a
silicon foundry with client engineers that use it. A ULA provides a silicon foundry with client engineers that use it. A ULA provides a
simple way to assign prefixes that would be used in accordance with simple way to assign prefixes that would be used in accordance with
an agreement between the parties. an agreement between the parties.
6.3.2. Used as NAT64 Prefix 4.4.2. Used as Identifier
The NAT64 PREF64 is just a group of local fake addresses for the
DNS64 to point traffic to a NAT64. Using a ULA prefix as the PREF64
easily ensures that only local systems can use the translation
resources of the NAT64 system since the ULA is not intended to be
globally routable. The ULA helps clearly identify traffic that is
locally contained and destined to a NAT64. Using ULA for PREF64 is
deployed and it is an operational model.
But there is an issue needs to be noted. The NAT64 standard
[RFC6146] specifies that the PREF64 should align with [RFC6052], in
which the IPv4-Embedded IPv6 Address format was specified. If we
pick a /48 for NAT64, it happens to be a standard 48/ part of ULA
(7bit ULA well-known prefix+ 1 "L" bit + 40bit Global ID). Then the
40bit of ULA is not violated by being filled with part of the 32bit
IPv4 address. This is important, because the 40bit assures the
uniqueness of ULA. If the prefix is shorter than /48, the 40bit
would be violated, and this could cause conformance issues. But it
is considered that the most common use case will be a /96 PREF64, or
even /64 will be used. So it seems this issue is not common in
current practice.
It is most common that ULA PREF64 will be deployed on a single
internal network, where the clients and the NAT64 share a common
internal network. ULA will not be effective as PREF64 when the
access network must use an Internet transit to receive the
translation service of a NAT64 since the ULA will not route across
the Internet.
According to the default address selection table specified in
[RFC6724], the host would always prefer IPv4 over ULA. This could be
a problem in NAT64-CGN scenario as analyzed in Section 8 of
[RFC7269]. So administrators need to add additional site-specific
address selection rules to the default table to steer traffic flows
going through NAT64-CGN. However, updating the default policy tables
in all hosts involves significant management cost. This may be
possible in an enterprise (using a group policy object, or other
configuration mechanisms), but it is not suitable at scale for home
networks.
6.3.3. Used as Identifier
ULAs could be self-generated and easily grabbed from the standard ULAs could be self-generated and easily grabbed from the standard
IPv6 stack. And ULAs don't need to be changed as the GUA prefixes IPv6 stack. And ULAs don't need to be changed as the GUA prefixes
do. So they are very suitable to be used as identifiers by the up do. So they are very suitable to be used as identifiers by the up
layer applications. And since ULA is not intended to be globally layer applications. And since ULA is not intended to be globally
routed, it is not harmful to the routing system. routed, it is not harmful to the routing system.
Such kind of benefit has been utilized in real implementations. For Such kind of benefit has been utilized in real implementations. For
example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to
assign a topology-independent identifier to each client host assign a topology-independent identifier to each client host
skipping to change at page 13, line 5 skipping to change at page 9, line 5
changes. changes.
o Sometimes one needs a constant identifier to be associated with a o Sometimes one needs a constant identifier to be associated with a
key so that the Security Association can survive the location key so that the Security Association can survive the location
changes. changes.
It needs to be noticed again that in theory ULA has the possibility It needs to be noticed again that in theory ULA has the possibility
of collision. However, the probability is desirably small enough and of collision. However, the probability is desirably small enough and
can be ignored in most cases when ULAs are used as identifiers. can be ignored in most cases when ULAs are used as identifiers.
7. Security Considerations 4.5. IPv4 Co-existence Considerations
Generally, this document does not consider IPv4 to be in scope. But
regarding ULA, there is a special case needs to be recognized, which
is described in Section 3.2.2 of [RFC5220]. When an enterprise has
IPv4 Internet connectivity but does not yet have IPv6 Internet
connectivity, and the enterprise wants to provide site-local IPv6
connectivity, a ULA is the best choice for site-local IPv6
connectivity. Each employee host will have both an IPv4 global or
private address and a ULA. Here, when this host tries to connect to
an outside node that has registered both A and AAAA records in the
DNS, the host will choose AAAA as the destination address and the ULA
for the source address according to the IPv6 preference of the
default policy table defined in the old address selection standard
[RFC3484]. This will clearly result in a connection failure. The
new address selection standard [RFC6724] has corrected this behavior
by preferring IPv4 than ULAs in the default policy table. However,
there are still lots of hosts using the old standard [RFC3484], thus
this could be an issue in real networks.
Happy Eyeballs [RFC6555] solves this connection failure problem, but
unwanted timeouts will obviously lower the user experience. One
possible approach to eliminating the timeouts is to deprecate the
IPv6 default route and simply configure a scoped route on hosts (in
the context of this document, only configure the ULA prefix routes).
Another alternative is to configure IPv4 preference on the hosts, and
not include DNS A records but only AAAA records for the internal
nodes in the internal DNS server. Then outside nodes have both A and
AAAA records and can be connected through IPv4 as default and
internal nodes can always connect through IPv6. But since IPv6
preference is default, changing the default in all nodes is not
suitable at scale.
5. Security Considerations
Security considerations regarding ULAs, in general, please refer to Security considerations regarding ULAs, in general, please refer to
the ULA specification [RFC4193]. Also refer to [RFC4864], which the ULA specification [RFC4193]. Also refer to [RFC4864], which
shows how ULAs help with local network protection. shows how ULAs help with local network protection.
As mentioned in Section 4.2.2, when using NPTv6, the administrators As mentioned in Section 4.2, when using NPTv6, the administrators
need to know where the firewall is located to set proper filtering need to know where the firewall is located to set proper filtering
rules. rules.
Also as mentioned in Section 4.2.2, if administrators choose not to Also as mentioned in Section 4.2, if administrators choose not to do
do reverse DNS delegation inside their local control of ULA prefixes, reverse DNS delegation inside their local control of ULA prefixes, a
a significant amount of information about the ULA population may leak significant amount of information about the ULA population may leak
to the outside world. to the outside world.
8. IANA Considerations 6. IANA Considerations
This memo has no actions for IANA. This memo has no actions for IANA.
9. Acknowledgements 7. Acknowledgements
Many valuable comments were received in the IETF v6ops WG mail list, Many valuable comments were received in the IETF v6ops WG mail list,
especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee
Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim
Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews, Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews,
Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton, Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton,
Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler, Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler,
Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali
and Wesley George. and Wesley George.
skipping to change at page 13, line 46 skipping to change at page 10, line 31
BNRC-BUPT (Broad Network Research Centre in Beijing University of BNRC-BUPT (Broad Network Research Centre in Beijing University of
Posts and Telecommunications). Thanks for the work of Prof. Posts and Telecommunications). Thanks for the work of Prof.
Xiangyang Gong and student Dengjia Xu. Xiangyang Gong and student Dengjia Xu.
Tom Taylor did a language review and revision throught the whole Tom Taylor did a language review and revision throught the whole
document. The authors appreciate a lot for his help. document. The authors appreciate a lot for his help.
This document was produced using the xml2rfc tool [RFC2629] This document was produced using the xml2rfc tool [RFC2629]
(initially prepared using 2-Word-v2.0.template.dot.). (initially prepared using 2-Word-v2.0.template.dot.).
10. References 8. References
10.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999, DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>. <http://www.rfc-editor.org/info/rfc2629>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <http://www.rfc-editor.org/info/rfc4193>.
10.2. Informative References 8.2. Informative References
[I-D.baker-v6ops-b2b-private-routing] [I-D.baker-v6ops-b2b-private-routing]
Baker, F., "Business to Business Private Routing", draft- Baker, F., "Business to Business Private Routing", draft-
baker-v6ops-b2b-private-routing-00 (work in progress), baker-v6ops-b2b-private-routing-00 (work in progress),
July 2007. July 2007.
[I-D.ietf-v6ops-dhcpv6-slaac-problem] [I-D.ietf-v6ops-dhcpv6-slaac-problem]
Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey,
"DHCPv6/SLAAC Interaction Problems on Address and DNS "DHCPv6/SLAAC Interaction Problems on Address and DNS
Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-06 Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-07
(work in progress), February 2016. (work in progress), August 2016.
[I-D.jhlee-mext-mnpp] [I-D.jhlee-mext-mnpp]
Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix
Provisioning", draft-jhlee-mext-mnpp-00 (work in Provisioning", draft-jhlee-mext-mnpp-00 (work in
progress), October 2009. progress), October 2009.
[I-D.petrescu-autoconf-ra-based-routing] [I-D.petrescu-autoconf-ra-based-routing]
Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali, Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali,
"Router Advertisements for Routing between Moving "Router Advertisements for Routing between Moving
Networks", draft-petrescu-autoconf-ra-based-routing-05 Networks", draft-petrescu-autoconf-ra-based-routing-05
skipping to change at page 16, line 5 skipping to change at page 12, line 35
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
IPv6 Network Address Translation", RFC 5902, IPv6 Network Address Translation", RFC 5902,
DOI 10.17487/RFC5902, July 2010, DOI 10.17487/RFC5902, July 2010,
<http://www.rfc-editor.org/info/rfc5902>. <http://www.rfc-editor.org/info/rfc5902>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>. <http://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", "Understanding Apple's Back to My Mac (BTMM) Service",
RFC 6281, DOI 10.17487/RFC6281, June 2011, RFC 6281, DOI 10.17487/RFC6281, June 2011,
<http://www.rfc-editor.org/info/rfc6281>. <http://www.rfc-editor.org/info/rfc6281>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<http://www.rfc-editor.org/info/rfc6296>. <http://www.rfc-editor.org/info/rfc6296>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
skipping to change at page 16, line 33 skipping to change at page 13, line 10
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>. <http://www.rfc-editor.org/info/rfc7084>.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014,
<http://www.rfc-editor.org/info/rfc7269>.
[RS-485] "Electronic Industries Association (1983). Electrical [RS-485] "Electronic Industries Association (1983). Electrical
Characteristics of Generators and Receivers for Use in Characteristics of Generators and Receivers for Use in
Balanced Multipoint Systems. EIA Standard RS-485.". Balanced Multipoint Systems. EIA Standard RS-485.".
[SCADA] "Boyer, Stuart A. (2010). SCADA Supervisory Control and [SCADA] "Boyer, Stuart A. (2010). SCADA Supervisory Control and
Data Acquisition. USA: ISA - International Society of Data Acquisition. USA: ISA - International Society of
Automation.". Automation.".
[ULA-IN-WILD] [ULA-IN-WILD]
"G. Michaelson, "conference.apnic.net/data/36/apnic- "G. Michaelson, "conference.apnic.net/data/36/apnic-
 End of changes. 38 change blocks. 
337 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/