draft-ietf-v6ops-ula-usage-recommendations-01.txt   draft-ietf-v6ops-ula-usage-recommendations-02.txt 
Network Working Group B. Liu Network Working Group B. Liu
Internet Draft S. Jiang Internet Draft S. Jiang
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: April 24, 2014 C. Byrne Expires: August 18, 2014 February 14, 2014
T-Mobile USA
October 21, 2013
Recommendations of Using Unique Local Addresses Recommendations of Using Unique Local Addresses
draft-ietf-v6ops-ula-usage-recommendations-01.txt draft-ietf-v6ops-ula-usage-recommendations-02.txt
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 working Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/. 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 April 24, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 carefully, publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this as they describe your rights and restrictions with respect to this
document. Code Components extracted from this document must include document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust Simplified BSD License text as described in Section 4.e of the Trust
Legal Provisions and are provided without warranty as described in Legal Provisions and are provided without warranty as described in
the Simplified BSD License. the Simplified BSD License.
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
Abstract Abstract
This document provides guidance of how to use ULA. It analyzes ULA This document provides guidance of how to use ULAs. It analyzes ULA
usage scenarios and recommends use cases where ULA address might be usage scenarios and recommends use cases where ULA addresses might be
beneficially used. beneficially used.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 3
2. The analysis of ULA features ................................. 3 2. The analysis of ULA features ................................. 3
2.1. Automatically Generated ................................. 3 2.1. Automatically Generated ................................. 3
2.2. Globally unique.......................................... 3 2.2. Globally unique.......................................... 3
2.3. Independent address space ............................... 4 2.3. Independent address space ............................... 4
2.4. Well known prefix ....................................... 4 2.4. Well known prefix ....................................... 4
2.5. Stable or Temporary Prefix .............................. 4 2.5. Stable or Temporary Prefix .............................. 4
3. Enumeration of Scenarios Using ULAs .......................... 4 3. Enumeration of Scenarios Using ULAs .......................... 4
3.1. Isolated network ........................................ 4 3.1. Isolated network ........................................ 4
3.2. Connected network ....................................... 6 3.2. Connected network ....................................... 5
3.2.1. ULA-only Deployment ................................ 6 3.2.1. ULA-only Deployment ................................ 5
3.2.2. ULA along with GUA ................................. 7 3.2.2. ULA along with GUA ................................. 7
3.3. IPv4 Co-existence consideration ......................... 9 3.3. IPv4 Co-existence consideration ......................... 9
4. General Guidelines of using ULA .............................. 9 4. General Guidelines of using ULA .............................. 9
4.1. Do not treat ULA equal to RFC1918 ....................... 9 4.1. Do not treat ULA equal to RFC1918 ....................... 9
4.2. Using ULAs in a limited scope .......................... 10 4.2. Using ULAs in a limited scope .......................... 10
5. ULA usage recommendations ................................... 10 5. ULA usage recommendations ................................... 10
5.1. Used in Isolated Networks .............................. 10 5.1. Used in Isolated Networks .............................. 10
5.2. ULA along with GUA ..................................... 10 5.2. ULA along with GUA ..................................... 10
5.3. Recommended Specific Use Cases ......................... 10 5.3. Recommended Specific Use Cases ......................... 10
5.3.1. Special routing ................................... 10 5.3.1. Special routing ................................... 11
5.3.2. Used as NAT64 prefix .............................. 11 5.3.2. Used as NAT64 prefix .............................. 11
5.3.3. Used as identifier ................................ 11 5.3.3. Used as identifier ................................ 12
6. Security Considerations ..................................... 12 6. Security Considerations ..................................... 12
7. IANA Considerations ......................................... 12 7. IANA Considerations ......................................... 13
8. Conclusions ................................................. 12 8. Conclusions ................................................. 13
9. References .................................................. 13 9. References .................................................. 13
9.1. Normative References ................................... 13 9.1. Normative References ................................... 13
9.2. Informative References ................................. 13 9.2. Informative References ................................. 13
10. Acknowledgments ............................................ 14 10. Acknowledgments ............................................ 14
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
1. Introduction 1. Introduction
Unique Local Addresses (ULAs) are defined in [RFC4193] as provider- Unique Local Addresses (ULAs) are defined in [RFC4193] as provider-
independent prefixes that can be used on isolated networks, internal independent prefixes that can be used on isolated networks, internal
networks, and VPNs. Although ULAs may be treated like global scope by networks, and VPNs. Although ULAs may be treated like global scope by
applications, normally they should not be used on the publicly applications, normally they should not be used on the publicly
routable internet. routable internet.
However, the ULAs haven't been widely used since IPv6 hasn't been However, the ULAs haven't been widely used since IPv6 hasn't been
widely deployed yet. widely deployed yet. The use of ULA addresses in various types of
networks has been confusing to network operators. This document aims
The use of ULA addresses in various types of networks has been to clarify the advantages and disadvantages of ULAs and how they can
confusing to network operators. Some network operators believe ULAs be most appropriately used.
are not useful at all while other network operators have run ULAs
beneficially in their networks. This document attempts to clarify the
advantages and disadvantages of ULAs and how they can be most
appropriately used.
2. The analysis of ULA features 2. The analysis of ULA features
2.1. Automatically Generated 2.1. Automatically Generated
ULA prefixes could be automatically generated according to the ULA prefixes could be automatically generated according to the
algorithms described in [RFC4193]. This feature allows automatic algorithms described in [RFC4193]. This feature allows automatic
address allocation, which is beneficial for some lightweight systems address allocation, which is beneficial for some lightweight systems
and can leverage minimal human management. and can leverage minimal human management.
skipping to change at page 4, line 4 skipping to change at page 3, line 44
a high degree of uniqueness (refer to [RFC4193] section 3.2.3 for a high degree of uniqueness (refer to [RFC4193] section 3.2.3 for
details)and make merging of networks simple and without the need to details)and make merging of networks simple and without the need to
renumbering overlapping IP address space. Overlapping is cited as a renumbering overlapping IP address space. Overlapping is cited as a
deficiency with how [RFC1918] addresses were deployed, and ULA was deficiency with how [RFC1918] addresses were deployed, and ULA was
designed to overcome this deficiency. designed to overcome this deficiency.
Notice that, as described in [RFC4864], in practice, applications may Notice that, as described in [RFC4864], in practice, applications may
treat ULAs like global-scope addresses, but address selection treat ULAs like global-scope addresses, but address selection
algorithms may need to distinguish between ULAs and ordinary GUA algorithms may need to distinguish between ULAs and ordinary GUA
(Global-scope Unicast Address) to ensure bidirectional communications. (Global-scope Unicast Address) to ensure bidirectional communications.
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
(Note: the new address selection standard has supported this in the (Note: the new address selection standard has supported this in the
default policy table. [RFC6724]) default policy table. [RFC6724])
2.3. Independent address space 2.3. Independent address space
ULA provides an internal address independence capability in IPv6ULA ULA provides an internal address independence capability in IPv6ULA
can be used for internal communications without having any permanent can be used for internal communications without having any permanent
or only intermittent Internet connectivity. And it needs no or only intermittent Internet connectivity. And it needs no
registration so that it can support on-demand usage and does not registration so that it can support on-demand usage and does not
carry any RIR documentation burden or disclosures. carry any RIR documentation burden or disclosures.
skipping to change at page 5, line 4 skipping to change at page 4, line 48
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 interface like (e.g. [RS-485], [SCADA], or even non-networked digital interface like
[MIL-STD-1397] began to use IP protocol. In such kind of networks, [MIL-STD-1397] began to use IP protocol. In such kind of networks,
the system might lack the ability/requirement of connecting to the the system might lack the ability/requirement of connecting to the
Internet. or explicitly designed not to connect. Internet. or explicitly designed not to connect.
Besides, there might be some networks which could connect to the Besides, there might be some networks which could connect to the
Internet, but prohibited by administration or just temporally not Internet, but prohibited by administration or just temporally not
connected. These networks may include machine-to-machine (e.g. connected. These networks may include machine-to-machine (e.g.
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
vehichle networks), sensor networks, or even normal LANs, which may vehichle networks), sensor networks, or even normal LANs, which may
include very large numbers of addresses. include very large numbers of addresses.
Since the serious disadvantages and impact on applications by Since the serious disadvantages and impact on applications by
ambiguous address space have been well documented in [RFC1918], ULA ambiguous address space have been well documented in [RFC1918], ULA
is a straightforward way to assign the IP addresses in these kinds of is a straightforward way to assign the IP addresses in these kinds of
networks with minimal administrative cost or burden. And since ULA networks with minimal administrative cost or burden. Also, ULAs fit
support multiple subnets, it is scalable. For example, when we assign in multiple subnet scenarios, in which each subnet has its own ULA
vehicles with ULA addresses, it is then possible to separate in- prefix. For example, when we assign vehicles with ULA addresses, it
vehicle embedded networks into different subnets depending on real- is then possible to separate in-vehicle embedded networks into
time requirements, devices types, services and more. different subnets depending on real-time requirements, devices types,
services and more.
o Pros of Using ULAs in Isolated Networks: o Benefits of Using ULAs in Isolated Networks:
- No cost of RIR/LIR fees or operational burden - No cost of RIR/LIR fees or operational burden
- Support multiple subnets comparing to link-local addresses - Could be used instantly on-demand
- Support isolated networks merge without renumbering, because of - Scalable to support multiple subnets
its extremely low probability of collision - Extremely low probability of collision when isolated networks
merge
o Cons: o Drawbacks:
- The global uniqueness of prefixes is not guaranteed, however, - The uniqueness of the global ULA prefix is not guaranteed,
the probability is extremely low however, the probability of collision is extremely low
o Operational considerations o Operational considerations
- Prefix generation: Randomly generated according to the - Prefix generation: Randomly generated according to the
algorithms defined in [RFC4193] or literally assigned by human. algorithms defined in [RFC4193] or literally assigned by human.
Normally, it is recommended to following the standard way to Normally, it is recommended to following the standard way to
automatically generate the prefixes; if there are some specific automatically generate the prefixes; if there are some specific
reasons that need to be assigned by human, the administrators must reasons that need to be assigned by human, the administrators must
carefully plan the prefixes to avoid collision. carefully plan the prefixes to avoid collision.
- Prefix announcement: In some cases, the networks might need to - Prefix announcement: In some cases, the networks might need to
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)
settings, prior knowledge of respective prefixes is unlikely. settings, prior knowledge of respective prefixes is unlikely.
Hence, a prefix announcement mechanism is needed to enable inter- Hence, a prefix announcement mechanism is needed to enable inter-
vehicles communications based on IP. For instance, such vehicles communications based on IP. For instance, such
announcement could rely on an extension of the Router announcement could rely on an extension of the Router
Advertisement message of Neighbor Discovery Protocol (e.g. Advertisement message of Neighbor Discovery Protocol (e.g.
[I-D.petrescu-autoconf-ra-based-routing] and [I-D.petrescu-autoconf-ra-based-routing] and
[I-D.jhlee-mext-mnpp]). [I-D.jhlee-mext-mnpp]).
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
3.2. Connected network 3.2. Connected network
3.2.1. ULA-only Deployment 3.2.1. ULA-only Deployment
In some situations, hosts/interfaces are assigned with ULA-only, but In some situations, hosts/interfaces are assigned with ULA-only, but
the networks need to communicate with the outside. It mainly includes the networks need to communicate with the outside. It mainly includes
the following two models. the following two models.
o Using Network Prefix Translation o Using Network Prefix Translation
skipping to change at page 6, line 32 skipping to change at page 6, line 21
In some very constrained situations(for example, in the sensors), the In some very constrained situations(for example, in the sensors), the
network needs ULA as the on-demand and stable addressing which network needs ULA as the on-demand and stable addressing which
doesn't need much code to support address assignment mechanisms like doesn't need much code to support address assignment mechanisms like
DHCP or full ND (Note: surely it needs SLAAC). If the network also DHCP or full ND (Note: surely it needs SLAAC). If the network also
needs to connect to the outside, then there can be an NPTv6 gateway needs to connect to the outside, then there can be an NPTv6 gateway
which is not subject to extreme resource constraints. Especially when which is not subject to extreme resource constraints. Especially when
a lightweight isolated network needs to add Internet connectivity, a lightweight isolated network needs to add Internet connectivity,
this is quite a straightforward and efficient way. this is quite a straightforward and efficient way.
This document does not intend to encourage the ULA binding with NPTv6 This document does not intend to encourage the ULA binding with NPTv6
model, in [RFC5902] the IAB had already gave opinions on IPv6 NAT; model, since in [RFC5902] the IAB had already gave opinions on IPv6
but this document considers it as a valid use case in some specific NAT; but this document considers it as an effective approach in some
situations as described above. specific situations as described above.
o Using application-layer proxies o Using application-layer proxies
The proxies terminate the network-layer connectivity of the hosts and The proxies terminate the network-layer connectivity of the hosts and
delegate the outgoing/incoming connections. delegate the outgoing/incoming connections.
In some environments (e.g. information security sensitive enterprise In some environments (e.g. information security sensitive enterprise
or government), the endpoints are default disconnected to the or government), the endpoints are default disconnected to the
Internet, and need the proxies to connect for central control. In Internet, and need the proxies to connect for central control. In
IPv4, using private address space with proxies is an effective and IPv4, using private address space with proxies is an effective and
common practice for this purpose, and it is natural to pick ULA in common practice for this purpose, and it is natural to pick ULA in
IPv6. IPv6.
o Pros of Using ULAs in This Scenario: o Benefits of Using ULAs in This Scenario:
- Allowing minimal management burden on address assignment for - Allowing minimal management burden on address assignment for
some specific environments. some specific environments.
o Cons: o Drawbacks:
- The serious disadvantages and impact on applications by NAT have - The serious disadvantages and impact on applications by NAT have
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
been well documented in [RFC2993] and [RFC3027]. However, it been well documented in [RFC2993] and [RFC3027]. However, it
should be noted that, For NPTv6, as described in [RFC6296], it is should be noted that, For NPTv6, as described in [RFC6296], it is
"a mechanism that has fewer architectural problems than merely "a mechanism that has fewer architectural problems than merely
implementing a traditional stateful Network Address Translator in implementing a traditional stateful Network Address Translator in
an IPv6 environment." an IPv6 environment."
o Operational considerations o Operational considerations
- Firewall Issue: When use NPTv6, the administrators need to care - Firewall Deployment: As described in [RFC6296], firewall is
about where the firewall need to be, because NPTv6 is stateless recommended to be implemented with NPTv6 translator. Then the
and makes the ULAs wide open to the Internet. And when renumber, administrators need to know about where the firewall is located.
the firewall(s) needs to be reconfigured when it is located If the firewall is located outside the NPTv6 translator, then the
outside the NPTv6 translator. If the firewall(s) is inside the filtering is based on the translated GUA prefixes, and when the
translator, the administrators need to use the ULAs for filtering internal ULA prefixes are renumbered, the filtering rules don't
instead of the global ones. need to be changed (however, when 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 according to the ULA prefixes renumbering (but don't
need to update when NPTv6 GUA prefixes are renumbered.).
3.2.2. ULA along with GUA 3.2.2. ULA along with GUA
There are two classes of network probably to use ULA with GUA There are two classes of network probably to use ULA with GUA
addresses: addresses:
- Home network. Home networks are normally assigned with one or - Home network. Home networks are normally assigned with one or
more globally routed PA prefixes to connect to the uplink of some more globally routed PA prefixes to connect to the uplink of some
an ISP. And besides, they may need internal routed networking even an ISP. And besides, 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. And in [RFC6204], it requires the CPE to support ULA. requirement. And in [RFC6204], it requires the CPE to support ULA.
Note, ULAs provide more benefit for multiple-segment home networks;
for home networks only containing one segment, link-local
addresses are better alternative.
- Enterprise network. An enterprise network is usually a managed - Enterprise network. An enterprise network is usually a managed
network with one or more PA prefixes or with a PI prefix, all of network with one or more PA prefixes or with a PI prefix, all of
which are globally routed. The ULA could be used for internal which are globally routed. The ULA could be used for internal
connectivity redundancy and better internal connectivity or connectivity redundancy and better internal connectivity or
isolation of certain functions like OAM of servers. isolation of certain functions like OAM of servers.
o Pros of Using ULAs in This Scenario: o Benefits of Using ULAs in This Scenario:
- Separated Local Communication Plane: For either home networks or - Separated Local Communication Plane: For either home networks or
enterprise networks, the main purpose of using ULA along with GUA enterprise networks, the main purpose of using ULA along with GUA
is to provide a logically local routing plane separated from the is to provide a logically local routing plane separated from the
globally routing plane. The benefit is to ensure stable and globally routing plane. The benefit is to ensure stable and
specific local communication regardless of the ISP uplink failure. specific local communication regardless of the ISP uplink failure.
This benefit is especially meaningful for the home network or This benefit is especially meaningful for the home network or
private OAM function in an enterprise. private OAM function in an enterprise.
- Renumbering: In some special cases such as renumbering, - Renumbering: In some special cases such as renumbering,
enterprise administrators may want to avoid the need to renumber enterprise administrators may want to avoid the need to renumber
their internal-only, private nodes when they have to renumber the their internal-only, private nodes when they have to renumber the
PA addresses of the whole network because of changing ISPs, ISPs PA addresses of the whole network because of changing ISPs, ISPs
restructure their address allocations, or whatever reasons. In restructure their address allocations, or whatever reasons. In
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
these situations, ULA is an effective tool for the internal-only these situations, ULA is an effective tool for the internal-only
nodes. nodes.
Besides the internal-only nodes, the public nodes can also benefit Besides the internal-only nodes, the public nodes can also benefit
from ULA for renumbering. When renumbering, as RFC4192 suggested, from ULA for renumbering. When renumbering, as RFC4192 suggested,
it has a period to keep using the old prefix(es) before the new it has a period to keep using the old prefix(es) before the new
prefix(es) is(are) stable. In the process of adding new prefix(es) prefix(es) is(are) stable. In the process of adding new prefix(es)
and deprecating old prefix(es), it is not easy to keep the local and deprecating old prefix(es), it is not easy to keep the local
communication immune of global routing plane change. If we use ULA communication immune of global routing plane change. If we use ULA
for the local communication, the separated local routing plane can for the local communication, the separated local routing plane can
isolate the affecting by global routing change. isolate the affecting by global routing change.
o Cons: o Drawbacks:
- Operational Complexity: There are some arguments that in - Operational Complexity: There are some arguments that in
practice the ULA+PA makes additional operational complexity. It is practice the ULA+PA makes additional operational complexity. It is
not a ULA-specific problem; the multiple-addresses-per-interface not a ULA-specific problem; the multiple-addresses-per-interface
is an important feature of IPv6 protocol. Never the less, running is an important feature of IPv6 protocol. Never the less, running
multiple prefixes needs more operational considerations than multiple prefixes needs more operational considerations than
running a single one. running a single one.
o Operational considerations o Operational considerations
- Default Routing: connectivity might be broken if ULAs are used
as default route.
- SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be - SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be
enabled in one network simultaneously; the administrators need to enabled in one network simultaneously; the administrators need to
carefully plan how to assign ULA and GUA prefixes in accordance carefully plan how to assign ULA and GUA prefixes in accordance
with the two mechanisms. The administrators need to know the with the two mechanisms. The administrators need to know the
current issue of the SLAAC/DHCPv6 interaction (please refer to current issue of the SLAAC/DHCPv6 interaction (please refer to
[I-D.liu-bonica-dhcpv6-slaac-problems] for details). [I-D.liu-bonica-dhcpv6-slaac-problems] for details).
- Address Selection: As mentioned in [RFC5220], there is a - Address Selection: As mentioned in [RFC5220], there is a
possibility that the longest matching rule will not be able to possibility that the longest matching rule will not be able to
choose the correct address between ULAs and global unicast choose the correct address between ULAs and global unicast
addresses for correct intra-site and extra-site communication. In addresses for correct intra-site and extra-site communication. In
[RFC6724], it claimed that a site-specific policy entry can be [RFC6724], it claimed that a site-specific policy entry can be
used to cause ULAs within a site to be preferred over global used to cause ULAs within a site to be preferred over global
addresses. addresses.
- DNS Relevant: if administrators chose not to do reverse DNS - DNS Relevant: if administrators chose not to do reverse DNS
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 will significant amount of information about the ULA population might
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 people will be and naturally routed to the global reverse tree, so people will be
exposed to the existence of population the ULA uses, not in exposed to the existence of population the ULA uses, not in
traffic terms, but in knowledge terms. [ULA-IN-WILD] provides more traffic terms, but in knowledge terms. [ULA-IN-WILD] provides more
detailed situations on this issue. detailed situations on this issue.
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October Administrators may need a split DNS to separate the queries from
2013 internal and external for ULA entries and GUA entries.
3.3. IPv4 Co-existence consideration 3.3. IPv4 Co-existence consideration
Generally, this document only concerns IPv6-only scenarios. But one Generally, this document does not consider IPv4 relevant as in the
specific IPv4 co-existence problem need to be noted. scope But regarding ULA, there is a special case needs to be noticed,
which is described in section 2.2.2 of [RFC5220]. When an enterprise
As described in section 2.2.2 of [RFC5220], when an enterprise has has IPv4 Internet connectivity but does not yet have IPv6 Internet
IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, and the enterprise wants to provide site-local IPv6
connectivity, then the enterprise chose ULA for 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 connectivity. Each employee host will have both an IPv4 global or
private address and a ULA. Here, when this host tries to connect to 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 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 DNS, the host will choose AAAA as the destination address and the ULA
for the source address according to the IPv6 preference of the for the source address according to the IPv6 preference of the
default address selection policy [RFC3484]. This will clearly result default address selection policy. This will clearly result in a
in a connection failure. (The new address selection standard [RFC6724] connection failure.
has added ULA specific rules to prefer IPv4 over ULA, but the
majority of current existing hosts might still under the old [RFC3484]
specification.)
Although with Happy Eyeballs [RFC6555] this connection failure Although with Happy Eyeballs [RFC6555] this connection failure
problem could be solved, but unwanted timeouts would obviously lower problem could be solved, but unwanted timeouts would obviously lower
the user experience. One possible approach of eliminating the the user experience. One possible approach of eliminating the
timeouts is configuring IPv4 preference on the hosts, and not timeouts is deprecating IPv6 default route and simply configuring a
including DNS A records but only AAAA records for the internal nodes scoped route on hosts (in the context of this document, only
in the internal DNS server, then outside nodes have both A and AAAA configure the ULA prefix routes).
records could be connected through IPv4 as default and internal nodes
could be always connected through IPv6. But since IPv6 preference is Another alternative is configuring IPv4 preference on the hosts, and
default, changing the default in all nodes is not easy. not including 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 could be connected through IPv4 as default and internal
nodes could be always connected through IPv6. But since IPv6
preference is default, changing the default in all nodes is not
suitable at scale.
4. General Guidelines of using ULA 4. General Guidelines of using ULA
4.1. Do not treat ULA equal to RFC1918 4.1. Do not treat ULA equal to RFC1918
ULA and [RFC1918] are similar in some aspects. The most obvious one ULA and [RFC1918] are similar in some aspects. The most obvious one
is as described in section 2.1.3 that ULA provides an internal is as described in section 2.1.3 that ULA provides an internal
address independence capability in IPv6 that is similar to how address independence capability in IPv6 that is similar to how
[RFC1918] is commonly used. ULA allows administrators to configure [RFC1918] is commonly used. ULA allows administrators to configure
the internal network of each platform the same way it is configured the internal network of each platform the same way it is configured
in IPv4. On the other hand, many organizations have security policies in IPv4. Many organizations have security policies and architectures
and architectures based around the local-only routing of [RFC1918] based around the local-only routing of [RFC1918] addresses and those
addresses and those policies may directly map to ULA [RFC4864]. policies may directly map to ULA [RFC4864].
But it doesn't mean ULA is equal to an IPv6 version of [RFC1918] But it doesn't mean ULA is equal to an IPv6 version of [RFC1918]
deployment. [RFC1918] usually combines with NAT/NAPT for global deployment. [RFC1918] usually combines with NAT/NAPT for global
connectivity. But it is not necessarily to combine ULAs with any kind connectivity. But it is not necessarily to combine ULAs with any kind
of NAT. People could use ULA for local communications along with of NAT. People could use ULA for local communications along with
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
global addresses for global communications (see section 5.2). This is global addresses for global communications (see section 5.2). This is
a big advantage brought by default support of multiple-addresses-per- a big advantage brought by default support of multiple-addresses-per-
interface feature in IPv6. (People might still have requirement of interface feature in IPv6. (People might still have requirement of
ULA with NAT, this is discussed in section 3.2.1. But people also ULA with NAT, this is discussed in section 3.2.1. But people also
should keep in mind that ULA is not intentionally designed for this should keep in mind that ULA is not intentionally designed for this
kind of use case.) kind of use case.)
Another important difference is the ability to merge two ULA networks Another important difference is the ability to merge two ULA networks
without renumbering (because of the uniqueness), which is a big without renumbering (because of the uniqueness), which is a big
advantage over [RFC1918]. advantage over [RFC1918].
skipping to change at page 10, line 29 skipping to change at page 10, line 30
4.2. Using ULAs in a limited scope 4.2. Using ULAs in a limited scope
A ULA is by definition a prefix that is never advertised outside a 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 given domain, and is used within that domain by agreement of those
networked by the domain. networked by the domain.
So when using ULAs in a network, the administrators should clearly So when using ULAs in a network, the administrators should clearly
set the scope of the ULAs and configure ACLs on relevant border set the scope of the ULAs and configure ACLs on relevant border
routers to block them out of the scope. And if internal DNS are routers to block them out of the scope. And if internal DNS are
enabled, the administrators might also need to use internal-only DNS enabled, the administrators might also need to use internal-only DNS
names for ULAs. names for ULAs and should split the DNS so that the internal DNS
server includes records that are not presented in the external DNS
server.
5. ULA usage recommendations 5. ULA usage recommendations
5.1. Used in Isolated Networks 5.1. Used in Isolated Networks
As analyzed in section 3.1, ULA is very suitable for isolated As analyzed in section 3.1, ULA is very suitable for isolated
networks. Especially when you have subnets in the isolated networks, networks. Especially when you have subnets in the isolated networks,
ULA is the best choice. ULA is the best choice.
5.2. ULA along with GUA 5.2. ULA along with GUA
As the benefits described in Section 3.2.2, using ULA along with GUA As the benefits described in Section 3.2.2, using ULA along with GUA
to provide a logically separated local plane could benefit to OAM to provide a logically separated local plane could benefit to OAM
functions and renumbering. functions and renumbering.
5.3. Recommended Specific Use Cases 5.3. Recommended Specific Use Cases
Along with the general scenarios, this section provide 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.
5.3.1. Special routing 5.3.1. Special routing
For various reasons the administrators might want to have private For various reasons the administrators might want to have private
routing be controlled and separated from other routing. For example, routing be controlled and separated from other routing. For example,
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
in the b2b case described in in the b2b 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 such prefixes that would be used in accordance simple way to assign such prefixes that would be used in accordance
with an agreement between the parties. with an agreement between the parties.
5.3.2. Used as NAT64 prefix 5.3.2. Used as NAT64 prefix
Since the NAT64 pref64 is just a group of local fake addresses for Since the NAT64 pref64 is just a group of local fake addresses for
skipping to change at page 11, line 46 skipping to change at page 11, line 47
It is most common that ULA Pref64 will be deployed on a single 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, where the clients and the NAT64 share a common
internal network. ULA will not be effective as Pref64 when the access internal network. ULA will not be effective as Pref64 when the access
network must use an Internet transit to receive the translation network must use an Internet transit to receive the translation
service of a NAT64 since the ULA will not route across the internet. service of a NAT64 since the ULA will not route across the internet.
According to the default address selection table specified in According to the default address selection table specified in
[RFC6724], the host would always prefer IPv4 over ULA. This could be [RFC6724], the host would always prefer IPv4 over ULA. This could be
a problem in NAT64-CGN scenario as analyzed in Section 8 of a problem in NAT64-CGN scenario as analyzed in Section 8 of
[I-D.ietf-v6ops-nat64-experience]. So site-specific address selection [I-D.ietf-v6ops-nat64-experience]. So administrators need to add
policy table would be needed. However, it involves significant costs additional site-specific address selection rules to the default table
to change terminal's behavior. 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.
5.3.3. Used as identifier 5.3.3. Used as identifier
Since ULA could be self-generated and easily grabbed from the ULAs could be self-generated and easily grabbed from the standard
standard IPv6 stack, it is very suitable to be used as identifiers by 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 layer
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October applications. And since ULA is not intended to be globally routed, it
2013 is not harmful to the routing system.
the up layer applications. And since ULA is not intended to be
globally 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
according to the following considerations: according to the following considerations:
o TCP connections between two end hosts wish to survive in network o TCP connections between two end hosts wish to survive in network
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
skipping to change at page 12, line 35 skipping to change at page 12, line 39
could be ignored by most of the cases when used as identifiers. could be ignored by most of the cases when used as identifiers.
6. Security Considerations 6. Security Considerations
Security considerations regarding ULAs, in general, please refer to Security considerations regarding ULAs, in general, please refer to
the ULA specification [RFC4193]. the ULA specification [RFC4193].
Also refer to [RFC4864], which shows how ULAs help with local network Also refer to [RFC4864], which shows how ULAs help with local network
protection. protection.
As mentioned in Section 3.2.1, when use NPTv6, the administrators
need to know about where the firewall is located to set proper
filtering rules.
As mentioned in Section 3.2.2, if administrators chose not to do
reverse DNS delegation inside their local control of ULA prefixes, a
significant amount of information about the ULA population might leak
to the outside world.
7. IANA Considerations 7. IANA Considerations
IANA considerations should be updated to point to RFC4193 in a IANA considerations should be updated to point to RFC4193 in a
similar manner to section 4. similar manner to section 4.
8. Conclusions 8. Conclusions
ULA is a useful tool, it could be successfully deployed in a diverse ULA is a useful tool; it could be successfully deployed in a diverse
set of circumstances including large private machine-to-machine type set of circumstances including large private machine-to-machine type
networks, enterprise networks with private systems, and within networks, enterprise networks with private systems, and within
service providers to limit Internet communication with non-public service providers to limit Internet communication with non-public
services such as caching DNS servers and NAT64 translation resources. services such as caching DNS servers and NAT64 translation resources.
Some of the deployment is already in real production networks. Some of the deployment is already in real production networks.
We should eliminate the misunderstanding that ULA is just an IPv6 We should eliminate the misunderstanding that ULA is just an IPv6
version of [RFC1918]. The features of ULA could be beneficial for version of [RFC1918]. The features of ULA could be beneficial for
various use cases. various use cases.
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
9. References 9. References
9.1. Normative References 9.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", RFC 2119, BCP14, March 1997. Requirement Levels", RFC 2119, BCP14, March 1997.
[RFC4193] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
skipping to change at page 14, line 5 skipping to change at page 14, line 22
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, (IPv6)", RFC 6724,
[I-D.ietf-v6ops-nat64-experience] [I-D.ietf-v6ops-nat64-experience]
Chen G., Cao Z., Xie C., and D. Binet, "NAT64 Operational Chen G., Cao Z., Xie C., and D. Binet, "NAT64 Operational
Experiences", Working in Progress, October, 2013 Experiences", Working in Progress, October, 2013
[I-D.baker-v6ops-b2b-private-routing] [I-D.baker-v6ops-b2b-private-routing]
F. Baker, "Business to Business Private Routing", Expired F. Baker, "Business to Business Private Routing", Expired
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
[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 Networks", "Router Advertisements for Routing between Moving Networks",
Working in Progress, October, 2013 Working in Progress, October, 2013
[I-D.jhlee-mext-mnpp] [I-D.jhlee-mext-mnpp]
Lee, J.-H., and T. Ernst, "Mobile Network Prefix Lee, J.-H., and T. Ernst, "Mobile Network Prefix
Provisioning", Expired Provisioning", Expired
[RS-485] http://en.wikipedia.org/wiki/RS-485 [RS-485] http://en.wikipedia.org/wiki/RS-485
skipping to change at page 14, line 31 skipping to change at page 14, line 45
[SCADA] http://en.wikipedia.org/wiki/SCADA [SCADA] http://en.wikipedia.org/wiki/SCADA
[ULA-IN-WILD] [ULA-IN-WILD]
G. Michaelson, "www.ietf.org/proceedings/87/slides/slides- G. Michaelson, "www.ietf.org/proceedings/87/slides/slides-
87-v6ops-0.pdf" 87-v6ops-0.pdf"
10. Acknowledgments 10. Acknowledgments
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 Fred Baker, Brian Carpenter, Victor Kuarsingh, especially from Fred Baker, Brian Carpenter, Lee Howard, Victor
Alexandru Petrescu, Mikael Abrahamsson, Jong-Hyouk Lee, Doug Barton, Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Jong-Hyouk Lee,
Owen Delong, Anders Brandt and Wesley George. Doug Barton, Owen Delong, Anders Brandt, Tim Chown, Jen Linkova,
Christopher Palmer and Wesley George.
Some contribution regarding vehicle networks is from Sofiane Imadali. Some test of using ULA in the lab was done by our research partner
BNRC-BUPT (Broad Network Research Centre in Beijing University of
Posts and Telecommunications). Thanks for the work of Prof. Xiangyang
Gong and student Dengjia Xu.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Internet-Draft draft-ietf-v6ops-ula-usage-recommendations-01 October
2013
Authors' Addresses Authors' Addresses
Bing Liu Bing Liu
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd., Huawei Q14 Building, No.156 Beiqing Rd.,
Zhong-Guan-Cun Environmental Protection Park, Beijing Zhong-Guan-Cun Environmental Protection Park, Beijing
P.R. China P.R. China
EMail: leo.liubing@huawei.com EMail: leo.liubing@huawei.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd., Huawei Q14 Building, No.156 Beiqing Rd.,
Zhong-Guan-Cun Environmental Protection Park, Beijing Zhong-Guan-Cun Environmental Protection Park, Beijing
P.R. China P.R. China
EMail: jiangsheng@huawei.com EMail: jiangsheng@huawei.com
Cameron Byrne
T-Mobile USA
Bellevue, Washington 98006
USA
Email: cameron.byrne@t-mobile.com
 End of changes. 49 change blocks. 
135 lines changed or deleted 118 lines changed or added

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