[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
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


   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

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

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

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

   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

   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

              Anipko, D., "Multiple Provisioning Domain Architecture",
              draft-ietf-mif-mpvd-arch-11 (work in progress), March

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