draft-ietf-v6ops-ula-usage-recommendations-02.txt   draft-ietf-v6ops-ula-usage-recommendations-03.txt 
Network Working Group B. Liu
Internet Draft S. Jiang Internet Engineering Task Force B. Liu
Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: August 18, 2014 February 14, 2014 Expires: January 5, 2015 July 4, 2014
Recommendations of Using Unique Local Addresses Considerations of Using Unique Local Addresses
draft-ietf-v6ops-ula-usage-recommendations-02.txt draft-ietf-v6ops-ula-usage-recommendations-03
Status of this Memo Abstract
This document provides considerations of how to use ULAs. It
analyzes ULA usage scenarios and considers some use cases of ULA
addresses as helpful.
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
documents as Internet-Drafts. The list of current Internet-Drafts is working documents as Internet-Drafts. The list of current Internet-
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 August 18, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
as they describe your rights and restrictions with respect to this carefully, as they describe your rights and restrictions with respect
document. Code Components extracted from this document must include to this document. Code Components extracted from this document must
Simplified BSD License text as described in Section 4.e of the Trust include Simplified BSD License text as described in Section 4.e of
Legal Provisions and are provided without warranty as described in the Trust Legal Provisions and are provided without warranty as
the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document provides guidance of how to use ULAs. It analyzes ULA
usage scenarios and recommends use cases where ULA addresses might be
beneficially used.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The analysis of ULA features ................................. 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2.1. Automatically Generated ................................. 3 3. Analysis of ULA Features . . . . . . . . . . . . . . . . . . 3
2.2. Globally unique.......................................... 3 3.1. Automatically Generated . . . . . . . . . . . . . . . . . 3
2.3. Independent address space ............................... 4 3.2. Globally Unique . . . . . . . . . . . . . . . . . . . . . 3
2.4. Well known prefix ....................................... 4 3.3. Independent Address Space . . . . . . . . . . . . . . . . 3
2.5. Stable or Temporary Prefix .............................. 4 3.4. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
3. Enumeration of Scenarios Using ULAs .......................... 4 3.5. Stable or Temporary Prefix . . . . . . . . . . . . . . . 4
3.1. Isolated network ........................................ 4 4. Enumeration of Scenarios Using ULAs . . . . . . . . . . . . . 4
3.2. Connected network ....................................... 5 4.1. Isolated Networks . . . . . . . . . . . . . . . . . . . . 4
3.2.1. ULA-only Deployment ................................ 5 4.2. Connected Network . . . . . . . . . . . . . . . . . . . . 6
3.2.2. ULA along with GUA ................................. 7 4.2.1. ULA-Only Deployment . . . . . . . . . . . . . . . . . 6
3.3. IPv4 Co-existence consideration ......................... 9 4.2.2. ULAs along with PA Addresses . . . . . . . . . . . . 7
4. General Guidelines of using ULA .............................. 9 4.3. IPv4 Co-existence Considerations . . . . . . . . . . . . 9
4.1. Do not treat ULA equal to RFC1918 ....................... 9 5. General Guidelines of Using ULA . . . . . . . . . . . . . . . 10
4.2. Using ULAs in a limited scope .......................... 10 5.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 10
5. ULA usage recommendations ................................... 10 5.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 10
5.1. Used in Isolated Networks .............................. 10 6. ULA Usages Considered Helpful . . . . . . . . . . . . . . . . 11
5.2. ULA along with GUA ..................................... 10 6.1. Used in Isolated Networks . . . . . . . . . . . . . . . . 11
5.3. Recommended Specific Use Cases ......................... 10 6.2. ULA along with PA . . . . . . . . . . . . . . . . . . . . 11
5.3.1. Special routing ................................... 11 6.3. Some Specific Use Cases . . . . . . . . . . . . . . . . . 11
5.3.2. Used as NAT64 prefix .............................. 11 6.3.1. Special Routing . . . . . . . . . . . . . . . . . . . 11
5.3.3. Used as identifier ................................ 12 6.3.2. Used as NAT64 Prefix . . . . . . . . . . . . . . . . 11
6. Security Considerations ..................................... 12 6.3.3. Used as Identifier . . . . . . . . . . . . . . . . . 12
7. IANA Considerations ......................................... 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Conclusions ................................................. 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References .................................................. 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References ................................... 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References ................................. 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments ............................................ 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 .etc. Although ULAs may be treated like global
applications, normally they should not be used on the publicly scope by applications, normally they should not be used on the
routable internet. publicly Internet. Since site-local addresses are deprecated in
[RFC3879], ULAs could be alternatives of site-local addresses in some
situations (but they are not equal).
However, the ULAs haven't been widely used since IPv6 hasn't been However, the use of ULAs in various types of networks has been
widely deployed yet. The use of ULA addresses in various types of confusing to network operators. This document aims to clarify the
networks has been confusing to network operators. This document aims advantages and disadvantages of ULAs and how they can be most
to clarify the advantages and disadvantages of ULAs and how they can appropriately used.
be most appropriately used.
2. The analysis of ULA features 2. Requirements Language
2.1. Automatically Generated The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key
words.
3. Analysis of ULA Features
3.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 prefixes allocation, thus one can get a network work immediately
and can leverage minimal human management. without applying prefix (es) from an RIR/LIR (Regional Internet
Registry/Local Internet Registry).
2.2. Globally unique 3.2. Globally Unique
ULA is intended to have an extremely low probability of collision. ULAs are intended to have an extremely low probability of collision.
Since the hosts assigned with ULA may occasionally be merged into one Since the hosts assigned with ULAs may occasionally be merged into
network, this uniqueness is necessary. The prefix uniqueness is based one network, this uniqueness is necessary. The randomization of 40
on randomization of 40 bits and is considered random enough to ensure bits in a ULA prefix is considered sufficient enough to ensure a high
a high degree of uniqueness (refer to [RFC4193] section 3.2.3 for degree of uniqueness (refer to [RFC4193] Section 3.2.3 for details)
details)and make merging of networks simple and without the need to and makes merging of networks simple and without the need to renumber
renumbering overlapping IP address space. Overlapping is cited as a overlapping IP address space. Overlapping is cited as a deficiency
deficiency with how [RFC1918] addresses were deployed, and ULA was with how [RFC1918] addresses were deployed, and ULA was designed to
designed to overcome this deficiency. overcome this deficiency.
Notice that, as described in [RFC4864], in practice, applications may Note 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
(Note: the new address selection standard has supported this in the communications. (Note: the new address selection standard has
default policy table. [RFC6724]) supported this in the default policy table. [RFC6724])
2.3. Independent address space 3.3. Independent Address Space
ULA provides an internal address independence capability in IPv6ULA ULAs provide internal address independence in IPv6 that they can be
can be used for internal communications without having any permanent used for internal communications without having any permanent or only
or only intermittent Internet connectivity. And it needs no intermittent Internet connectivity. And it needs no registration so
registration so that it can support on-demand usage and does not that it can support on-demand usage and does not carry any RIR/LIR
carry any RIR documentation burden or disclosures. documentation/fees burden or disclosures.
2.4. Well known prefix 3.4. Well Known Prefix
The prefixes of ULAs are well known and they are easy to be The prefixes of ULAs are well known thus they are easy to be
identified and easy to be filtered. identified and filtered.
This feature may be convenient to management of security policies and This feature is convenient for management of security policies and
troubleshooting. For example, the administrators can decide what troubleshooting. For example, the administrators can decide what
parameters have to be assembled or transmitted globally, by a parameters have to be assembled or transmitted globally, by a
separate function, through an appropriate gateway/firewall, to the separate function, through an appropriate gateway/firewall, to the
Internet or to the telecom network. Internet or to the telecom network.
2.5. Stable or Temporary Prefix 3.5. Stable or Temporary Prefix
A ULA prefix can be generated once, at installation time or "factory
reset", and then never change unless the network manager wants to
change. Alternatively, it could be regenerated regularly, if desired
for some reason.
3. Enumeration of Scenarios Using ULAs A ULA prefix can be generated once, at installation time or factory
reset, and then probably never be changed. Alternatively, it could
be regenerated regularly, if desired for some reason.
In this section, we cover possible ULA use cases. Some of them might 4. Enumeration of Scenarios Using ULAs
have been discussed in other documents and are briefly reviewed in
this document as well as other potential valid usage is discussed.
3.1. Isolated network 4.1. 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 interface like (e.g. [RS-485], [SCADA], or even non-networked digital interface
[MIL-STD-1397] began to use IP protocol. In such kind of networks, like [MIL-STD-1397] began to use IP protocol. In such kind of
the system might lack the ability/requirement of connecting to the networks, the system might lack the ability/requirement of connecting
Internet. or explicitly designed not to connect. to the 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.
vehichle networks), sensor networks, or even normal LANs, which may vehicle 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. Also, ULAs fit networks with minimal administrative cost or burden. Also, ULAs fit
in multiple subnet scenarios, in which each subnet has its own ULA in multiple subnet scenarios, in which each subnet has its own ULA
prefix. For example, when we assign vehicles with ULA addresses, it prefix. For example, when we assign vehicles with ULA addresses, it
is then possible to separate in-vehicle embedded networks into is then possible to separate in-vehicle embedded networks into
different subnets depending on real-time requirements, devices types, different subnets depending on real-time requirements, devices types,
services and more. services and more.
o Benefits of Using ULAs in Isolated Networks: However, each isolated network has the possibility to be connected in
- No cost of RIR/LIR fees or operational burden the future. The administrators need to consider following things:
- Could be used instantly on-demand
- Scalable to support multiple subnets o If it connects to another isolated/private network, then comes the
- Extremely low probability of collision when isolated networks collision problem. However, if the ULAs were generated by the
standard way, this won't be a big problem.
o If it connects to the global Internet, then need some operation to
add a new global prefix and ensure the address selection policy in
the proper form.
If these further operations/considerations are unacceptable for some
reasons, then the administrators need to be careful with using ULAs
in current isolated networks.
Benefits of using ULAs in isolated networks:
o No cost of fees or operational burden of applying GUA prefix(es)
from RIR/LIR
o Could be used instantly on-demand
o Scalable to support multiple subnets
o Extremely low probability of collision when isolated networks
merge merge
o Drawbacks: Drawbacks:
- The uniqueness of the global ULA prefix is not guaranteed,
however, the probability of collision is extremely low
o Operational considerations o The uniqueness of the global ULA prefix is not guaranteed,
- Prefix generation: Randomly generated according to the however, the probability of collision is extremely low.
algorithms defined in [RFC4193] or literally assigned by human.
Normally, it is recommended to following the standard way to
automatically generate the prefixes; if there are some specific
reasons that need to be assigned by human, the administrators must
carefully plan the prefixes to avoid collision.
- Prefix announcement: In some cases, the networks might need to Operational considerations:
o Prefix generation: Randomly generated according to the algorithms
defined in [RFC4193] or literally assigned by human. Normally, it
is recommended to following the standard way to automatically
generate the prefixes; if there are some specific reasons that
need to be assigned by human, the administrators must carefully
plan the prefixes to avoid collision.
o 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]).
3.2. Connected network 4.2. Connected Network
3.2.1. ULA-only Deployment 4.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
the following two models. includes the following two models.
o Using Network Prefix Translation o Using Network Prefix Translation
Network Prefix Translation (NPTv6) [RFC6296] is an experimental Network Prefix Translation (NPTv6) [RFC6296] is an experimental
specification that provides a stateless one to one mapping between specification that provides a stateless one to one mapping
internal addresses and external addresses. between internal addresses and external addresses. The
specification considers translating ULA prefixes into GUA
prefixes as a use case. Although NPTv6 works differently to
traditional stateful NAT/NAPT (which is discouraged in
[RFC5902]), it also introduces some similar additional
complexity to applications, which might cause applications to
break.
In some very constrained situations(for example, in the sensors), the Thus this document does not recommend the use of ULA+NPTv6.
network needs ULA as the on-demand and stable addressing which Rather, this document considers ULA+PA (Provider Aggregated) as
doesn't need much code to support address assignment mechanisms like a better approach to connect to the global network when ULAs
DHCP or full ND (Note: surely it needs SLAAC). If the network also are expected to be retained. The use of ULA+PA is discussed in
needs to connect to the outside, then there can be an NPTv6 gateway detail in Section 4.2.2 below.
which is not subject to extreme resource constraints. Especially when
a lightweight isolated network needs to add Internet connectivity,
this is quite a straightforward and efficient way.
This document does not intend to encourage the ULA binding with NPTv6 o Using Application-Layer Proxies
model, since in [RFC5902] the IAB had already gave opinions on IPv6
NAT; but this document considers it as an effective approach in some
specific situations as described above.
o Using application-layer proxies The proxies terminate the network-layer connectivity of the
hosts and delegate the outgoing/incoming connections.
The proxies terminate the network-layer connectivity of the hosts and In some environments (e.g. Information security sensitive
delegate the outgoing/incoming connections. enterprise or government), the endpoints are default
disconnected to the Internet, and need the proxies to connect
for central control. In IPv4, using private address space with
proxies is an effective and common practice for this purpose,
and it is natural to pick ULA in IPv6.
In some environments (e.g. information security sensitive enterprise Benefits of using ULAs in this scenario:
or government), the endpoints are default disconnected to the
Internet, and need the proxies to connect for central control. In
IPv4, using private address space with proxies is an effective and
common practice for this purpose, and it is natural to pick ULA in
IPv6.
o Benefits of Using ULAs in This Scenario: o Allowing minimal management burden on address assignment for some
- Allowing minimal management burden on address assignment for specific environments.
some specific environments.
o Drawbacks: Drawbacks:
- The serious disadvantages and impact on applications by NAT have
been well documented in [RFC2993] and [RFC3027]. However, it o The serious disadvantages and impact on applications by NAT have
should be noted that, For NPTv6, as described in [RFC6296], it is been well documented in [RFC2993] and [RFC3027]. Although NPTv6
"a mechanism that has fewer architectural problems than merely is 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 [RFC6296], it still beaks the end-to-end
transparency which is in general not recommended by the IETF.
o Operational considerations Operational considerations:
- Firewall Deployment: As described in [RFC6296], firewall is
recommended to be implemented with NPTv6 translator. Then the o Firewall deployment: as described in [RFC6296], firewall is
recommended to be implemented with NPTv6 translator. Then the
administrators need to know about where the firewall is located. administrators need to know about where the firewall is located.
If the firewall is located outside the NPTv6 translator, then the
filtering is based on the translated GUA prefixes, and when the
internal ULA prefixes are renumbered, the filtering rules don't
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 - If the firewall is located outside the NPTv6 translator, then
the filtering is based on the translated GUA prefixes, and when
the internal ULA prefixes are renumbered, the filtering rules
don't need to be changed (however, when GUA prefixes of the
NPTv6 are renumbered, the filtering rules need to be updated
accordingly.).
There are two classes of network probably to use ULA with GUA - If the firewall is located inside the NPTv6 translator, the
addresses: 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.).
- Home network. Home networks are normally assigned with one or 4.2.2. ULAs along with PA Addresses
There are two classes of network probably to use ULA with PA
(Provider Aggregated) addresses:
o 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
when the ISP link is down. Then ULA is a proper tool to fit the even when the ISP link is down. Then ULA is a proper tool to fit
requirement. And in [RFC6204], it requires the CPE to support ULA. the requirement. And in [RFC6204], it requires the CPE to support
Note, ULAs provide more benefit for multiple-segment home networks; ULA. Note, ULAs provide more benefit for multiple-segment home
for home networks only containing one segment, link-local networks; for home networks only containing one segment, link-
addresses are better alternative. local addresses are better alternatives.
- Enterprise network. An enterprise network is usually a managed o 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 Benefits of Using ULAs in This Scenario: Benefits of Using ULAs in this scenario:
- Separated Local Communication Plane: For either home networks or
enterprise networks, the main purpose of using ULA along with GUA
is to provide a logically local routing plane separated from the
globally routing plane. The benefit is to ensure stable and
specific local communication regardless of the ISP uplink failure.
This benefit is especially meaningful for the home network or
private OAM function in an enterprise.
- Renumbering: In some special cases such as renumbering, o Separated local communication plane: for either home networks or
enterprise administrators may want to avoid the need to renumber enterprise networks, the main purpose of using ULAs along with PA
their internal-only, private nodes when they have to renumber the addresses is to provide a logically local routing plane separated
PA addresses of the whole network because of changing ISPs, ISPs from the globally routing plane. The benefit is to ensure stable
restructure their address allocations, or whatever reasons. In and specific local communication regardless of the ISP uplink
failure. This benefit is especially meaningful for the home
network or private OAM function in an enterprise.
o Renumbering: in some special cases such as renumbering, enterprise
administrators may want to avoid the need to renumber their
internal-only, private nodes when they have to renumber the PA
addresses of the whole network because of changing ISPs, ISPs
restructure their address allocations, or whatever reasons. In
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
Besides the internal-only nodes, the public nodes can also benefit benefit from ULA for renumbering. When renumbering, as [RFC4192]
from ULA for renumbering. When renumbering, as RFC4192 suggested, suggested, it has a period to keep using the old prefix(es) before
it has a period to keep using the old prefix(es) before the new the new prefix(es) is(are) stable. In the process of adding new
prefix(es) is(are) stable. In the process of adding new prefix(es) prefix(es) and deprecating old prefix(es), it is not easy to keep
and deprecating old prefix(es), it is not easy to keep the local the local communication immune of global routing plane change. If
communication immune of global routing plane change. If we use ULA we use ULAs for the local communication, the separated local
for the local communication, the separated local routing plane can routing plane can isolate the affecting by global routing change.
isolate the affecting by global routing change.
o Drawbacks: Drawbacks:
- Operational Complexity: There are some arguments that in
practice the ULA+PA makes additional operational complexity. It is o Operational Complexity: there are some arguments that in practice
not a ULA-specific problem; the multiple-addresses-per-interface the ULA+PA makes additional operational complexity. It is not a
is an important feature of IPv6 protocol. Never the less, running ULA-specific problem; the multiple-addresses-per-interface 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 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 o Default Routing: connectivity might be broken if ULAs are used as
enabled in one network simultaneously; the administrators need to default route. When using RIO (Route Information Option) in
carefully plan how to assign ULA and GUA prefixes in accordance [RFC4191], specific routs would be added without a default route,
with the two mechanisms. The administrators need to know the thus bad user experience of timeouts on ICMPv6 redirects are
avoided. This behavior was well documented in [RFC7084] as rule
ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all of
its configured and delegated prefixes are ULA prefixes." and along
with rule L-3 "An IPv6 CE router MUST advertise itself as a router
for the delegated prefix(es) (and ULA prefix if configured to
provide ULA addressing) using the "Route Information Option"
specified in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the WAN
interface.". However, it should be noticed that current OSes
don't all support [RFC4191].
o SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be enabled
in one network simultaneously; the administrators need to
carefully plan how to assign ULA and PA prefixes in accordance
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.ietf-v6ops-dhcpv6-slaac-problem] for details).
- Address Selection: As mentioned in [RFC5220], there is a o 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 o 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 might 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
detailed situations on this issue. more detailed situations on this issue. Administrators may need a
split DNS to separate the queries from internal and external for
Administrators may need a split DNS to separate the queries from ULA entries and GUA entries.
internal and external for ULA entries and GUA entries.
3.3. IPv4 Co-existence consideration 4.3. IPv4 Co-existence Considerations
Generally, this document does not consider IPv4 relevant as in the Generally, this document does not consider IPv4 relevant as in the
scope But regarding ULA, there is a special case needs to be noticed, 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 which is described in Section 3.2.2 of [RFC5220]. When an enterprise
has IPv4 Internet connectivity but does not yet have IPv6 Internet has IPv4 Internet connectivity but does not yet have IPv6 Internet
connectivity, and the enterprise wants to provide site-local IPv6 connectivity, and the enterprise wants to provide site-local IPv6
connectivity, a ULA is the best choice 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. This will clearly result in a default address selection policy. This will clearly result in a
connection failure. connection failure.
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 deprecating IPv6 default route and simply configuring a timeouts is deprecating IPv6 default route and simply configuring a
scoped route on hosts (in the context of this document, only scoped route on hosts (in the context of this document, only
configure the ULA prefix routes). configure the ULA prefix routes). Another alternative is configuring
IPv4 preference on the hosts, and not including DNS A records but
Another alternative is configuring IPv4 preference on the hosts, and only AAAA records for the internal nodes in the internal DNS server,
not including DNS A records but only AAAA records for the internal then outside nodes have both A and AAAA records could be connected
nodes in the internal DNS server, then outside nodes have both A and through IPv4 as default and internal nodes could be always connected
AAAA records could be connected through IPv4 as default and internal through IPv6. But since IPv6 preference is default, changing the
nodes could be always connected through IPv6. But since IPv6 default in all nodes is not suitable at scale.
preference is default, changing the default in all nodes is not
suitable at scale.
4. General Guidelines of using ULA 5. General Guidelines of Using ULA
4.1. Do not treat ULA equal to RFC1918 5.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 3.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. Many organizations have security policies and architectures in IPv4. Many organizations have security policies and architectures
based around the local-only routing of [RFC1918] addresses and those based around the local-only routing of [RFC1918] 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
of NAT. People could use ULA for local communications along with kind of NAT. People could use ULA for local communications along
global addresses for global communications (see section 5.2). This is with global addresses for global communications (see Section 6.2).
a big advantage brought by default support of multiple-addresses-per- This is a big advantage brought by default support of multiple-
interface feature in IPv6. (People might still have requirement of addresses-per-interface feature in IPv6. (People might still have
ULA with NAT, this is discussed in section 3.2.1. But people also requirement of ULA with NAT, this is discussed in Section 4.2.1. But
should keep in mind that ULA is not intentionally designed for this people also should keep in mind that ULA is not intentionally
kind of use case.) designed for this 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].
4.2. Using ULAs in a limited scope 5.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 and should split the DNS so that the internal DNS 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 includes records that are not presented in the external DNS
server. server.
5. ULA usage recommendations 6. ULA Usages Considered Helpful
5.1. Used in Isolated Networks 6.1. Used in Isolated Networks
As analyzed in section 3.1, ULA is very suitable for isolated As analyzed in Section 4.1, ULA is very suitable for isolated
networks. Especially when you have subnets in the isolated networks, networks. Especially when there are subnets in the isolated network,
ULA is the best choice. ULA is a reasonable choice.
5.2. ULA along with GUA 6.2. ULA along with PA
As the benefits described in Section 3.2.2, using ULA along with GUA As the benefits described in Section 4.2.2, using ULAs along with PA
to provide a logically separated local plane could benefit to OAM addresses to provide a logically separated local plane could benefit
functions and renumbering. to OAM functions and renumbering.
5.3. Recommended Specific Use Cases 6.3. 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.
5.3.1. Special routing 6.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,
in the b2b case described in in the b2b case described in [I-D.baker-v6ops-b2b-private-routing],
[I-D.baker-v6ops-b2b-private-routing], two companies might want to two companies might want to use direct connectivity that only
use direct connectivity that only connects stated machines, such as a connects stated machines, such as a silicon foundry with client
silicon foundry with client engineers that use it. A ULA provides a engineers that use it. A ULA provides a simple way to assign such
simple way to assign such prefixes that would be used in accordance prefixes that would be used in accordance with an agreement between
with an agreement between the parties. the parties.
5.3.2. Used as NAT64 prefix 6.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
the DNS64 to point traffic to a NAT64, When using a ULA prefix as the the DNS64 to point traffic to a NAT64, When using a ULA prefix as the
pref64, it could easily ensures that only local systems can use the pref64, it could easily ensures that only local systems can use the
translation resources of the NAT64 system since the ULA is not translation resources of the NAT64 system since the ULA is not
intended to be globally routable and helps clearly identify traffic intended to be globally routable and helps clearly identify traffic
that is locally contained and destine to a NAT64. Using ULA for that is locally contained and destine to a NAT64. Using ULA for
Pref64 is deployed and it is an operational model. Pref64 is deployed and it is an operational model.
But there's an issue should be noticed. The NAT64 standard [RFC6146) But there's an issue should be noticed. The NAT64 standard [RFC6146]
mentioned the pref64 should align with [RFC6052], in which the IPv4- mentioned the pref64 should align with [RFC6052], in which the
Embedded IPv6 Address format was specified. If we pick a /48 for IPv4-Embedded IPv6 Address format was specified. If we pick a /48
NAT64, it happened to be a standard 48/ part of ULA (7bit ULA famous for NAT64, it happened to be a standard 48/ part of ULA (7bit ULA
prefix+ 1 "L" bit + 40bit Global ID). Then the 40bit of ULA is not famous prefix+ 1 "L" bit + 40bit Global ID). Then the 40bit of ULA
violated to be filled with part of the 32bit IPv4 address. This is is not violated to be filled with part of the 32bit IPv4 address.
important, because the 40bit assures the uniqueness of ULA, if the This is important, because the 40bit assures the uniqueness of ULA,
prefix is shorter than /48, the 40bit would be violated, and this may if the prefix is shorter than /48, the 40bit would be violated, and
cause conformance issue. But it is considered that the most common this may cause conformance issue. But it is considered that the most
use case will be a /96 PREF64, or even /64 will be used. So it seems common use case will be a /96 PREF64, or even /64 will be used. So
this issue is not common in current practice. it seems this issue is not common in current practice.
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
network must use an Internet transit to receive the translation access network must use an Internet transit to receive the
service of a NAT64 since the ULA will not route across the internet. translation 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 administrators need to add [RFC7269]. So administrators need to add additional site-specific
additional site-specific address selection rules to the default table address selection rules to the default table to steer traffic flows
to steer traffic flows going through NAT64-CGN. However, updating the going through NAT64-CGN. However, updating the default policy tables
default policy tables in all hosts involves significant management in all hosts involves significant management cost. This may be
cost. This may be possible in an enterprise (using a group policy possible in an enterprise (using a group policy object, or other
object, or other configuration mechanisms), but it is not suitable at configuration mechanisms), but it is not suitable at scale for home
scale for home networks. networks.
5.3.3. Used as identifier 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 do. IPv6 stack. And ULAs don't need to be changed as the GUA prefixes
So they are very suitable to be used as identifiers by the up layer do. So they are very suitable to be used as identifiers by the up
applications. And since ULA is not intended to be globally routed, it layer applications. And since ULA is not intended to be globally
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
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
key so that the Security Association can survive the location key so that the Security Association can survive the location
changes. changes.
It should be noticed again that in theory ULA has the possibility of It should be noticed again that in theory ULA has the possibility of
collision. However, the probability is desirable small enough and collision. However, the probability is desirable small enough and
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 7. 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 protection.
Also refer to [RFC4864], which shows how ULAs help with local network
protection.
As mentioned in Section 3.2.1, when use NPTv6, the administrators As mentioned in Section 5.2.1, when use NPTv6, the administrators
need to know about where the firewall is located to set proper need to know about where the firewall is located to set proper
filtering rules. filtering rules.
As mentioned in Section 3.2.2, if administrators chose not to do As mentioned in Section 5.2.2, if administrators chose not to do
reverse DNS delegation inside their local control of ULA prefixes, a reverse DNS delegation inside their local control of ULA prefixes, a
significant amount of information about the ULA population might leak significant amount of information about the ULA population might leak
to the outside world. to the outside world.
7. IANA Considerations 8. 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 5.
8. Conclusions 9. Acknowledgements
ULA is a useful tool; it could be successfully deployed in a diverse Many valuable comments were received in the IETF v6ops WG mail list,
set of circumstances including large private machine-to-machine type especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee
networks, enterprise networks with private systems, and within Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim
service providers to limit Internet communication with non-public Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews,
services such as caching DNS servers and NAT64 translation resources. Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton,
Some of the deployment is already in real production networks. Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler,
Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali
and Wesley George.
We should eliminate the misunderstanding that ULA is just an IPv6 Some test of using ULA in the lab was done by our research partner
version of [RFC1918]. The features of ULA could be beneficial for BNRC-BUPT (Broad Network Research Centre in Beijing University of
various use cases. Posts and Telecommunications). Thanks for the work of Prof.
Xiangyang Gong and student Dengjia Xu.
9. References This document was produced using the xml2rfc tool [RFC2629]
(initially prepared using 2-Word-v2.0.template.dot.).
9.1. Normative References 10. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 10.1. Normative References
Requirement Levels", RFC 2119, BCP14, March 1997.
[RFC4193] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Addresses", RFC 4193, October 2005. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
E. Lear, "Address Allocation for Private Internets",BCP 5, Addresses", RFC 4193, October 2005.
RFC 1918, February 1996.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 10.2. Informative References
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, [I-D.baker-v6ops-b2b-private-routing]
"Problem Statement for Default Address Selection in Multi- Baker, F., "Business to Business Private Routing", draft-
Prefix Environments: Operational Issues of RFC 3484 Default baker-v6ops-b2b-private-routing-00 (work in progress),
Rules", RFC 5220, July 2008. July 2007.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, [I-D.ietf-v6ops-dhcpv6-slaac-problem]
"Understanding Apple's Back to My Mac (BTMM) Service", RFC Liu, B., Bonica, R., Gong, X., and W. Wang, "DHCPv6/SLAAC
6281, June 2011. Address Configuration Interaction Problem Statement",
draft-ietf-v6ops-dhcpv6-slaac-problem-01 (work in
progress), June 2014.
[RFC6296] Wasserman, M., and F. Baker, "IPv6-to-IPv6 Network Prefix [I-D.jhlee-mext-mnpp]
Translation", RFC 6296, June 2011. Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix
Provisioning", draft-jhlee-mext-mnpp-00 (work in
progress), October 2009.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [I-D.petrescu-autoconf-ra-based-routing]
Dual-Stack Hosts", RFC 6555, April 2012. Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali,
"Router Advertisements for Routing between Moving
Networks", draft-petrescu-autoconf-ra-based-routing-04
(work in progress), October 2013.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [MIL-STD-1397]
"Default Address Selection for Internet Protocol Version 6 "Military Standard, Input/Output Interfaces, Standard
(IPv6)", RFC 6724, Digital Data, Navy Systems (MIL-STD-1397B), 3 March 1989",
.
[I-D.ietf-v6ops-nat64-experience] [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
Chen G., Cao Z., Xie C., and D. Binet, "NAT64 Operational E. Lear, "Address Allocation for Private Internets", BCP
Experiences", Working in Progress, October, 2013 5, RFC 1918, February 1996.
[I-D.baker-v6ops-b2b-private-routing] [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
F. Baker, "Business to Business Private Routing", Expired November 2000.
[I-D.petrescu-autoconf-ra-based-routing] [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
Petrescu, A., Janneteau, C., Demailly, N. and S. Imadali, with the IP Network Address Translator", RFC 3027, January
"Router Advertisements for Routing between Moving Networks", 2001.
Working in Progress, October, 2013
[I-D.jhlee-mext-mnpp] [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Lee, J.-H., and T. Ernst, "Mobile Network Prefix Addresses", RFC 3879, September 2004.
Provisioning", Expired
[RS-485] http://en.wikipedia.org/wiki/RS-485 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[MIL-STD-1397] [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
http://en.wikipedia.org/wiki/MIL-STD-1397 Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[SCADA] http://en.wikipedia.org/wiki/SCADA [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[ULA-IN-WILD] [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
G. Michaelson, "www.ietf.org/proceedings/87/slides/slides- "Problem Statement for Default Address Selection in Multi-
87-v6ops-0.pdf" Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008.
10. Acknowledgments [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
IPv6 Network Address Translation", RFC 5902, July 2010.
Many valuable comments were received in the IETF v6ops WG mail list, [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
especially from Fred Baker, Brian Carpenter, Lee Howard, Victor Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Jong-Hyouk Lee, October 2010.
Doug Barton, Owen Delong, Anders Brandt, Tim Chown, Jen Linkova,
Christopher Palmer and Wesley George.
Some test of using ULA in the lab was done by our research partner [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
BNRC-BUPT (Broad Network Research Centre in Beijing University of NAT64: Network Address and Protocol Translation from IPv6
Posts and Telecommunications). Thanks for the work of Prof. Xiangyang Clients to IPv4 Servers", RFC 6146, April 2011.
Gong and student Dengjia Xu.
This document was prepared using 2-Word-v2.0.template.dot. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
Authors' Addresses [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", RFC
6281, June 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269, June 2014.
[RS-485] "Electronic Industries Association (1983). Electrical
Characteristics of Generators and Receivers for Use in
Balanced Multipoint Systems. EIA Standard RS-485.", .
[SCADA] "Boyer, Stuart A. (2010). SCADA Supervisory Control and
Data Acquisition. USA: ISA - International Society of
Automation.", .
[ULA-IN-WILD]
"G. Michaelson, "conference.apnic.net/data/36/apnic-
36-ula_1377495768.pdf"", .
Authors' Addresses
Bing Liu Bing Liu
Huawei Technologies Co., Ltd Huawei Technologies
Huawei Q14 Building, No.156 Beiqing Rd., Q14, Huawei Campus, No.156 Beiqing Road
Zhong-Guan-Cun Environmental Protection Park, Beijing Hai-Dian District, Beijing, 100095
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
Huawei Q14 Building, No.156 Beiqing Rd., Q14, Huawei Campus, No.156 Beiqing Road
Zhong-Guan-Cun Environmental Protection Park, Beijing Hai-Dian District, Beijing, 100095
P.R. China P.R. China
EMail: jiangsheng@huawei.com Email: jiangsheng@huawei.com
 End of changes. 140 change blocks. 
401 lines changed or deleted 492 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/