Running Multiple IPv6 Prefixes
draft-liu-v6ops-running-multiple-prefixes-01

Network Working Group                                           B. Liu
Internet Draft                                                S. Jiang
Intended status: Informational                                   Y. Bo
Expires: January 4, 2015                           Huawei Technologies
                                                          July 3, 2014

                      Running Multiple IPv6 Prefixes
              draft-liu-v6ops-running-multiple-prefixes-01.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 January 4, 2015.

Copyright Notice

   Copyright (c) 2012 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 January 4, 2015                [Page 1]
Internet-Draft         Running Multiple Prefixes             July 2014

Abstract

   This document discusses that multiple prefixes in one network/host
   might be common in IPv6 deployment, and describes several typical
   multiple prefixes use cases. Then some operational considerations and
   current problems of running multiple prefixes are described.

Table of Contents

   1. Introduction ................................................. 3
   2. Multiple Prefixes Use cases .................................. 4
      2.1. Multi-Scope Addresses ................................... 4
      2.2. Multihoming ............................................. 4
      2.3. Service Prefixes ........................................ 5
   3. Operational Considerations and Problems ...................... 5
      3.1. Multiple prefix provisioning ............................ 5
      3.2. Multiple addresses in one interface ..................... 6
      3.3. Address Selection ....................................... 7
      3.4. Exit-router selection ................................... 8
   4. Security Considerations ...................................... 8
   5. IANA Considerations .......................................... 8
   6. Acknowledgments .............................................. 9
   7. References ................................................... 9
      7.1. Normative References .................................... 9
      7.2. Informative References .................................. 9

Liu, et al.           Expires  January 4, 2015                [Page 2]
Internet-Draft         Running Multiple Prefixes             July 2014

1. Introduction

   IP technology has been widely spread. More and more services are
   relying on it. As the evolution of network application, the IP
   network architecture/functions are becoming more and more
   sophisticated.

   One aspect is the requirement of multiple prefixes. There are several
   motivations as the following:

   - Multiple network provisioning, including multihoming and service
   prefixes (as described in section 2.4) etc;

   - Multiple logical planes, VPN/OAM .etc.

   In IPv6, multiple prefixes feature is naturally well-supported.
   Standard IPv6 stack is mandatory to support multiple addresses per
   interface; and there is a standard algorithm [RFC6724] defined for
   address selection. It is an important improvement comparing to IPv4.

   In practice, there might be some worry that running multiple prefixes
   would make significant operational complexity. It is apprehensible
   that most of the administrators are not be accustomed to this model,
   since it is quite different with that in IPv4. But considering
   running multiple prefixes in IPv6 might be very common,
   administrators need to adapt this new operational model regardless of
   personal prefer.

   This document introduces several multiple prefixes use cases in IPv6
   networks; and provides some operational considerations, as while as
   some current problems of running multiple prefixes.

   This document basically targets at a different scope with MIF
   (Multiple Interfaces) [RFC6418]. MIF is focusing on the problems of
   multiple interfaces in a host, typically the interfaces belong to
   different links and different provision domains (see definition in
   Section 3.1 below); while this document specifically focus on the
   multiple prefixes/addresses assigned to one interface. The scenario
   of "multiple provision domains on the same link" is overlapped in
   this document and MIF, this document only focuses the multiple
   prefixes handling part, and leaves the multiple interfaces relevant
   problems space to MIF.

Liu, et al.           Expires  January 4, 2015                [Page 3]
Internet-Draft         Running Multiple Prefixes             July 2014

2. Multiple Prefixes Use cases

2.1. Multi-Scope Addresses

   o Mandatory Link-Local Address

   IPv6 contains link-local addresses, global addresses and unique local
   addresses (which by definition are global but site-scope by practice).

   As specified in [RFC4291], all interfaces are required to have at
   least one Link-Local unicast address. When the interfaces are
   connected and managed, they might be configured with all three types
   of addresses.

   This is the basic case of running multiple prefixes. In this sense,
   multiple prefixes are almost unavoidable when running IPv6.

   o ULAs along with PA (Provider Aggregate) Addresses

   Unique Local Addresses (ULAs) are defined in [RFC4193] as provider-
   independent prefixes. Since there is a 40 bits pseudo random field in
   the ULA prefix, there is no practical risk of collision (please refer
   to section 3.2.3 in [RFC4193] for more detail).

   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 and specific local communication regardless of
   the ISP uplink failure or change. This benefit is especially
   meaningful for the home network or private OAM function in an
   enterprise.

   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.

2.2. Multihoming

   When a network is multihomed, the multiple upstream networks would
   assign prefixes respectively. If a network for some reason neither
   acquire a PI (Provider Independent) space nor deploys IPv6 NAT, then
   the multihoming would resulting in hosts with multiple PA (Provider
   Aggregated) IPv6 addresses with different prefixes.

Liu, et al.           Expires  January 4, 2015                [Page 4]
Internet-Draft         Running Multiple Prefixes             July 2014

   This approach in IPv4 has rarely been used, since the IPv4 doesn't
   support multiple addresses/prefixes well. But it is quite practical
   in IPv6. This approach allows the SMEs to do multihoming without
   burden from running PI address space or running IPv6 NAT. Furthermore,
   multiple PA spaces don't 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, these problems are well documented in
   [RFC7157]. Make-before-break 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;
   it is a very good use of multiple prefixes that could avoid the
   session outage issue in most of the situations when renumbering a
   network.

2.3. Service Prefixes

   [I-D.jiang-semantic-prefix] describes a framework to embed some
   parameters into the IPv6 prefix segment. The parameters might contain
   user types, service types, applications, security requirements,
   traffic identity types, quality requirements and other criteria may
   also be relevant parameters which a network operator may wish to use
   to treat packets differently and efficiently.

   With this approach, for example, the ISPs could provision one
   subscriber multiple addresses/prefixes to access different services.

3. Operational Considerations and Problems

   Following sub-sections discuss operational considerations and
   problems in several important aspects.

3.1. Multiple prefix provisioning

   o Multiple Provisioning Domain

   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  January 4, 2015                [Page 5]
Internet-Draft         Running Multiple Prefixes             July 2014

   But in modern IPv6 networks, multihoming or service prefixes (which
   are described in the introduction section) can result in more than
   one provisioning domain being present on a single link. In these
   scenarios, current DHCP lacks support of distinguishing multiple
   provisioning domains, thus the host would not be able to associate
   configuration information with provisioning domains. There has been a
   proposed solution [I-D.kkb-mpvd-dhcp-support] to address it.

   Since the technology is still under developing, the administrators
   should avoid multiple provisioning domains on the same link for
   current deployment.

   o DHCPv6/SLAAC Co-existing

   If administrators enable both DHCPv6 and SLAAC for address
   configuration in one network, then they need to notice that there
   might be some operational problems, which are reported in [I-D.ietf-
   v6ops-dhcpv6-slaac-problem], and some operational guidelines are
   provided in [I-D.liu-v6ops-dhcpv6-slaac-guidance].

3.2. Multiple addresses in one interface

   Since it is a mandatory feature in IPv6, normally there is no problem
   in hosts' perspective.

   But in the network side, there might be problems as the following.

   o Multiple addresses to one interface mapping might have not been
      well supported by some management tools.

   o ND table space 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 ease the management. In a big L2 network, a large amount of hosts
   (e.g. 10K users) are aggregated to the core at layer 2.

   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 to 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.
   Because in this situation, the switch need to instantly look up the
   destination through ARP/ND broadcast/multicast, thus the CPU needs to
   be involved in this processing. This would significantly cost the
   performance of the switch and packet loss might happen.

Liu, et al.           Expires  January 4, 2015                [Page 6]
Internet-Draft         Running Multiple Prefixes             July 2014

   According to current state of the art, the maximum amount of ARP/ND
   entries in a switch is normally under 16K (the high-end ones could
   reach to 64K, measured by per line card). In IPv4, each host only
   occupies one entry, so normally the table space is enough. However,
   when the network is in an IPv6 transition, the table would be in a
   significant shortage. In implementation, one IPv6 ND entry needs 2-4
   times of an IPv4 ARP entry; and one IPv6-enabled host might configure
   2-4 IPv6 addresses or even more. For example, an IPv6-enabled Window
   7 host would have at least three IPv6 addresses (one link-local
   address, one permanent global address and one temporary global
   address) when it connects to an IPv6 network. Finally, a dual-stack
   network would cost 5-17 times table space than the IPv4 does, so that
   the table space shortage is likely to happen.

3.3. Address Selection

   In practice, address selection has the following issues.

   o Inconsistent Behavior in Old and New Address Selection Standards

   [RFC5220] reported various potential problems with address selection
   in deployment. To address these problems, the updated standard
   [RFC6724] was developed.

   There old hosts which still use the [RFC3484] implementation might
   co-exist with the [RFC6724] hosts. Thus inconsistent behavior would
   happen. Basically, all the problems described in [RFC5220] might
   happen in the [RFC3484] hosts. This document picks two examples that
   might probably happen as the following.

   - ULA specific rules

   In [RFC6724] default policy table, ULAs are specifically treated to
   ensure one ULA address will match a given ULA address in a higher
   priority. But in the default policy table of [RFC3484], ULAs are not
   distinguished, thus a non-ULA address pairs might be sorted out to
   cause connectivity failure.

   - 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 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

Liu, et al.           Expires  January 4, 2015                [Page 7]
Internet-Draft         Running Multiple Prefixes             July 2014

   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 [RFC3484]. This will clearly 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.

   o Lack of Address Pair Failover

   Currently there isn't a good mechanism for triggering an application
   to switch over to a different SA/DA pair when the current one fails.
   The only mechanism we have today is signaling with ICMP destination
   unreachable/wrong source address, but those messages might not been
   passed up to the application in implementations.

   Shim6 has the address-pair failover ability [RFC5534], but it is only
   applicable for the specific shim6 communication.

3.4. Exit-router selection

   In multiple PA multihoming networks, if the ISPs enable ingress
   filtering at the edge, then the administrators need to deal with the
   the exit router selection issues. Currently there is no well-used
   solution, so the administrator might need to communicate with the ISP
   for not filtering the prefixes.

   If a site has multiple PA prefixes, complexities in routing
   configuration will appear. In particular, source-based routing rules
   might be needed to ensure 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, to
   avoid ingress filtering by Y [RFC2827] [RFC3704]. Additional
   considerations can be found in [RFC7157].

   Note that, source-base routing mechanisms proposed in
   [I-D.troan-homenet-sadr] might become solutions to deal with the
   exit-router selection problem in the future.

4. Security Considerations

   TBD.

5. IANA Considerations

   This draft does not request any IANA actions.

Liu, et al.           Expires  January 4, 2015                [Page 8]
Internet-Draft         Running Multiple Prefixes             July 2014

6. Acknowledgments

   Some inputs of the texts/ideas were from Ole Troan.

   Useful comments were received from Brian Carpenter, Victor Kuarsingh
   and Roberta Maglione.

   This document was prepared using 2-Word-v2.0.template.dot.

7. References

7.1. Normative References

   [RFC3315] R. Droms, 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

   [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
             Renumbering an IPv6 Network without a Flag Day", RFC 4192,
             September 2005.

   [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
             Architecture", RFC 4291, February 2006.

   [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
             from the IAB Workshop on Routing and Addressing", RFC 4984,
             September 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.

Liu, et al.           Expires  January 4, 2015                [Page 9]
Internet-Draft         Running Multiple Prefixes             July 2014

   [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
             Dual-Stack Hosts", RFC 6555, April 2012.

   [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
             "Default Address Selection for Internet Protocol Version 6
             (IPv6)", RFC 6724, September 2012.

   [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive
             DNS Server Selection for Multi-Interfaced Nodes", RFC 6731,
             December 2012.

   [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and
             D. Wing, "IPv6 Multihoming without Network Address
             Translation", RFC 7157, March 2014.

   [I-D.ietf-6man-addr-select-opt]
             Matsumoto, A.M., Fujisaki T.F., and T. Chown, "Distributing
             Address Selection Policy using DHCPv6", Working in Progress,
             April 2013.

   [I-D.ietf-v6ops-dhcpv6-slaac-problem]
             Liu, B., Bonica, R., Jiang, S., Gong, X., and W., Wang,
             "DHCPv6/SLAAC Address Configuration Interaction Problem
             Statement", Working in Progress, June 2014.

   [I-D.liu-v6ops-dhcpv6-slaac-guidance]
             Liu, B., Bonica, R., and T. Yang, "DHCPv6/SLAAC Interaction
             Operational Guidance", Working in Progress, February 2014.

   [I-D.ietf-mif-mpvd-arch]
             D. Anipko, "Mutiple Provisioning Domain Architecture",
             Working in Progress, May 2014.

   [I-D.troan-homenet-sadr]
             Troan, O., and L. Colitti, "IPv6 Multihoming with Source
             Address Dependent Routing (SADR)", Work in Progress,
             September 2013.

Liu, et al.           Expires  January 4, 2015               [Page 10]
Internet-Draft         Running Multiple Prefixes             July 2014

Authors' Addresses

   Bing Liu
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Rd.
   Hai-Dian District, Beijing  100095
   P.R. China

   Email: leo.liubing@huawei.com

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14 Building, No.156 Beiqing Rd.,
   Zhong-Guan-Cun Environmental Protection Park, Beijing
   P.R. China

   EMail: jiangsheng@huawei.com

   Yang Bo
   Huawei Technologies Co., Ltd
   Q21, Huawei Campus
   No.156 Beiqing Rd.
   Hai-Dian District, Beijing  100095
   P.R. China

   Email: boyang.bo@huawei.com

Liu, et al.           Expires  January 4, 2015               [Page 11]