Internet Engineering Task Force B. Liu Internet-Draft S. Jiang Intended status: Informational Huawei Technologies Expires: January 5, 2015 July 4, 2014 Considerations of Using Unique Local Addresses draft-ietf-v6ops-ula-usage-recommendations-03 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 provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liu & Jiang Expires January 5, 2015 [Page 1] Internet-Draft Considerations of Using ULAs July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Analysis of ULA Features . . . . . . . . . . . . . . . . . . 3 3.1. Automatically Generated . . . . . . . . . . . . . . . . . 3 3.2. Globally Unique . . . . . . . . . . . . . . . . . . . . . 3 3.3. Independent Address Space . . . . . . . . . . . . . . . . 3 3.4. Well Known Prefix . . . . . . . . . . . . . . . . . . . . 4 3.5. Stable or Temporary Prefix . . . . . . . . . . . . . . . 4 4. Enumeration of Scenarios Using ULAs . . . . . . . . . . . . . 4 4.1. Isolated Networks . . . . . . . . . . . . . . . . . . . . 4 4.2. Connected Network . . . . . . . . . . . . . . . . . . . . 6 4.2.1. ULA-Only Deployment . . . . . . . . . . . . . . . . . 6 4.2.2. ULAs along with PA Addresses . . . . . . . . . . . . 7 4.3. IPv4 Co-existence Considerations . . . . . . . . . . . . 9 5. General Guidelines of Using ULA . . . . . . . . . . . . . . . 10 5.1. Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . . 10 5.2. Using ULAs in a Limited Scope . . . . . . . . . . . . . . 10 6. ULA Usages Considered Helpful . . . . . . . . . . . . . . . . 11 6.1. Used in Isolated Networks . . . . . . . . . . . . . . . . 11 6.2. ULA along with PA . . . . . . . . . . . . . . . . . . . . 11 6.3. Some Specific Use Cases . . . . . . . . . . . . . . . . . 11 6.3.1. Special Routing . . . . . . . . . . . . . . . . . . . 11 6.3.2. Used as NAT64 Prefix . . . . . . . . . . . . . . . . 11 6.3.3. Used as Identifier . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Unique Local Addresses (ULAs) are defined in [RFC4193] as provider- independent prefixes that can be used on isolated networks, internal networks, and VPNs .etc. Although ULAs may be treated like global scope by applications, normally they should not be used on the 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 use of ULAs in various types of networks has been confusing to network operators. This document aims to clarify the advantages and disadvantages of ULAs and how they can be most appropriately used. Liu & Jiang Expires January 5, 2015 [Page 2] Internet-Draft Considerations of Using ULAs July 2014 2. Requirements Language 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 algorithms described in [RFC4193]. This feature allows automatic prefixes allocation, thus one can get a network work immediately without applying prefix (es) from an RIR/LIR (Regional Internet Registry/Local Internet Registry). 3.2. Globally Unique ULAs are intended to have an extremely low probability of collision. Since the hosts assigned with ULAs may occasionally be merged into one network, this uniqueness is necessary. The randomization of 40 bits in a ULA prefix is considered sufficient enough to ensure a high degree of uniqueness (refer to [RFC4193] Section 3.2.3 for details) and makes merging of networks simple and without the need to renumber overlapping IP address space. Overlapping is cited as a deficiency with how [RFC1918] addresses were deployed, and ULA was designed to overcome this deficiency. Note that as described in [RFC4864], in practice, applications may treat ULAs like global-scope addresses, but address selection algorithms may need to distinguish between ULAs and ordinary GUA (Global-scope Unicast Address) to ensure bidirectional communications. (Note: the new address selection standard has supported this in the default policy table. [RFC6724]) 3.3. Independent Address Space ULAs provide internal address independence in IPv6 that they can be used for internal communications without having any permanent or only intermittent Internet connectivity. And it needs no registration so that it can support on-demand usage and does not carry any RIR/LIR documentation/fees burden or disclosures. Liu & Jiang Expires January 5, 2015 [Page 3] Internet-Draft Considerations of Using ULAs July 2014 3.4. Well Known Prefix The prefixes of ULAs are well known thus they are easy to be identified and filtered. This feature is convenient for management of security policies and troubleshooting. For example, the administrators can decide what parameters have to be assembled or transmitted globally, by a separate function, through an appropriate gateway/firewall, to the Internet or to the telecom network. 3.5. Stable or Temporary Prefix 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. 4. Enumeration of Scenarios Using ULAs 4.1. Isolated Networks IP is used ubiquitously. Some networks like industrial control bus (e.g. [RS-485], [SCADA], or even non-networked digital interface like [MIL-STD-1397] began to use IP protocol. In such kind of networks, the system might lack the ability/requirement of connecting to the Internet or explicitly designed not to connect. Besides, there might be some networks which could connect to the Internet, but prohibited by administration or just temporally not connected. These networks may include machine-to-machine (e.g. vehicle networks), sensor networks, or even normal LANs, which may include very large numbers of addresses. Since the serious disadvantages and impact on applications by ambiguous address space have been well documented in [RFC1918], ULA is a straightforward way to assign the IP addresses in these kinds of networks with minimal administrative cost or burden. Also, ULAs fit in multiple subnet scenarios, in which each subnet has its own ULA prefix. For example, when we assign vehicles with ULA addresses, it is then possible to separate in-vehicle embedded networks into different subnets depending on real-time requirements, devices types, services and more. However, each isolated network has the possibility to be connected in the future. The administrators need to consider following things: Liu & Jiang Expires January 5, 2015 [Page 4] Internet-Draft Considerations of Using ULAs July 2014 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 merge Drawbacks: o The uniqueness of the global ULA prefix is not guaranteed, however, the probability of collision is extremely low. 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 with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) settings, prior knowledge of respective prefixes is unlikely. Hence, a prefix announcement mechanism is needed to enable inter- vehicles communications based on IP. For instance, such announcement could rely on an extension of the Router Advertisement message of Neighbor Discovery Protocol (e.g. [I-D.petrescu-autoconf-ra-based-routing] and [I-D.jhlee-mext-mnpp]). Liu & Jiang Expires January 5, 2015 [Page 5] Internet-Draft Considerations of Using ULAs July 2014 4.2. Connected Network 4.2.1. ULA-Only Deployment In some situations, hosts/interfaces are assigned with ULA-only, but the networks need to communicate with the outside. It mainly includes the following two models. o Using Network Prefix Translation Network Prefix Translation (NPTv6) [RFC6296] is an experimental specification that provides a stateless one to one mapping 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. Thus this document does not recommend the use of ULA+NPTv6. Rather, this document considers ULA+PA (Provider Aggregated) as a better approach to connect to the global network when ULAs are expected to be retained. The use of ULA+PA is discussed in detail in Section 4.2.2 below. o Using Application-Layer Proxies The proxies terminate the network-layer connectivity of the hosts and delegate the outgoing/incoming connections. In some environments (e.g. Information security sensitive 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. Benefits of using ULAs in this scenario: o Allowing minimal management burden on address assignment for some specific environments. Drawbacks: o The serious disadvantages and impact on applications by NAT have been well documented in [RFC2993] and [RFC3027]. Although NPTv6 is a mechanism that has fewer architectural problems than merely Liu & Jiang Expires January 5, 2015 [Page 6] Internet-Draft Considerations of Using ULAs July 2014 implementing a traditional stateful Network Address Translator in an IPv6 environment [RFC6296], it still beaks the end-to-end transparency which is in general not recommended by the IETF. Operational considerations: 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. - 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.). 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 an ISP. And besides, they may need internal routed networking even when the ISP link is down. Then ULA is a proper tool to fit the requirement. And in [RFC6204], it requires the CPE to support ULA. Note, ULAs provide more benefit for multiple-segment home networks; for home networks only containing one segment, link- local addresses are better alternatives. o Enterprise network. An enterprise network is usually a managed 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 connectivity redundancy and better internal connectivity or isolation of certain functions like OAM of servers. Benefits of Using ULAs in this scenario: o Separated local communication plane: for either home networks or enterprise networks, the main purpose of using ULAs along with PA addresses is to provide a logically local routing plane separated from the globally routing plane. The benefit is to ensure stable Liu & Jiang Expires January 5, 2015 [Page 7] Internet-Draft Considerations of Using ULAs July 2014 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 nodes. Besides the internal-only nodes, the public nodes can also benefit from ULA for renumbering. When renumbering, as [RFC4192] suggested, it has a period to keep using the old prefix(es) before the new prefix(es) is(are) stable. In the process of adding new prefix(es) and deprecating old prefix(es), it is not easy to keep the local communication immune of global routing plane change. If we use ULAs for the local communication, the separated local routing plane can isolate the affecting by global routing change. Drawbacks: o Operational Complexity: there are some arguments that in practice the ULA+PA makes additional operational complexity. It is not a 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 running a single one. Operational considerations: o Default Routing: connectivity might be broken if ULAs are used as default route. When using RIO (Route Information Option) in [RFC4191], specific routs would be added without a default route, 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 Liu & Jiang Expires January 5, 2015 [Page 8] Internet-Draft Considerations of Using ULAs July 2014 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 [I-D.ietf-v6ops-dhcpv6-slaac-problem] for details). o Address selection: As mentioned in [RFC5220], there is a possibility that the longest matching rule will not be able to choose the correct address between ULAs and global unicast addresses for correct intra-site and extra-site communication. In [RFC6724], it claimed that a site-specific policy entry can be used to cause ULAs within a site to be preferred over global addresses. o DNS relevant: if administrators chose not to do reverse DNS delegation inside of their local control of ULA prefixes, a significant amount of information about the ULA population might leak to the outside world. Because reverse queries will be made and naturally routed to the global reverse tree, so people will be exposed to the existence of population the ULA uses, not in traffic terms, but in knowledge terms. [ULA-IN-WILD] provides more detailed situations on this issue. Administrators may need a split DNS to separate the queries from internal and external for ULA entries and GUA entries. 4.3. IPv4 Co-existence Considerations Generally, this document does not consider IPv4 relevant as in the scope But regarding ULA, there is a special case needs to be noticed, which is described in Section 3.2.2 of [RFC5220]. When an enterprise has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, and the enterprise wants to provide site-local IPv6 connectivity, a ULA is the best choice for site-local IPv6 connectivity. Each employee host will have both an IPv4 global or private address and a ULA. Here, when this host tries to connect to an outside node that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and the ULA for the source address according to the IPv6 preference of the default address selection policy. This will clearly result in a connection failure. Although with Happy Eyeballs [RFC6555] this connection failure problem could be solved, but unwanted timeouts would obviously lower the user experience. One possible approach of eliminating the timeouts is deprecating IPv6 default route and simply configuring a scoped route on hosts (in the context of this document, only configure the ULA prefix routes). Another alternative is configuring IPv4 preference on the hosts, and not including DNS A records but only AAAA records for the internal nodes in the internal DNS server, Liu & Jiang Expires January 5, 2015 [Page 9] Internet-Draft Considerations of Using ULAs July 2014 then outside nodes have both A and AAAA records could be connected through IPv4 as default and internal nodes could be always connected through IPv6. But since IPv6 preference is default, changing the default in all nodes is not suitable at scale. 5. General Guidelines of Using ULA 5.1. Do Not Treat ULA Equal to RFC1918 ULA and [RFC1918] are similar in some aspects. The most obvious one is as described in Section 3.1.3 that ULA provides an internal address independence capability in IPv6 that is similar to how [RFC1918] is commonly used. ULA allows administrators to configure the internal network of each platform the same way it is configured in IPv4. Many organizations have security policies and architectures based around the local-only routing of [RFC1918] addresses and those policies may directly map to ULA [RFC4864]. But it doesn't mean ULA is equal to an IPv6 version of [RFC1918] deployment. [RFC1918] usually combines with NAT/NAPT for global connectivity. But it is not necessarily to combine ULAs with any kind of NAT. People could use ULA for local communications along with global addresses for global communications (see Section 6.2). This is a big advantage brought by default support of multiple- addresses-per-interface feature in IPv6. (People might still have requirement of ULA with NAT, this is discussed in Section 4.2.1. But people also should keep in mind that ULA is not intentionally designed for this kind of use case.) Another important difference is the ability to merge two ULA networks without renumbering (because of the uniqueness), which is a big advantage over [RFC1918]. 5.2. Using ULAs in a Limited Scope A ULA is by definition a prefix that is never advertised outside a given domain, and is used within that domain by agreement of those networked by the domain. So when using ULAs in a network, the administrators should clearly set the scope of the ULAs and configure ACLs on relevant border routers to block them out of the scope. And if internal DNS are enabled, the administrators might also need to use internal-only 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. Liu & Jiang Expires January 5, 2015 [Page 10] Internet-Draft Considerations of Using ULAs July 2014 6. ULA Usages Considered Helpful 6.1. Used in Isolated Networks As analyzed in Section 4.1, ULA is very suitable for isolated networks. Especially when there are subnets in the isolated network, ULA is a reasonable choice. 6.2. ULA along with PA As the benefits described in Section 4.2.2, using ULAs along with PA addresses to provide a logically separated local plane could benefit to OAM functions and renumbering. 6.3. Some Specific Use Cases Along with the general scenarios, this section provides some specific use cases that could benefit from using ULA. 6.3.1. Special Routing For various reasons the administrators might want to have private routing be controlled and separated from other routing. For example, in the b2b case described in [I-D.baker-v6ops-b2b-private-routing], two companies might want to use direct connectivity that only connects stated machines, such as a silicon foundry with client engineers that use it. A ULA provides a simple way to assign such prefixes that would be used in accordance with an agreement between the parties. 6.3.2. Used as NAT64 Prefix 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 pref64, it could easily ensures that only local systems can use the translation resources of the NAT64 system since the ULA is not intended to be globally routable and helps clearly identify traffic that is locally contained and destine to a NAT64. Using ULA for Pref64 is deployed and it is an operational model. But there's an issue should be noticed. The NAT64 standard [RFC6146] mentioned the pref64 should align with [RFC6052], in which the IPv4-Embedded IPv6 Address format was specified. If we pick a /48 for NAT64, it happened to be a standard 48/ part of ULA (7bit ULA famous prefix+ 1 "L" bit + 40bit Global ID). Then the 40bit of ULA is not violated to be filled with part of the 32bit IPv4 address. This is important, because the 40bit assures the uniqueness of ULA, if the prefix is shorter than /48, the 40bit would be violated, and Liu & Jiang Expires January 5, 2015 [Page 11] Internet-Draft Considerations of Using ULAs July 2014 this may cause conformance issue. But it is considered that the most common use case will be a /96 PREF64, or even /64 will be used. So it seems this issue is not common in current practice. It is most common that ULA Pref64 will be deployed on a single internal network, where the clients and the NAT64 share a common internal network. ULA will not be effective as Pref64 when the access network must use an Internet transit to receive the translation service of a NAT64 since the ULA will not route across the Internet. According to the default address selection table specified in [RFC6724], the host would always prefer IPv4 over ULA. This could be a problem in NAT64-CGN scenario as analyzed in Section 8 of [RFC7269]. So administrators need to add additional site-specific address selection rules to the default table to steer traffic flows going through NAT64-CGN. However, updating the default policy tables in all hosts involves significant management cost. This may be possible in an enterprise (using a group policy object, or other configuration mechanisms), but it is not suitable at scale for home networks. 6.3.3. Used as Identifier ULAs could be self-generated and easily grabbed from the standard IPv6 stack. And ULAs don't need to be changed as the GUA prefixes do. So they are very suitable to be used as identifiers by the up layer applications. And since ULA is not intended to be globally routed, it is not harmful to the routing system. Such kind of benefit has been utilized in real implementations. For example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to assign a topology-independent identifier to each client host according to the following considerations: o TCP connections between two end hosts wish to survive in network changes. o Sometimes one needs a constant identifier to be associated with a key so that the Security Association can survive the location changes. It should be noticed again that in theory ULA has the possibility of collision. However, the probability is desirable small enough and could be ignored by most of the cases when used as identifiers. Liu & Jiang Expires January 5, 2015 [Page 12] Internet-Draft Considerations of Using ULAs July 2014 7. Security Considerations Security considerations regarding ULAs, in general, please refer to the ULA specification [RFC4193]. Also refer to [RFC4864], which shows how ULAs help with local network protection. As mentioned in Section 5.2.1, when use NPTv6, the administrators need to know about where the firewall is located to set proper filtering rules. As mentioned in Section 5.2.2, if administrators chose not to do reverse DNS delegation inside their local control of ULA prefixes, a significant amount of information about the ULA population might leak to the outside world. 8. IANA Considerations IANA considerations should be updated to point to [RFC4193] in a similar manner to section 5. 9. Acknowledgements Many valuable comments were received in the IETF v6ops WG mail list, especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews, Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton, Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler, Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali and Wesley George. Some test of using ULA in the lab was done by our research partner BNRC-BUPT (Broad Network Research Centre in Beijing University of Posts and Telecommunications). Thanks for the work of Prof. Xiangyang Gong and student Dengjia Xu. This document was produced using the xml2rfc tool [RFC2629] (initially prepared using 2-Word-v2.0.template.dot.). 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Liu & Jiang Expires January 5, 2015 [Page 13] Internet-Draft Considerations of Using ULAs July 2014 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. 10.2. Informative References [I-D.baker-v6ops-b2b-private-routing] Baker, F., "Business to Business Private Routing", draft- baker-v6ops-b2b-private-routing-00 (work in progress), July 2007. [I-D.ietf-v6ops-dhcpv6-slaac-problem] Liu, B., Bonica, R., Gong, X., and W. Wang, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", draft-ietf-v6ops-dhcpv6-slaac-problem-01 (work in progress), June 2014. [I-D.jhlee-mext-mnpp] Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix Provisioning", draft-jhlee-mext-mnpp-00 (work in progress), October 2009. [I-D.petrescu-autoconf-ra-based-routing] 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. [MIL-STD-1397] "Military Standard, Input/Output Interfaces, Standard Digital Data, Navy Systems (MIL-STD-1397B), 3 March 1989", . [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. Liu & Jiang Expires January 5, 2015 [Page 14] Internet-Draft Considerations of Using ULAs July 2014 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi- Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008. [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 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, "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. Liu & Jiang Expires January 5, 2015 [Page 15] Internet-Draft Considerations of Using ULAs July 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 Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: leo.liubing@huawei.com Sheng Jiang Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Liu & Jiang Expires January 5, 2015 [Page 16]