[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Network Working Group                                           B. Liu
Internet Draft                            Huawei Technologies Co., Ltd
Intended status: Informational                           July 15, 2013
Expires: January 16, 2014

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

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.










Bing Liu              Expires January 16, 2014                [Page 1]


Internet-Draft         Running Multiple Prefixes             July 2013




Abstract

   This document introduces that multiple prefixes in one network/host
   might be common in IPv6, and describes several multiple prefixes use
   cases. Then some operational considerations and current gaps to
   support multiple prefixes operations are described.



Table of Contents


   1. Introduction ................................................. 3
   2. Multiple Prefixes Use cases .................................. 3
      2.1. Multihoming ............................................. 3
      2.2. ULA+PA .................................................. 4
      2.3. Make-before-break renumbering ........................... 4
      2.4. Semantic Prefixes ....................................... 4
   3. Basic operational considerations ............................. 5
      3.1. Multiple prefix provisioning ............................ 5
      3.2. Multiple addresses in one interface ..................... 5
      3.3. Address selection ....................................... 6
      3.4. DNS relevant ............................................ 6
   4. Current Gaps ................................................. 6
   5. Security Considerations ...................................... 7
   6. IANA Considerations .......................................... 7
   7. Acknowledgments .............................................. 7
   8. References ................................................... 7
      8.1. Normative References .................................... 7
      8.2. Informative References .................................. 8
















Liu, et al.           Expires January 16, 2014                [Page 2]


Internet-Draft         Running Multiple Prefixes             July 2013




1. Introduction

   IP protocols have been widely spread. More and more services are
   relying on IP infrastructure. And IP network architecture/functions
   are becoming more and more sophisticated accordingly.

   One aspect is the requirement of multiple prefixes. There are some
   probable motivations of multiple prefixes, as the following:

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

   - Multiple logic planes, VPN/OAM .etc.

   In IPv6, multiple prefixes feature is naturally well-supported.
   Standard IPv6 stack supports multiple-addresses-per-interface as
   default; there is a standard address selection algorithms (RFC6724)
   defined for multiple prefixes purpose. Although most of the recent
   IPv4 stacks also support multiple-addresses-per-interfce, IPv6 makes
   it as mandatory and provides way of automatically managing the
   addresses. It is one of the most important advantages from IPv4 to
   IPv6.

   This document discusses several aspects of running multiple prefixes,
   which include some multiple prefixes use cases; some operational
   considerations of running multiple prefixes in a network; and some
   current gaps of supporting running multiple prefixes.

2. Multiple Prefixes Use cases

2.1. Multihoming

   When a network is multihomed, the multiple upstream networks would
   assign prefixes respectively. If a network for some reason neither
   acquires 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.

   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 (Small & Medium Enterprises)
   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].


Liu, et al.           Expires January 16, 2014                [Page 3]


Internet-Draft         Running Multiple Prefixes             July 2013


   However, multihoming with multiple PA spaces has some operational
   issues which mainly include address selection, next-hop selection,
   and DNS selection (see section 5 in
   [I.D-ietf-v6ops-ipv6-multihoming-without-ipv6nat]). Besides, there is
   another exit-router selection issue, which seems has not been
   addresses by any practical solution yet (see some detailed discussion
   in section 4).

2.2. ULA+PA

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

   The main purpose of using ULA along with GUA (Global Unique Address)
   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 uplink (who provides the GUA
   connectivity, e.g. an ISP) 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.3. 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.4. Semantic 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


Liu, et al.           Expires January 16, 2014                [Page 4]


Internet-Draft         Running Multiple Prefixes             July 2013


   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. Basic operational considerations

   There might be some argument/worry that in practice running multiple
   prefixes would makes terrible 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 preference.

   Following sub-sections summarize several important operational
   considerations that try to eliminate the FUD of the administrators.

3.1. Multiple prefix provisioning

   - Multiple provisioning domains: considering current DHCP
   architecture does not fit multiple provisioning domains well, the
   administrators should avoid that multiple provisioning domains all
   directly configuring the host through DHCP, since it might cause
   confusion for the host.

   - Multiple provisioning mechanisms: if administrators applied
   DHCP/SLAAC co-exist in one network, then they need to learn that
   there might be some issues, which are reported in
   [I-D.liu-bonica-dhcpv6-slaac-problems].

3.2. Multiple addresses in one interface

   IPv4 stacks support multiple IP address per interface in the terms of
   "secondary" addresses. This is very useful in practice, especially
   for routers. So in IPv6, it became a mandatory feature. Every IPv6
   interface has a link-local IP address as default. The interfaces
   connected outside might also have a PA address or ULA address. In
   some operation systems (e.g. Windows 7), there's a temporary address
   for privacy purpose as default. So when the interface is connected,
   there might be three addresses as minimum.

   So for the host, current implementations support this feature very
   well; normally this wouldn't be a problem for host multiple addresses
   configuration.


Liu, et al.           Expires January 16, 2014                [Page 5]


Internet-Draft         Running Multiple Prefixes             July 2013


   However,  some current IPAM/NMS applications might have not ready for
   this multiple addresses mappings. This could be an issue for complete
   management.

3.3. Address selection

   Address selecition is an error prone issue in running multiple
   prefixes.

   [RFC5220] reported various potential problems with address selection
   in deployment. Some of them have been handled in the updated standard
   address selection mechanism [RFC6724].

   (Editor's Note: to be filled.)

3.4. DNS relevant

   Normally, one SP only allows only its users to look at DNS records of
   the service. So in multiple network provisioning scenarios, each DNS
   query from a host must be forwarded to a suitable DNS server. Hosts
   normally are not able to select a DNS server for each DNS query
   target.

   [RFC6731] is developed for this purpose; it defined DHCPv4/v6 options
   to deliver the DNS selection policies for hosts. However, since it
   hasn't published for long, there have not been many implementations
   supporting it.

4. Current Gaps

   o Some IPAM/NMS tools might not be able to handle one interface and
      multiple addresses mappings.

   o ULA+IPv4 selection

   There is a special case that needs to be noticed, which is 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 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.



Liu, et al.           Expires January 16, 2014                [Page 6]


Internet-Draft         Running Multiple Prefixes             July 2013


   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 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, 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 easy.

   o Multiple PA 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.

5. Security Considerations

   TBD.

6. IANA Considerations

   This draft does not request any IANA actions.

7. Acknowledgments

   Many useful comments and contributions were made by Sheng Jiang.

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

8. References

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



Liu, et al.           Expires January 16, 2014                [Page 7]


Internet-Draft         Running Multiple Prefixes             July 2013


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

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

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

   [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.liu-bonica-dhcpv6-slaac-problem]
             Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration
             Interaction Problem Statement", Working in Progress,
             February 2013.

   [I.D-ietf-v6ops-ipv6-multihoming-without-ipv6nat]
             Troan, O., Ed. Miles, D., Matsushima, S., Okimoto T., and D.
             Wing, "IPv6 Multihoming without Network Address
             Translation", Working in Progress, March 2013.








Liu, et al.           Expires January 16, 2014                [Page 8]

Internet-Draft         Running Multiple Prefixes             July 2013


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


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/