draft-ietf-v6ops-ula-usage-recommendations-03.txt   draft-ietf-v6ops-ula-usage-recommendations-04.txt 
Internet Engineering Task Force B. Liu Internet Engineering Task Force B. Liu
Internet-Draft S. Jiang Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: January 5, 2015 July 4, 2014 Expires: April 30, 2015 October 27, 2014
Considerations of Using Unique Local Addresses Considerations For Using Unique Local Addresses
draft-ietf-v6ops-ula-usage-recommendations-03 draft-ietf-v6ops-ula-usage-recommendations-04
Abstract Abstract
This document provides considerations of how to use ULAs. It This document provides considerations for using IPv6 Unique Local
analyzes ULA usage scenarios and considers some use cases of ULA Addresses (ULAs). It identifies cases where ULA addresses are
addresses as helpful. helpful as well as potential problems that their use could introduce,
based on an analysis of different ULA usage scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 30, 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 publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Analysis of ULA Features . . . . . . . . . . . . . . . . . . 3 3. Analysis of ULA Features . . . . . . . . . . . . . . . . . . 3
3.1. Automatically Generated . . . . . . . . . . . . . . . . . 3 3.1. Automatically Generated . . . . . . . . . . . . . . . . . 3
3.2. Globally Unique . . . . . . . . . . . . . . . . . . . . . 3 3.2. Globally Unique . . . . . . . . . . . . . . . . . . . . . 3
3.3. Independent Address Space . . . . . . . . . . . . . . . . 3 3.3. Independent Address Space . . . . . . . . . . . . . . . . 3
3.4. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 3.4. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4
3.5. Stable or Temporary Prefix . . . . . . . . . . . . . . . 4 3.5. Stable or Temporary Prefix . . . . . . . . . . . . . . . 4
4. Enumeration of Scenarios Using ULAs . . . . . . . . . . . . . 4 4. Analysis and Operational Considerations of Scenarios Using
ULAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Isolated Networks . . . . . . . . . . . . . . . . . . . . 4 4.1. Isolated Networks . . . . . . . . . . . . . . . . . . . . 4
4.2. Connected Network . . . . . . . . . . . . . . . . . . . . 6 4.2. Connected Networks . . . . . . . . . . . . . . . . . . . 5
4.2.1. ULA-Only Deployment . . . . . . . . . . . . . . . . . 6 4.2.1. ULA-Only Deployment . . . . . . . . . . . . . . . . . 5
4.2.2. ULAs along with PA Addresses . . . . . . . . . . . . 7 4.2.2. ULAs along with PA Addresses . . . . . . . . . . . . 7
4.3. IPv4 Co-existence Considerations . . . . . . . . . . . . 9 4.3. IPv4 Co-existence Considerations . . . . . . . . . . . . 9
5. General Guidelines of Using ULA . . . . . . . . . . . . . . . 10 5. General Considerations For Using ULAs . . . . . . . . . . . . 10
5.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 10 5.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 10
5.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 10 5.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 10
6. ULA Usages Considered Helpful . . . . . . . . . . . . . . . . 11 6. ULA Usages Considered Helpful . . . . . . . . . . . . . . . . 10
6.1. Used in Isolated Networks . . . . . . . . . . . . . . . . 11 6.1. Used in Isolated Networks . . . . . . . . . . . . . . . . 11
6.2. ULA along with PA . . . . . . . . . . . . . . . . . . . . 11 6.2. ULA along with PA . . . . . . . . . . . . . . . . . . . . 11
6.3. Some Specific Use Cases . . . . . . . . . . . . . . . . . 11 6.3. Some Specific Use Cases . . . . . . . . . . . . . . . . . 11
6.3.1. Special Routing . . . . . . . . . . . . . . . . . . . 11 6.3.1. Special Routing . . . . . . . . . . . . . . . . . . . 11
6.3.2. Used as NAT64 Prefix . . . . . . . . . . . . . . . . 11 6.3.2. Used as NAT64 Prefix . . . . . . . . . . . . . . . . 11
6.3.3. Used as Identifier . . . . . . . . . . . . . . . . . 12 6.3.3. Used as Identifier . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 locally, for example, on
networks, and VPNs .etc. Although ULAs may be treated like global isolated networks, internal networks, or VPNs. Although ULAs may be
scope by applications, normally they should not be used on the treated like addresses of global scope by applications, normally they
publicly Internet. Since site-local addresses are deprecated in are not used on the public Internet. ULAs are a possible alternative
[RFC3879], ULAs could be alternatives of site-local addresses in some to site-local addresses (deprecated in [RFC3879]) in some situations,
situations (but they are not equal). but there are differences between the two address types.
However, the use of ULAs in various types of networks has been The use of ULAs in various types of networks has been confusing to
confusing to network operators. This document aims to clarify the network operators. This document aims to clarify the advantages and
advantages and disadvantages of ULAs and how they can be most disadvantages of ULAs and how they can be most appropriately used.
appropriately used.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in [RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key English meanings, and are not to be interpreted as [RFC2119] key
words. words.
3. Analysis of ULA Features 3. Analysis of ULA Features
3.1. Automatically Generated 3.1. Automatically Generated
ULA prefixes could be automatically generated according to the ULA prefixes can be automatically generated using the algorithms
algorithms described in [RFC4193]. This feature allows automatic described in [RFC4193]. This feature allows automatic prefix
prefixes allocation, thus one can get a network work immediately allocation. Thus one can get a network working immediately without
without applying prefix (es) from an RIR/LIR (Regional Internet applying for prefix(es) from an RIR/LIR (Regional Internet Registry/
Registry/Local Internet Registry). Local Internet Registry).
3.2. Globally Unique 3.2. Globally Unique
ULAs are 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 ULAs may occasionally be merged into Since multiple networks in which the hosts have been assigned with
one network, this uniqueness is necessary. The randomization of 40 ULAs may occasionally be merged into one network, this uniqueness is
bits in a ULA prefix is considered sufficient enough to ensure a high necessary. The randomization of 40 bits in a ULA prefix is
degree of uniqueness (refer to [RFC4193] Section 3.2.3 for details) considered sufficient enough to ensure a high degree of uniqueness
and makes merging of networks simple and without the need to renumber (refer to [RFC4193] Section 3.2.3 for details) and simplifies merging
overlapping IP address space. Overlapping is cited as a deficiency of networks by avoiding the need to renumber overlapping IP address
with how [RFC1918] addresses were deployed, and ULA was designed to space. Such overlapping was a major drawback to the deployment of
overcome this deficiency. private [RFC1918] addresses in IPv4.
Note that as described in [RFC4864], in practice, applications may Note that, as described in [RFC4864], applications may treat ULAs in
treat ULAs like global-scope addresses, but address selection practice 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 Global-scope
(Global-scope Unicast Address) to ensure bidirectional Unicast Addresses (GUAs) to ensure bidirectional communications. As
communications. (Note: the new address selection standard has a further note, the default address selection policy table in
supported this in the default policy table. [RFC6724]) [RFC6724]) responds to this requirement.
3.3. Independent Address Space 3.3. Independent Address Space
ULAs provide internal address independence in IPv6 that they can be ULAs provide internal address independence in IPv6 since they can be
used for internal communications without having any permanent or only used for internal communications even without Internet connectivity.
intermittent Internet connectivity. And it needs no registration so They need no registration, so they can support on-demand usage and do
that it can support on-demand usage and does not carry any RIR/LIR not carry any RIR/LIR burden of documentation or fees.
documentation/fees burden or disclosures.
3.4. Well Known Prefix 3.4. Well Known Prefix
The prefixes of ULAs are well known thus they are easy to be The prefixes of ULAs are well known thus they are easily identified
identified and filtered. and filtered.
This feature is convenient for 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, network administrators can segregate
parameters have to be assembled or transmitted globally, by a packets containing data which must stay in the internal network by
separate function, through an appropriate gateway/firewall, to the assigning ULAs to internal servers. Externally-destined data can be
Internet or to the telecom network. sent to the Internet or telecommunication network by a separate
function, through an appropriate gateway/firewall.
3.5. Stable or Temporary Prefix 3.5. Stable or Temporary Prefix
A ULA prefix can be generated once, at installation time or factory A ULA prefix can be generated once, at installation time or factory
reset, and then probably never be changed. Alternatively, it could reset, and then possibly never be changed. Alternatively, it can be
be regenerated regularly, if desired for some reason. regenerated regularly, depending on deployment requirements.
4. Enumeration of Scenarios Using ULAs 4. Analysis and Operational Considerations of Scenarios Using ULAs
4.1. Isolated Networks 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 (e.g. [RS-485], [SCADA], or even non-networked digital interfaces
like [MIL-STD-1397] began to use IP protocol. In such kind of like [MIL-STD-1397] have begun to use IP. In these kinds of
networks, the system might lack the ability/requirement of connecting networks, the system may lack the ability to communicate with the
to the Internet or explicitly designed not to connect. public networks.
Besides, there might be some networks which could connect to the As another example, there may be some networks in which the equipment
Internet, but prohibited by administration or just temporally not has the technical capability to connect to the Internet, but is
connected. These networks may include machine-to-machine (e.g. prohibited by administration or just temporarily not connected.
vehicle networks), sensor networks, or even normal LANs, which may These networks may include separate financial networks, lab networks.
include very large numbers of addresses. machine-to-machine (e.g. vehicle networks), sensor networks, or even
normal LANs, and can include very large numbers of addresses.
Since the serious disadvantages and impact on applications by Serious disadvantages and impact on applications due to the use of
ambiguous address space have been well documented in [RFC1918], ULA ambiguous address space have been well documented in [RFC1918].
is a straightforward way to assign the IP addresses in these kinds of However, ULA is a straightforward way to assign the IP addresses in
networks with minimal administrative cost or burden. Also, ULAs fit the kinds of networks just described, with minimal administrative
in multiple subnet scenarios, in which each subnet has its own ULA cost or burden. Also, ULAs fit in multiple subnet scenarios, in
prefix. For example, when we assign vehicles with ULA addresses, it which each subnet has its own ULA prefix. For example, when we
is then possible to separate in-vehicle embedded networks into assign vehicles with ULA addresses, it is then possible to separate
different subnets depending on real-time requirements, devices types, in-vehicle embedded networks into different subnets depending on
services and more. real-time requirements, device types, services and more.
However, each isolated network has the possibility to be connected in However, each isolated network has the possibility to be connected in
the future. The administrators need to consider following things: the future. Administrators need to consider the following before
deciding whether to use ULAs:
o If it connects to another isolated/private network, then comes the
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 o If the network eventually connects to another isolated or private
merge network, the potential for address collision arises. However, if
the ULAs were generated in the standard way, this will not be a
big problem.
Drawbacks: o If the network eventually connects to the global Internet, then
the operator will need to add a new global prefix and ensure that
the address selection policy is properly set up on all interfaces.
o The uniqueness of the global ULA prefix is not guaranteed, If these further considerations are unacceptable for some reason,
however, the probability of collision is extremely low. then the administrator needs to be careful about using ULAs in
currently isolated networks.
Operational considerations: Operational considerations:
o Prefix generation: Randomly generated according to the algorithms o Prefix generation: Randomly generated according to the algorithms
defined in [RFC4193] or literally assigned by human. Normally, it defined in [RFC4193] or manually assigned. Normally, automatic
is recommended to following the standard way to automatically generation of the prefixes is recommended, following [RFC4193].
generate the prefixes; if there are some specific reasons that If there are some specific reasons that call for manual
need to be assigned by human, the administrators must carefully assignment, administrators have to plan the prefixes carefully to
plan the prefixes to avoid collision. avoid collision.
o Prefix announcement: In some cases, the networks might need to o Prefix announcement: In some cases, networks may need to announce
announce prefixes to each other, for example in vehicle networks prefixes to each other. For example, in vehicle networks with
with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) infrastructure-less settings such as Vehicle-to-Vehicle (V2V)
settings, prior knowledge of respective prefixes is unlikely. communication, prior knowledge of the respective prefixes is
Hence, a prefix announcement mechanism is needed to enable inter- unlikely. Hence, a prefix announcement mechanism is needed to
vehicles communications based on IP. For instance, such enable inter-vehicle communications based on IP. As one
announcement could rely on an extension of the Router possibility, such announcements could rely on extensions to the
Advertisement message of Neighbor Discovery Protocol (e.g. Router Advertisement message of the Neighbor Discovery Protocol
[I-D.petrescu-autoconf-ra-based-routing] and (e.g., [I-D.petrescu-autoconf-ra-based-routing] and
[I-D.jhlee-mext-mnpp]). [I-D.jhlee-mext-mnpp]).
4.2. Connected Network 4.2. Connected Networks
4.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 and interior interfaces are assigned ULAs
the networks need to communicate with the outside. It mainly and not GUAs, but the network needs to communicate with the outside.
includes the following two models. Two models can be considered:
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 specification that provides a stateless one-to-one mapping
between internal addresses and external addresses. The between internal addresses and external addresses. The
specification considers translating ULA prefixes into GUA specification considers translating ULA prefixes into GUA
prefixes as a use case. Although NPTv6 works differently to prefixes as an use case. Although NPTv6 works differently from
traditional stateful NAT/NAPT (which is discouraged in traditional stateful NAT/NAPT (which is discouraged in
[RFC5902]), it also introduces some similar additional [RFC5902]), it introduces similar additional complexity to
complexity to applications, which might cause applications to applications, which may cause applications to break.
break.
Thus this document does not recommend the use of ULA+NPTv6. Thus this document does not recommend the use of ULA+NPTv6.
Rather, this document considers ULA+PA (Provider Aggregated) as Rather, this document considers ULA+PA (Provider Aggregated) as
a better approach to connect to the global network when ULAs a better approach to connect to the global network when ULAs
are expected to be retained. The use of ULA+PA is discussed in are expected to be retained. The use of ULA+PA is discussed in
detail in Section 4.2.2 below. detail in Section 4.2.2 below.
o Using Application-Layer Proxies o Using Application-Layer Proxies
The proxies terminate the network-layer connectivity of the The proxies terminate the network-layer connectivity of the
hosts and delegate the outgoing/incoming connections. hosts and associate separate internal and external connections.
In some environments (e.g. Information security sensitive In some environments (e.g., information security sensitive
enterprise or government), the endpoints are default enterprise or government), central control is exercised by
disconnected to the Internet, and need the proxies to connect allowing the endpoints to connect to the Internet only through
for central control. In IPv4, using private address space with a proxy. With IPv4, using private address space with proxies
proxies is an effective and common practice for this purpose, is an effective and common practice for this purpose, and it is
and it is natural to pick ULA in IPv6. natural to pick ULA as its counterpart in IPv6.
Benefits of using ULAs in this scenario: Benefits of using ULAs in this scenario:
o Allowing minimal management burden on address assignment for some o Allowing minimal management burden on address assignment for some
specific environments. specific environments.
Drawbacks: Drawbacks:
o The serious disadvantages and impact on applications by NAT have o The serious disadvantages and impact on applications imposed by
been well documented in [RFC2993] and [RFC3027]. Although NPTv6 NATs have been well documented in [RFC2993] and [RFC3027].
is a mechanism that has fewer architectural problems than merely Although NPTv6 is a mechanism that has fewer architectural
implementing a traditional stateful Network Address Translator in problems than a traditional stateful Network Address Translator in
an IPv6 environment [RFC6296], it still beaks the end-to-end an IPv6 environment [RFC6296], it still breaks end-to-end
transparency which is in general not recommended by the IETF. transparency and hence in general is not recommended by the IETF.
Operational considerations: Operational considerations:
o Firewall deployment: as described in [RFC6296], firewall is o Firewall deployment: [RFC6296] points out that an NPTv6 translator
recommended to be implemented with NPTv6 translator. Then the does not have the same security properties as a traditional NAT44,
administrators need to know about where the firewall is located. and hence needs be supplemented with a firewall if security at the
boundary is an issue. The operator has to decide where to locate
the firewall.
- If the firewall is located outside the NPTv6 translator, then - If the firewall is located outside the NPTv6 translator, then
the filtering is based on the translated GUA prefixes, and when filtering is based on the translated GUA prefixes, and when the
the internal ULA prefixes are renumbered, the filtering rules internal ULA prefixes are renumbered, the filtering rules do
don't need to be changed (however, when GUA prefixes of the not need to be changed. However, when the GUA prefixes of the
NPTv6 are renumbered, the filtering rules need to be updated NPTv6 are renumbered, the filtering rules need to be updated
accordingly.). accordingly.).
- If the firewall is located inside the NPTv6 translator, the - If the firewall is located inside the NPTv6 translator, the
filtering is then based on the ULA prefixes, and the rules need filtering is then based on the ULA prefixes, and the rules need
to be updated according to the ULA prefixes renumbering (but to be updated correspondingly. There is no need to update when
don't need to update when NPTv6 GUA prefixes are renumbered.). the NPTv6 GUA prefixes are renumbered.
4.2.2. ULAs along with PA Addresses 4.2.2. ULAs along with PA Addresses
There are two classes of network probably to use ULA with PA Two classes of network might need to use ULA with PA (Provider
(Provider Aggregated) addresses: Aggregated) addresses:
o Home network. Home networks are normally assigned with one or o Home network. Home networks are normally assigned with one or
more globally routed PA prefixes to connect to the uplink of some more globally routed PA prefixes to connect to the uplink of an
an ISP. And besides, they may need internal routed networking ISP. In addition, they may need internal routed networking even
even when the ISP link is down. Then ULA is a proper tool to fit when the ISP link is down. Then ULA is a proper tool to fit the
the requirement. And in [RFC6204], it requires the CPE to support requirement. [RFC7084] requires the CPE to support ULA. Note:
ULA. Note, ULAs provide more benefit for multiple-segment home ULAs provide more benefit for multiple-segment home networks; for
networks; for home networks only containing one segment, link- home networks containing only one segment, link-local addresses
local addresses are better alternatives. are better alternatives.
o 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 can be used to improve
connectivity redundancy and better internal connectivity or internal connectivity and make it more resilient, or to isolate
isolation of certain functions like OAM of servers. certain functions like OAM for servers.
Benefits of Using ULAs in this scenario: Benefits of Using ULAs in this scenario:
o Separated local communication plane: for either home networks or o Separated local communication plane: for either home networks or
enterprise networks, the main purpose of using ULAs along with PA enterprise networks, the main purpose of using ULAs along with PA
addresses is to provide a logically local routing plane separated addresses is to provide a logically local routing plane separated
from the globally routing plane. The benefit is to ensure stable from the global routing plane. The benefit is to ensure stable
and specific local communication regardless of the ISP uplink and specific local communication regardless of the ISP uplink
failure. This benefit is especially meaningful for the home failure. This benefit is especially meaningful for the home
network or private OAM function in an enterprise. network or for private OAM function in an enterprise.
o Renumbering: in some special cases such as renumbering, enterprise o Renumbering: in some special cases such as renumbering, enterprise
administrators may want to avoid the need to renumber their administrators may want to avoid the need to renumber their
internal-only, private nodes when they have to renumber the PA internal-only, private nodes when they have to renumber the PA
addresses of the whole network because of changing ISPs, ISPs addresses of the rest of the network because they are changing
restructure their address allocations, or whatever reasons. In ISPs, because the ISP has restructured its address allocations, or
these situations, ULA is an effective tool for the internal-only for some other reason. In these situations, ULA is an effective
nodes. Besides the internal-only nodes, the public nodes can also tool for addressing internal-only nodes. Even public nodes can
benefit from ULA for renumbering. When renumbering, as [RFC4192] benefit from ULA for renumbering, on their internal interfaces.
suggested, it has a period to keep using the old prefix(es) before When renumbering, as [RFC4192] suggests, old prefixes continue to
the new prefix(es) is(are) stable. In the process of adding new be valid until the new prefix(es) is(are) stable. In the process
prefix(es) and deprecating old prefix(es), it is not easy to keep of adding new prefix(es) and deprecating old prefix(es), it is not
the local communication immune of global routing plane change. If easy to keep local communication disentangled from global routing
we use ULAs for the local communication, the separated local plane change. If we use ULAs for local communication, the
routing plane can isolate the affecting by global routing change. separated local routing plane can isolate the effects of global
routing change.
Drawbacks: Drawbacks:
o Operational Complexity: there are some arguments that in practice o Operational Complexity: there are some arguments that in practice
the ULA+PA makes additional operational complexity. It is not a the use of ULA+PA creates additional operational complexity. This
ULA-specific problem; the multiple-addresses-per-interface is an is not a ULA-specific problem; the multiple-addresses-per-
important feature of IPv6 protocol. Never the less, running interface is an important feature of IPv6 protocol. Nevertheless,
multiple prefixes needs more operational considerations than running multiple prefixes needs more operational consideration
running a single one. than running a single one.
Operational considerations: Operational considerations:
o Default Routing: connectivity might be broken if ULAs are used as o Default Routing: connectivity may be broken if ULAs are used as
default route. When using RIO (Route Information Option) in default route. When using RIO (Route Information Option) in
[RFC4191], specific routs would be added without a default route, [RFC4191], specific routes can be added without a default route,
thus bad user experience of timeouts on ICMPv6 redirects are thus avoiding bad user experience due to timeouts on ICMPv6
avoided. This behavior was well documented in [RFC7084] as rule redirects. This behavior was well documented in [RFC7084] as rule
ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all of router with a Router Lifetime greater than zero whenever all of
its configured and delegated prefixes are ULA prefixes." and along its configured and delegated prefixes are ULA prefixes." and along
with rule L-3 "An IPv6 CE router MUST advertise itself as a router 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 for the delegated prefix(es) (and ULA prefix if configured to
provide ULA addressing) using the "Route Information Option" provide ULA addressing) using the "Route Information Option"
specified in Section 2.3 of [RFC4191]. This advertisement is specified in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the WAN independent of having or not having IPv6 connectivity on the WAN
interface.". However, it should be noticed that current OSes interface.". However, it needs to be noticed that current OSes
don't all support [RFC4191]. don't all support [RFC4191].
o SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be enabled o SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be enabled
in one network simultaneously; the administrators need to in one network simultaneously; the administrators need to
carefully plan how to assign ULA and PA prefixes in accordance carefully plan how to assign ULA and PA 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.ietf-v6ops-dhcpv6-slaac-problem] for details). [I-D.ietf-v6ops-dhcpv6-slaac-problem] for details).
o 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.
[RFC6724], it claimed that a site-specific policy entry can be [RFC6724] claims that a site-specific policy entry can be used to
used to cause ULAs within a site to be preferred over global cause ULAs within a site to be preferred over global addresses.
addresses.
o DNS relevant: if administrators chose not to do reverse DNS o DNS relevant: if administrators choose 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 may
leak to the outside world. Because reverse queries will be made leak to the outside world. Because reverse queries will be made
and naturally routed to the global reverse tree, so people will be and naturally routed to the global reverse tree, so external
exposed to the existence of population the ULA uses, not in parties will be exposed to the existence of a population of ULA
traffic terms, but in knowledge terms. [ULA-IN-WILD] provides addresses. [ULA-IN-WILD] provides more detailed situations on
more detailed situations on this issue. Administrators may need a this issue. Administrators may need a split DNS to separate the
split DNS to separate the queries from internal and external for queries from internal and external for ULA entries and GUA
ULA entries and GUA entries. entries.
4.3. IPv4 Co-existence Considerations 4.3. IPv4 Co-existence Considerations
Generally, this document does not consider IPv4 relevant as in the Generally, this document does not consider IPv4 to be in scope. But
scope But regarding ULA, there is a special case needs to be noticed, regarding ULA, there is a special case needs to be recognized, which
which is described in Section 3.2.2 of [RFC5220]. When an enterprise is described in Section 3.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, 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 policy table defined in the old address selection standard
connection failure. [RFC3484]. This will clearly result in a connection failure. The
new address selection standard [RFC6724] has corrected this behavior
by preferring IPv4 than ULAs in the default policy table. However,
there are still lots of hosts using the old standard [RFC3484], thus
this could be an issue in real networks.
Although with Happy Eyeballs [RFC6555] this connection failure Happy Eyeballs [RFC6555] solves this connection failure problem, but
problem could be solved, but unwanted timeouts would obviously lower unwanted timeouts will obviously lower the user experience. One
the user experience. One possible approach of eliminating the possible approach to eliminating the timeouts is to deprecate the
timeouts is deprecating IPv6 default route and simply configuring a IPv6 default route and simply configure a scoped route on hosts (in
scoped route on hosts (in the context of this document, only the context of this document, only configure the ULA prefix routes).
configure the ULA prefix routes). Another alternative is configuring Another alternative is to configure IPv4 preference on the hosts, and
IPv4 preference on the hosts, and not including DNS A records but not include DNS A records but only AAAA records for the internal
only AAAA records for the internal nodes in the internal DNS server, nodes in the internal DNS server. Then outside nodes have both A and
then outside nodes have both A and AAAA records could be connected AAAA records and can be connected through IPv4 as default and
through IPv4 as default and internal nodes could be always connected internal nodes can always connect through IPv6. But since IPv6
through IPv6. But since IPv6 preference is default, changing the preference is default, changing the default in all nodes is not
default in all nodes is not suitable at scale. suitable at scale.
5. General Guidelines of Using ULA 5. General Considerations For Using ULAs
5.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 3.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 this does not mean that ULA is equal to an IPv6 version of
deployment. [RFC1918] usually combines with NAT/NAPT for global [RFC1918] deployment. [RFC1918] usually combines with NAT/NAPT for
connectivity. But it is not necessarily to combine ULAs with any global connectivity. But it is not necessary to combine ULAs with
kind of NAT. People could use ULA for local communications along any kind of NAT. Operators can use ULA for local communications
with global addresses for global communications (see Section 6.2). along with global addresses for global communications (see
This is a big advantage brought by default support of multiple- Section 4.2.2). This is a big advantage brought by default support
addresses-per-interface feature in IPv6. (People might still have of multiple-addresses-per-interface feature in IPv6. (People may
requirement of ULA with NAT, this is discussed in Section 4.2.1. But still have a requirement for NAT with ULA, this is discussed in
people also should keep in mind that ULA is not intentionally Section 4.2.1. But people also need to keep in mind that ULA is not
designed for this kind of use case.) intentionally 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].
5.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 need to 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 is
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 might need to split the DNS so that the internal
server includes records that are not presented in the external DNS DNS server includes records that are not presented in the external
server. DNS server.
6. ULA Usages Considered Helpful 6. ULA Usages Considered Helpful
6.1. Used in Isolated Networks 6.1. Used in Isolated Networks
As analyzed in Section 4.1, ULA is very suitable for isolated As analyzed in Section 4.1, ULA is very suitable for isolated
networks. Especially when there are subnets in the isolated network, networks. Especially when there are subnets in the isolated network,
ULA is a reasonable choice. ULA is a reasonable choice.
6.2. ULA along with PA 6.2. ULA along with PA
As the benefits described in Section 4.2.2, using ULAs along with PA As described in Section 4.2.2, using ULAs along with PA addresses to
addresses to provide a logically separated local plane could benefit provide a logically separated local plane can benefit OAM functions
to OAM functions and renumbering. and renumbering.
6.3. Some 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.
6.3.1. Special Routing 6.3.1. Special Routing
For various reasons the administrators might want to have private For various reasons the administrators may want to have private
routing be controlled and separated from other routing. For example, routing be controlled and separated from other routing. For example,
in the b2b case described in [I-D.baker-v6ops-b2b-private-routing], in the business-to-business case described in
two companies might want to use direct connectivity that only [I-D.baker-v6ops-b2b-private-routing], two companies might want to
connects stated machines, such as a silicon foundry with client use direct connectivity that only connects stated machines, such as a
engineers that use it. A ULA provides a simple way to assign such silicon foundry with client engineers that use it. A ULA provides a
prefixes that would be used in accordance with an agreement between simple way to assign prefixes that would be used in accordance with
the parties. an agreement between the parties.
6.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 The NAT64 PREF64 is just a group of local fake addresses for the
the DNS64 to point traffic to a NAT64, When using a ULA prefix as the DNS64 to point traffic to a NAT64. Using a ULA prefix as the PREF64
pref64, it could easily ensures that only local systems can use the easily ensures that only local systems can use the translation
translation resources of the NAT64 system since the ULA is not resources of the NAT64 system since the ULA is not intended to be
intended to be globally routable and helps clearly identify traffic globally routable. The ULA helps clearly identify traffic that is
that is locally contained and destine to a NAT64. Using ULA for locally contained and destined to a NAT64. Using ULA for PREF64 is
Pref64 is deployed and it is an operational model. deployed and it is an operational model.
But there's an issue should be noticed. The NAT64 standard [RFC6146] But there is an issue needs to be noted. The NAT64 standard
mentioned the pref64 should align with [RFC6052], in which the [RFC6146] specifies that the PREF64 should align with [RFC6052], in
IPv4-Embedded IPv6 Address format was specified. If we pick a /48 which the IPv4-Embedded IPv6 Address format was specified. If we
for NAT64, it happened to be a standard 48/ part of ULA (7bit ULA pick a /48 for NAT64, it happens to be a standard 48/ part of ULA
famous prefix+ 1 "L" bit + 40bit Global ID). Then the 40bit of ULA (7bit ULA well-known prefix+ 1 "L" bit + 40bit Global ID). Then the
is not violated to be filled with part of the 32bit IPv4 address. 40bit of ULA is not violated by being filled with part of the 32bit
This is important, because the 40bit assures the uniqueness of ULA, IPv4 address. This is important, because the 40bit assures the
if the prefix is shorter than /48, the 40bit would be violated, and uniqueness of ULA. If the prefix is shorter than /48, the 40bit
this may cause conformance issue. But it is considered that the most would be violated, and this could cause conformance issues. But it
common use case will be a /96 PREF64, or even /64 will be used. So is considered that the most common use case will be a /96 PREF64, or
it seems this issue is not common in current practice. even /64 will be used. So it seems this issue is not common in
current practice.
It is most common that ULA Pref64 will be deployed on a single 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 internal network. ULA will not be effective as PREF64 when the
access network must use an Internet transit to receive the access network must use an Internet transit to receive the
translation service of a NAT64 since the ULA will not route across translation service of a NAT64 since the ULA will not route across
the Internet. 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
[RFC7269]. So administrators need to add additional site-specific [RFC7269]. So administrators need to add additional site-specific
address selection rules to the default table to steer traffic flows address selection rules to the default table to steer traffic flows
going through NAT64-CGN. However, updating the default policy tables going through NAT64-CGN. However, updating the default policy tables
skipping to change at page 12, line 46 skipping to change at page 12, line 45
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 needs to be noticed again that in theory ULA has the possibility
collision. However, the probability is desirable small enough and of collision. However, the probability is desirably small enough and
could be ignored by most of the cases when used as identifiers. can be ignored in most cases when ULAs are used as identifiers.
7. 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]. Also refer to [RFC4864], which the ULA specification [RFC4193]. Also refer to [RFC4864], which
shows how ULAs help with local network protection. shows how ULAs help with local network protection.
As mentioned in Section 5.2.1, when use NPTv6, the administrators As mentioned in Section 4.2.2, when using NPTv6, the administrators
need to know about where the firewall is located to set proper need to know where the firewall is located to set proper filtering
filtering rules. rules.
As mentioned in Section 5.2.2, if administrators chose not to do Also as mentioned in Section 4.2.2, if administrators choose not to
reverse DNS delegation inside their local control of ULA prefixes, a do reverse DNS delegation inside their local control of ULA prefixes,
significant amount of information about the ULA population might leak a significant amount of information about the ULA population may leak
to the outside world. to the outside world.
8. IANA Considerations 8. IANA Considerations
IANA considerations should be updated to point to [RFC4193] in a This memo has no actions for IANA.
similar manner to section 5.
9. Acknowledgements 9. Acknowledgements
Many valuable comments were received in the IETF v6ops WG mail list, Many valuable comments were received in the IETF v6ops WG mail list,
especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee
Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim
Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews, Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews,
Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton, Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton,
Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler, Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler,
Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali
and Wesley George. and Wesley George.
Some test of using ULA in the lab was done by our research partner Some test of using ULA in the lab was done by our research partner
BNRC-BUPT (Broad Network Research Centre in Beijing University of BNRC-BUPT (Broad Network Research Centre in Beijing University of
Posts and Telecommunications). Thanks for the work of Prof. Posts and Telecommunications). Thanks for the work of Prof.
Xiangyang Gong and student Dengjia Xu. Xiangyang Gong and student Dengjia Xu.
Tom Taylor did a language review and revision throught the whole
document. The authors appreciate a lot for his help.
This document was produced using the xml2rfc tool [RFC2629] This document was produced using the xml2rfc tool [RFC2629]
(initially prepared using 2-Word-v2.0.template.dot.). (initially prepared using 2-Word-v2.0.template.dot.).
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 14, line 16 skipping to change at page 14, line 19
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
10.2. Informative References 10.2. Informative References
[I-D.baker-v6ops-b2b-private-routing] [I-D.baker-v6ops-b2b-private-routing]
Baker, F., "Business to Business Private Routing", draft- Baker, F., "Business to Business Private Routing", draft-
baker-v6ops-b2b-private-routing-00 (work in progress), baker-v6ops-b2b-private-routing-00 (work in progress),
July 2007. July 2007.
[I-D.ietf-v6ops-dhcpv6-slaac-problem] [I-D.ietf-v6ops-dhcpv6-slaac-problem]
Liu, B., Bonica, R., Gong, X., and W. Wang, "DHCPv6/SLAAC Liu, B., Jiang, S., Bonica, R., Gong, X., and W. Wang,
Address Configuration Interaction Problem Statement", "DHCPv6/SLAAC Address Configuration Interaction Problem
draft-ietf-v6ops-dhcpv6-slaac-problem-01 (work in Statement", draft-ietf-v6ops-dhcpv6-slaac-problem-02 (work
progress), June 2014. in progress), October 2014.
[I-D.jhlee-mext-mnpp] [I-D.jhlee-mext-mnpp]
Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix
Provisioning", draft-jhlee-mext-mnpp-00 (work in Provisioning", draft-jhlee-mext-mnpp-00 (work in
progress), October 2009. progress), October 2009.
[I-D.petrescu-autoconf-ra-based-routing] [I-D.petrescu-autoconf-ra-based-routing]
Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali, Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali,
"Router Advertisements for Routing between Moving "Router Advertisements for Routing between Moving
Networks", draft-petrescu-autoconf-ra-based-routing-04 Networks", draft-petrescu-autoconf-ra-based-routing-05
(work in progress), October 2013. (work in progress), July 2014.
[MIL-STD-1397] [MIL-STD-1397]
"Military Standard, Input/Output Interfaces, Standard "Military Standard, Input/Output Interfaces, Standard
Digital Data, Navy Systems (MIL-STD-1397B), 3 March 1989", Digital Data, Navy Systems (MIL-STD-1397B), 3 March 1989",
. .
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027, January with the IP Network Address Translator", RFC 3027, January
2001. 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
skipping to change at page 15, line 29 skipping to change at page 15, line 35
IPv6 Network Address Translation", RFC 5902, July 2010. IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", RFC "Understanding Apple's Back to My Mac (BTMM) Service", RFC
6281, June 2011. 6281, June 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011. Translation", RFC 6296, June 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
 End of changes. 77 change blocks. 
277 lines changed or deleted 270 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/