Network Working Group B. Liu Internet Draft S. Jiang Intended status: Best Current Practice Huawei Technologies Co., Ltd Expires: April 2012 October 22, 2011 Analysis and recommendation for the ULA usage draft-liu-v6ops-ula-usage-analysis-00.txt 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 May 10, 2012. Copyright Notice Copyright (c) 2011 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. Abstract This document tries to cover all kinds of ULA use cases. And then tries to identify some potentially valuable use cases which can benefit from ULA. Expires April 22, 2012 [Page 1] Liu & Jiang Internet-Draft draft-liu-v6ops-ula-analysis October 2011 Table of Contents 1. Introduction ................................................. 2 2. The features of ULA .......................................... 2 2.1. Globally unique ......................................... 2 2.2. Independent address space ............................... 3 2.3. Well known prefix ....................................... 3 3. ULA usage analysis ........................................... 3 3.1. ULA as address .......................................... 3 3.1.1. ULA-only deployment ................................ 3 3.1.2. ULA co-exist with globally routable addresses ...... 4 3.2. ULA as identifier ....................................... 5 3.3. Centrally assigned ULAs ................................. 6 4. Benefit to renumbering ....................................... 6 5. Benefit to security/privacy .................................. 6 6. Security Considerations ...................................... 6 7. IANA Considerations .......................................... 6 8. Conclusions .................................................. 7 9. References ................................................... 7 9.1. Normative References .................................... 7 9.2. Informative References .................................. 7 10. Acknowledgments ............................................. 8 1. Introduction Unique Local Addresses (ULAs) are defined in RFC 4193 [RFC4193], which defines a local assignment method to be used for local, provider-independent prefixes that can be used on isolated networks, internal networks and VPNs. This document tries to cover all kinds of use cases regardless of whether they are valid or not. And then tries to identify some potentially valuable use cases. Particularly, this document intends to call for any existing practice of deploying ULA to be discussed in this document. 2. The features of ULA 2.1. Globally unique ULA is intended to be globally unique to avoid collision. Since the hosts assigned with ULA may occasionally be merged into one network. However, it still has some probability to have collision although the probability is very small. Liu & Jiang Expires April 22, 2012 [Page 2] Internet-Draft draft-liu-v6ops-ula-analysis October 2011 Notice 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 global- scope unicast addresses to ensure stability. 2.2. Independent address space ULA provides ability in IPv6 that can perform the same function as RFC 1918. It allows administrators to configure the internal network of each platform the same way. It 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. ULAs are not intended to be routed in the Internet. So it won't bother much for the routing system if ULAs leaks. 2.3. Well known prefix The prefixes of ULAs are well known that they are easy to be identified and easy to be filtered. This feature may bring convenient to management or security policies. 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. ULA usage analysis In this section, we try to cover every possible ULA use case. Some of them have been discussed in other documents which are briefly reviewed as well as other potential valid usage is discussed. 3.1. ULA as address This section talks about use cases that hosts in a network are only assigned with ULAs. 3.1.1. ULA-only deployment - Isolated network As we know, IP is used ubiquitously now. Some situations like RS-485, or other type of industrial control bus, or even non-networked digital interface like MIL-STD-1397 began to use IP protocol. Liu & Jiang Expires April 22, 2012 [Page 3] Internet-Draft draft-liu-v6ops-ula-analysis October 2011 These systems/platforms may be used in building, car, plane .etc which normally are isolated. To configure addresses in these systems/environment, we need a straightforward way with minimal administrative cost. ULA is a good solution for these use cases. The address space is provided on-demand, however, for these pure isolated networks, it still need automatic ULA address provision. - Connected network In some situations, hosts/interfaces are assigned with ULA-only, but the networks need to communicate with the outside. This use case fits the requirement that the system/platform/network needs connectivity to the outside but doesn't want the addresses to be globally routed. The use case could be achieved through the following two methods. o With NAT, some a kind of NAT which provides a simple one to one mapping for a subset of the internal addresses could fit the requirement. However, NAT in IPv6 has been always a long-term argued topic. This document does not intend to involve the IPv6 NAT argument, but rather to consider the NAT is a possible solution. o Without NAT, using a application-layer proxy can also fit the requirement as while as isolates the connectivity at level 3 and no NAT is required to be involved. Application Access from outside can be strict controlled. Does not matter which address used. 3.1.2. ULA co-exist with globally routable addresses - ULA with PA There are two classes of network probably to use ULA with PA addresses: o Homenet like, which are normally assigned with PA addresses to connect to the uplink of some a ISP. And besides, they may use ULA to provide routed networking even when the ISP link is down. As presented in the IETF Homenet WG, they have the desire for the network to provide a stable ULA with limited routing scope alongside a global address for Global Internet routing scope. o Enterprise like, this is a managed network with a fixed PA space. The ULA could be used for internal connectivity redundancy and better internal connectivity. Liu & Jiang Expires April 22, 2012 [Page 4] Internet-Draft draft-liu-v6ops-ula-analysis October 2011 For enterprise, some people argued that in practice they don't prefer ULA+PA, but it is ambiguous that they just don't prefer ULA with PA, or just don't prefer running multiple addresses. Besides the unwelcome multiple addresses operation, as commented in [RFC6296], this use case fails to meet the requirement for address independence, because if an ISP renumbering event occurs, all of the hosts, routers, DHCP servers, Access Control Lists (ACLs), firewalls, and other internal systems that are configured with global addresses from the ISP will need to be renumbered before global connectivity is fully restored. Another issue is 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. [note: needs to identify whether it is still suitable for 3484-bis] - ULA with PI TBD. 3.2. ULA as identifier 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[RFC6281]. ULA can fit the requirements, and besides, ULA can be used directly because it belongs to the existing IPv6 code and it can be created by the ends themselves at boot time. As ULA would not cause any problem to the routing system, it can be considered as an ID/Locator split solution in this case. But there is a problem of ULAs being identifiers, that in theory it has the possibility of collision. However, the probability is desirable small enough. Liu & Jiang Expires April 22, 2012 [Page 5] Internet-Draft draft-liu-v6ops-ula-analysis October 2011 3.3. Centrally assigned ULAs Besides the normal ULA, there has been some discussion about centrally assigned ULAs (ULA-C) raised in IETF. As analyzed in [I-D. mrw-6man-ulac-analysis], ULA-C has the benefits of greater assurance of uniqueness, accountability, and being able to populated in global reverse DNS. This document does not intend to involve the argument of ULA-C, but wants to quote it as a kind of special usage of ULA. 4. Benefit to renumbering Enterprise administrators want to avoid the need to renumber their internal, private networks when they change ISPs, or when their ISPs merge with other ISPs or restructure their address allocations. In these situations, ULA is an effective solution. 5. Benefit to security/privacy As mentioned in [RFC4864], ULAs have no intrinsic security properties. However, they have the useful property that their routing scope is limited by default within an administrative boundary. One typical benefit of the limited routing scope is about the IP leaking issue. In the IPv4 practice, the internal IP addresses seem hard to avoid be leaked. For this reason, if ULAs are used, it won't be a serious problem since the ULAs are not able to be routed globally. This will bring much benefit for security or privacy. 6. Security Considerations Security considerations regarding ULAs, in general, please refer to the ULA specification RFC 4193 [RFC4193], and security considerations regarding Centrally Assigned ULAs, in particular, please refer to the ULA-C draft [I-D.ietf-ipv6-ula-central]. 7. IANA Considerations None. Liu & Jiang Expires April 22, 2012 [Page 6] Internet-Draft draft-liu-v6ops-ula-analysis October 2011 8. Conclusions TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1997. [RFC4193] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. 9.2. Informative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets",BCP 5, RFC 1918, February 1996. [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. [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. [I-D.ietf-ipv6-ula-central] Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-02 (work in progress), June 2007. [I-D. mrw-6man-ulac-analysis] Wasserman, M., "An Analysis of Centrally Assigned Unique Local Addresses", November 2007 Liu & Jiang Expires April 22, 2012 [Page 7] Internet-Draft draft-liu-v6ops-ula-analysis October 2011 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Liu & Jiang Expires April 22, 2012 [Page 8] Internet-Draft draft-liu-v6ops-ula-analysis October 2011 Authors' Addresses Bing Liu Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing P.R. China Email: leo.liubing@huawei.com Sheng Jiang Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing P.R. China Email: jiangsheng@huawei.com Liu & Jiang Expires April 22, 2012 [Page 9]