V6OPS B. Liu Internet-Draft S. Jiang Intended status: Informational Y. Bo Expires: April 14, 2015 Huawei Technologies October 11, 2014 Considerations for Running Multiple IPv6 Prefixes draft-liu-v6ops-running-multiple-prefixes-02 Abstract This document describes several typical multiple prefixes use cases. Then analyzes potential operational issues and provides operational considerations of running multiple prefixes. 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 April 14, 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, et al. Expires April 14, 2015 [Page 1] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 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 Considerations . . . . . . . . . . . . . . . . . 4 3.1. Multiple prefix provisioning . . . . . . . . . . . . . . 4 3.2. Consideration for Managing Address Selection in the Network . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Exit-router selection . . . . . . . . . . . . . . . . . . 7 3.4. Miscellaneous Considerations . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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) . IPv6 standards support multiple addresses on a single interface. [RFC6724] defines a default address selection policy among multiple addresses on host. This feature is one of most important improvements comparing to IPv4. It is also a key supporting factor to allow a network running multiple prefixes. In practice, running multiple prefixes in one network introduces operational complexity and there are a few well-known issues in the deployment and network operations. While standardization works to solve these issues are out of scope of this document, network Liu, et al. Expires April 14, 2015 [Page 2] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 administrators should be aware of these operational issues, and also need some guidance/considerations to avoid them. This document provides such operational considerations for site network administrators. Administrators of ISP networks might also benifit from this document ,but they are NOT the intended target audience. 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. 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. For details of using ULAs, please refer to [I-D.ietf-v6ops-ula-usage-recommendations]. 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 space or deploys IPv6 NAT, 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. Liu, et al. Expires April 14, 2015 [Page 3] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 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 [RFC7157]. Especially for the exit-router selection, currently there is no standardized solution yet. (More details Section 3.3.) 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 Considerations This section gives operational considerations for network administrators for running multiple prefix in their networks. 3.1. Multiple prefix provisioning o Avoiding Information from Multiple Provisioning Domains on the Same Link 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. Liu, et al. Expires April 14, 2015 [Page 4] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 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. Solutions [I-D.ietf-mif-mpvd-dhcp-support] [I-D.ietf-mif-mpvd-ndp-support] [I-D.ietf-mif-mpvd-id] have been proposed to address it. Since the technology is still under development and would not be widely supported for a while, the network administrators are recommended to avoid providing information from multiple provisioning domains on the same link for current deployment. o Considerations for Co-existing DHCPv6/SLAAC If administrators enable both DHCPv6 [RFC3315] and SLAAC [RFC4862] for address configuration in one network, then 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. The main operational problems of DHCPv6/SLAAC co-existing might happen are: - When the hosts are already configured by SLAAC and the administrators want to add another address (the added address is probably based on another prefix) by DHCPv6, the operation might fail on certain hosts. This is because some operating systems would ignore the M flag transitioning from 0 to 1, since the relevant behavior is ambiguious in the standard. Thus, if the administrators need to config different addresses on the hosts through DHCPv6 and SLAAC respectively, it needs to be done at the initial stage, that is to make sure the M flag in the RA messages is set at the begining so that the hosts could configure SLAAC and DHCPv6 simultaneously. - According to [RFC6879] a renumbering exercise might cause hosts to switch from one autoconfiguration mechanism to another (e.g., DHCPv6 to SLAAC). Currently, certain opertating systems immediately release the DHCPv6 address when M flag is off. If the prefix is also changed along with the mechanism switching, a flash network renumbering would happen, which against the general "make-before-break" approach recommended in [RFC4192]. Liu, et al. Expires April 14, 2015 [Page 5] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 To avoid this kind of flash renumbering, it is recommendated for the administrators to turn on A flag first to make the hosts all configure SLAAC and then turn the M flag off. The dedicated problem statement document [I-D.ietf-v6ops-dhcpv6-slaac-problem] provides more detailed and comprehensive analysis and considerations. Another document [I-D.liu-v6ops-dhcpv6-slaac-guidance] provides operational guidance to avoid such issue. 3.2. Consideration for Managing Address Selection in the Network In practice, administrators need to concern the following issues. o Inconsistent Behavior in Old and New Address Selection Standards reported various potential problems with address selection in deployment. To address these problems, the updated standard [RFC6724] was developed. Old hosts using [RFC3484] might co-exist with hosts using [RFC6724]. Thus inconsistent behavior would happen. In theory, all the problems described in [RFC5220] might happen in the [RFC3484] hosts. This memo specifically documents following problem which was reported from real expierence. * ULA+IPv4 address selection This is a special case described in section 2.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 an obvious choice. Each employee host will have both an global or private IPv4 address and a ULA. When the ULAs are for local IPv6 communication, there is no problem; however, when a host tries to connect to an outside dual-stack node that has registered both A and AAAA records in the DNS, the host will choose the IPv6 address in the AAAA record as the destination address and choose the ULA for the source address according to the IPv6 preference of the default address selection policy defined in [RFC3484]. This will certainly result in a connection failure. [RFC6724] has added ULA specific rules to prefer IPv4 over ULA, but there might be hosts still under the old [RFC3484] specification. Liu, et al. Expires April 14, 2015 [Page 6] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 Considering [RFC6724] was just published in late 2012, it is very possible that it has not been supported by a large portion of currently under-using operating systems. (The authors did a brief investigation: Windows 8/8.1 and Windows Server 2012/R2 had implemented [RFC6724]; Windows 7 and Windows Server 2008 R2 with the IPv6 readiness update [http://support.microsoft.com/kb/2750841/en-us] also support [RFC6724]; have not found any clear statements of other operating systems whether [RFC6724] is supported or not.) Thus, using ULAs as IPv6 local communication in an network which has not had global IPv6 connectivity yet might not be a good approach for current deployment. 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. Hence, 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. 3.4. Miscellaneous Considerations In the network side, the administrators also need to notice the following potential issues. o Support Multiple-address Management from Network Management Tools It is possible that multiple addresses on a single interface mapping is not well supported on all network management tools (especially the legacy tools). So, the administrators need to check the capablilities of tools before utilizing them, and make sure they support multiple-address management. o ND Cache Shortage in Big L2 Networks In some scenarios, such as campus networks and enterprise networks, the "big L2 network" architecture is often used to reduce the cost and configuration burden. In a big L2 network, a large amount of hosts (e.g. 10K users) are aggregated to the core at layer 2. Liu, et al. Expires April 14, 2015 [Page 7] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 The top-level core switch needs to record the MAC and IP addresses of all the hosts in the aggregation domain as entries in the ARP/ ND table, so that incoming packets toward the hosts could be forwarded directly by the line cards in a line speed. When the ARP/ND table is full, normally the network would not allow new hosts to access; otherwise, the switch needs to instantly look up the destination through ARP/ND broadcast/multicast, thus the CPU needs to be involved in this processing. CPU-involved forwarding would significantly reduce the performance of the switch, and packet loss might happen. According to current state of the art, there are normally 16K or less entries in a switch (the high-end ones could reach to 64K or even higher, per line card). Each IPv4 node normally has only one IPv4 address, so each IPv4 node only ocuppies one IPv4-MAC mapping entry in the cache. It is obvious that the table space is enough for IPv4 network most of the time. However, an IPv6 node would normally have 3 or more IPv6 addresses (e.g. an IPv6-enabled Window 7 host would have at least one link-local IPv6 address, one permanent global IPv6 address and one temporary global IPv6 address when it connects to an IPv6 network.), and each IPv6-MAC mapping entry would requires two to four times the space than IPv4. As the result, a dual-stack node might cost (3 or more)*(2-4) +1 times table space than an IPv4 node, thus the table space shortage is likely to happen in a dual-stack big L2 network. Thus, an L3 core switch which can sufficiently serve an IPv4 big L2 network might not be able to serve an IPv6 big L2 network in an equal scale. So, when designing an IPv6 L2 network, the administratros need to make sure the core L3 switch has enough ND cache. Higer end L3 core switch might be needed, which means higher budget. Or the administrators may have to break the network into several smaller L2 networks. 4. Security Considerations This document is a collection of operational considerations for current technical aspects. It 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. Liu, et al. Expires April 14, 2015 [Page 8] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 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 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [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. [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 Liu, et al. Expires April 14, 2015 [Page 9] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 [I-D.ietf-mif-mpvd-arch] Anipko, D., "Multiple Provisioning Domain Architecture", draft-ietf-mif-mpvd-arch-07 (work in progress), October 2014. [I-D.ietf-mif-mpvd-dhcp-support] Krishnan, S., Korhonen, J., and S. Bhandari, "Support for multiple provisioning domains in DHCPv6", draft-ietf-mif- mpvd-dhcp-support-00 (work in progress), August 2014. [I-D.ietf-mif-mpvd-id] Krishnan, S., Korhonen, J., Bhandari, S., and S. Gundavelli, "Identification of provisioning domains", draft-ietf-mif-mpvd-id-00 (work in progress), August 2014. [I-D.ietf-mif-mpvd-ndp-support] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-00 (work in progress), August 2014. [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.ietf-v6ops-ula-usage-recommendations] Liu, B. and S. Jiang, "Considerations of Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- recommendations-03 (work in progress), July 2014. [I-D.liu-v6ops-dhcpv6-slaac-guidance] Liu, B., Bonica, R., and T. Yang, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", draft-liu- v6ops-dhcpv6-slaac-guidance-02 (work in progress), July 2014. [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. Liu, et al. Expires April 14, 2015 [Page 10] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 [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. [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. [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. [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 Liu, et al. Expires April 14, 2015 [Page 11] Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014 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 April 14, 2015 [Page 12]