[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
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]