V6OPS B. Liu Internet-Draft S. Jiang Intended status: Informational Y. Bo Expires: September 26, 2015 Huawei Technologies March 25, 2015 Multiple IPv6 Prefixes: Background and Considerations draft-liu-v6ops-running-multiple-prefixes-03 Abstract This document describes several typical multiple prefixes use cases, and discusses that running multiple IPv6 prefixes/addresses in one network/host should be common proactice that administrators need to adapt. 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 September 26, 2015. Copyright Notice Copyright (c) 2015 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, et al. Expires September 26, 2015 [Page 1] Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Multiple Prefixes Use cases . . . . . . . . . . . . . . . . . 3 2.1. Multiple Prefixes with Different Scopes . . . . . . . . . 3 2.2. Multihoming based on Multiple PA Prefixes . . . . . . . . 3 2.3. Multiple Prefix Co-existing during Network Renumbering . 4 2.4. Service Prefixes . . . . . . . . . . . . . . . . . . . . 4 3. Operational Availability and Considerations . . . . . . . . . 4 3.1. Multiple prefix provisioning . . . . . . . . . . . . . . 4 3.2. Address Selection . . . . . . . . . . . . . . . . . . . . 5 3.3. Exit-router selection . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In IPv6 networks, there are deployment scenarios in which multiple prefixes coexists simultaneously in one network. Several typical use cases are: - Multiple Prefixes with Different Scopes (described in Section 2.1) - IPv6 multihoming based on multiple PA prefixes (described in Section 2.2) - Make-before-break renumbeirng (described in Section 2.3) - An IPv6 network with multiple services, each of which has a distinct prefix (described in Section 2.4) . To support the multiple prefixes running mode, there have been some technologies developed. This document discusses these technologies of different aspects, which could allow and smoothen the multiple prefiex operation. Note that, although MIF (Multiple InterFaces) [RFC6418] architecture also involves mutliple IPv6 prefixes, it mainly targets different interfaces which attach to different networks respectively. This document discusses the multiple IPv6 prefixes running in the same network. Liu, et al. Expires September 26, 2015 [Page 2] Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015 2. Multiple Prefixes Use cases 2.1. Multiple Prefixes with Different Scopes IPv6 contains link-local addresses, global addresses and unique local addresses, which by definition are global but normally are site-scope by practice. As specified in [RFC4291], all interfaces are required to have at least one Link-Local unicast address. This is the basic case of running multiple prefixes. However, this does not require operations from the network administrators since it is automatically processed. Besides Link-Local addresses, the Unique Local Addresses (ULAs, [RFC4193]) might also be used for the interal communication within a site network. In many deployment, the ULA is used along with PA (Provider Aggregated) addresses, which connect to the public network. The benefit of such combination is to provide seperate local communication from the globally communication so that the local communication would not be impacted when ISP uplink fail or prefix(es) be renumbered. It is especially benificial for the home network and private OAM plane or internal-only nodes in an enterprise. 2.2. Multihoming based on Multiple PA Prefixes When a network is multihomed, the multiple upstream network providers would assign prefixes respectively. If a network does not acquires a PI (Provider Independent) address spaceu, multihoming will result coexistent multiple PA prefixes. In such network, a single host have multiple PA IPv6 addresses that assoicated with different prefixes. This scenario rarely exists in IPv4 networks, since IPv4 only allows single address per interface. But it is quite practical in IPv6. This new feature of IPv6 allows the SMEs (Small/Medium Enterprises) to multihome without the burden of running PI address space or running IPv6 NAT. Furthermore, multiple PA spaces do not have the potential global routing system scalable issue as the PI does [RFC4894]. However, multihoming with multiple PA prefixes has some operational issues which mainly include address selection, next-hop selection, and exit-router selection. For detailed discussion, please refer to [RFC7157]. [Editor's note: more discussion to be filled.] Liu, et al. Expires September 26, 2015 [Page 3] Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015 2.3. Multiple Prefix Co-existing during Network Renumbering [RFC4192] describes a procedure that can be used to renumber a network from one prefix to another smoothly through a "make-before- break" transition. In the transition period, both the old and new prefixes are available; the usage of multiple prefixes provides the smooth transition and avoids the session outage issue in most of renumbering operations. 2.4. Service Prefixes An IPv6 network may simultaneously provide multiple services, such as IPTV, Internet access, VPN, etc. Each of these services should have a distinct prefix. The network may apply different policy based on the distinguished prefixes. This deployment would simplify the management and processing on network devices, such as forwarding routers, access authentication devices, account devices, bourder filter, etc. The ISPs would provide one subscriber multiple addresses/prefixes to access different services. This deployment would paricularly benefit for traffic recognision and management. 3. Operational Availability and Considerations This section discusses some technologies of different aspects, which could allow and smooth the multiple prefiex operation. 3.1. Multiple prefix provisioning o Multiple Prefixes from Different Provisioning Domains In [I-D.ietf-mif-mpvd-arch], provisioning domain is defined as consistent set of network configuration information. Classically, the entire set available on a single interface is provided by a single source, such as network administrator, and can therefore be treated as a single provisioning domain. But in modern IPv6 networks, multihoming or service prefixes may result in provisioning information from more than one provisioning domains being presented on a single link. In these scenarios, current technologies lack support of distinguishing information from multiple provisioning domains, thus the host would not be able to associate configuration information with provisioning domains. However, there are several techniques under developing in MIF WG to solve the problems, we could expect them to be standardized in the near future. Liu, et al. Expires September 26, 2015 [Page 4] Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015 o Co-existing DHCPv6/SLAAC Both SLAAC [RFC4862] and DHCPv6-PD [RFC3633] could assign IPv6 prefixes. DHCPv6-PD is normally run between routers and routers or routers and DHCPv6 [RFC3315] servers; while SLAAC is normally run between routers and downstream hosts. The two protocols could collabarate sufficiently to cover the whole network's prefix provisioning. If operate properly, SLAAC and DHCPv6 could also co-exist for IPv6 addresses provisioning based on different prefixes. They need to carefully deal with the interaction between the two protocols. It is mostly regarding to the M flag in Neighbor Discovery [RFC4861] messages. 3.2. Address Selection In order to support multiple addresses well, IPv6 introduced address selection mechanism which utilize a address selection policy table to calculate a proper source address for a given destination address. Of cource, destination adresses selection is also defined. [RFC6724] described the rationale and algorithms in detail, and also defines a default address selection policy table for operating systems. Note that, the [RFC6724] is a replacement of the old [RFC3484] specification to improve some behaviors (e.g. to prefer IPv4 over ULA for outside connectivity). Currently, so far there haven't been many operating systems supporting the new standard, but we could expect that the new standard would be available in all new released operating systems and becomes the mainstream in the near future. 3.3. Exit-router selection In multiple PA multihoming networks, if the ISPs enable ingress filtering at the edge (BCP38, [RFC2827]), then there comes the exit router selection issues that outgoing packets are routed to the appropriate border router and ISP link. Normally, a packet sourced from an address assigned by ISP X should not be sent via ISP Y, otherwise it would be filtered by ISP Y. In the past, the administrators have to either communicate with the ISP for not filtering the prefixes or manually configure routing policies within the network to make sure the traffics are forwarded to the right upstream link, based on source prefixes. Now, there are some source-based routing technologies under development and standardization. We could expect these solutions available soon. Liu, et al. Expires September 26, 2015 [Page 5] Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015 4. Security Considerations This document does not introduce any new mechanisms or protocols technologies and as such does not introduce any new security threads. Nevertheless, relevant important security considerations are worth to be iterated here: o [RFC7157] gives the security considerations for multi-prefix based multihoming. o Address selection relevant security considerations are described in [RFC6724]. o ND cache exhausion caused by multiple addresses per host in a big L2 network is described in Section 3.2. It is possibility that malicious users intentionally configure massive addresses on host to make the gateway ND cache exhausted. So administrators always need to consider mitigation operations for potential ND cache DoS attack which is documented as [RFC6583]. 5. IANA Considerations This draft does not request any IANA action. 6. Acknowledgements Valuable inputs of the texts/ideas were from Ole Troan. Useful comments were received from Brian Carpenter, Victor Kuarsingh, Lorenzo Colliti, Mikael Abrahamsson, Fred Baker, Lee Howard and Roberta Maglione. This document was produced using the xml2rfc tool [RFC2629]. (initiallly prepared using 2-Word-v2.0.template.dot. ) 7. References 7.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, et al. Expires September 26, 2015 [Page 6] Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 7.2. Informative References [I-D.ietf-mif-mpvd-arch] Anipko, D., "Multiple Provisioning Domain Architecture", draft-ietf-mif-mpvd-arch-11 (work in progress), March 2015. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec", RFC 4894, May 2007. [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011. [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012. Liu, et al. Expires September 26, 2015 [Page 7] Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013. [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", RFC 7157, March 2014. 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 Bo Yang Huawei Technologies Q21, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: boyang.bo@huawei.com Liu, et al. Expires September 26, 2015 [Page 8]