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

Versions: 00 01 02

Internet Engineering Task Force                              M. Townsley
Internet-Draft                                                  O. Troan
Intended status: Informational                                     cisco
Expires: June 18, 2012                                 December 16, 2011


     Basic Requirements for Customer Edge Routers - multihoming and
                               transition
             draft-townsley-troan-ipv6-ce-transitioning-02

Abstract

   This document specifies general IPv6 multihoming and specific 6rd
   transitioning requirements for an IPv6 Customer Edge (CE) router.  It
   also provides an illustrative implementation model for IPv4
   multihoming in order to support shared IPv4 transition mechanisms
   that utilize IPv6 as a transport for IPv4.

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 June 18, 2012.

Copyright Notice

   Copyright (c) 2011 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



Townsley & Troan          Expires June 18, 2012                 [Page 1]


Internet-Draft           CE router requirements            December 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IPv6 MultiPrefix Multihoming . . . . . . . . . . . . . . . . .  4
     3.1.  Multihoming requirements . . . . . . . . . . . . . . . . .  5
     3.2.  6rd Sunsetting Requirements  . . . . . . . . . . . . . . .  5
   4.  IPv4 NAT Multihoming . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  IPv4 Multihoming Data Structures . . . . . . . . . . . . .  6
     4.2.  IPv4 Packet flow . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Example RIB Policy for IPv4 to IPv6 Transition . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Configuration-oriented multihoming  . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10




























Townsley & Troan          Expires June 18, 2012                 [Page 2]


Internet-Draft           CE router requirements            December 2011


1.  Introduction

   The CE requirements specified in RFC 6204 are based on a fundamental
   assumption that a CE router has a single active WAN interface for
   forwarding IPv4 and IPv6 traffic towards an ISP.  The operation of
   IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native
   together, forces us to reconsider this basic assumption.

   There are three possible steady-state combinations of "native" and
   "virtual" (tunneled) dual-stack service models (an IPv6-only service
   model, while imperative for finalizing the transition to IPv6, is
   currently out of scope in [RFC6204] and [I-D.ietf-v6ops-6204bis])
   that do not break the fundamental assumption of having no more than
   one WAN interface per IP version.

   1.  One Native IPv4 and IPv6 interface (Classic Dual-Stack)

   2.  One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires
       Hub and Spoke via L2TP, TSP, etc)

   3.  One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd,
       etc)

   For (1), IPv4 and IPv6 each share a single WAN interface, so there is
   no problem when enabling one vs. the other.

   For (2), when enabling tunneled IPv6 on an existing IPv4-only network
   there is no significant change in the basic model as each IP version
   still has its own distinct single WAN interface.  Multihoming issues
   arise when enabling native IPv6 alongside tunneled IPv6 (needed for
   "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces
   at the same time.

   For (3) there similarly is no problem when enabling tunneled IPv4 on
   an existing IPv6-only network, and we understand that there are
   greenfield deployments just like this happening.  Multihoming issues
   arise when enabling tunneled IPv4 on a network that has native IPv4
   available at the same time.

   The multihoming model described in this document assumes the operator
   or user can configure any WAN interface type at any time.  The CE
   follows forwarding rules defined in this document in order to ensure
   packets make it out the right interface on WAN egress, and liberally
   accepts packets on WAN ingress.  This is "classic multihoming" and
   should work for any order of planned incremental transition steps, as
   well as failover and/or transient situations.

   While this authors of this document believe that the forward-oriented



Townsley & Troan          Expires June 18, 2012                 [Page 3]


Internet-Draft           CE router requirements            December 2011


   model, there is another approach which we identify as "Configuration-
   oriented" and describe briefly in Appendix A.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Terminology

   SRIB                      A Source Address Routing Information Base
                             containing an entry per delegated prefix.
                             Each entry points to one or more
                             Destination Address Routing Tables (DRIB).

   DRIB                      A Destination Address Routing Information
                             Base used for destination address longest
                             matching lookups.  Each entry points to one
                             or more next-hops.

   NPIB                      Network Address and Port Translation (NAPT)
                             Information Base used binding "flows" to an
                             egress WAN interface.

   NPIB entry                The address and port mapping state
                             [RFC4787] at the NAT necessary for network
                             address and port translation.


3.  IPv6 MultiPrefix Multihoming

   A multihomed, multiprefix, IPv6 CE router has multiple WAN interfaces
   connecting it to one or more Service Providers.  The interfaces may
   be "real" or "virtual" in the case of tunneling technology such as
   6rd [RFC5969].  The CE router receives one or more delegated
   prefixes, each associated with one or more WAN interfaces.  The CE
   router has a single SRIB, and one DRIB associated with each WAN
   Interface.

   WAN interfaces are used to send Ingress traffic from the Internet to
   the End-User, and Egress traffic from the End-User network to the
   Internet.  Ingress traffic may be received on any active interface at
   any time.  Egress traffic follows a set of rules within the CE in
   order to choose the proper WAN interface.  This is important not only
   in order to choose the best path, but also because the networks that
   the CE are connected to typically employ source address verification



Townsley & Troan          Expires June 18, 2012                 [Page 4]


Internet-Draft           CE router requirements            December 2011


   mechanisms.

   Packets arriving at the CE have an IPv6 source address chosen by the
   host [RFC3484].  The SRIB contains an entry for each delegated prefix
   with a pointer to one or more DRIBs.  A longest matching lookup based
   upon the source address of each arriving packet is performed within
   the SRIB to determine the DRIB(s).  The egress WAN interface to use
   for sending a packet is then chosen by performing a longest matching
   lookup within the resulting DRIB(s).

3.1.  Multihoming requirements

   MH-1:  An IPv6 CE router MUST create a separate DRIB for each WAN
          interface (real or virtual) and installs a route for the
          associated delegated prefix, default route and more specific
          routes.

   MH-2:  An IPv6 CE router MUST create an SRIB containing entries for
          associated delegated prefixes.  Each entry points to one or
          more DRIBs.  An entry points to multiple DRIBs only in the
          case where an identical delegated prefix is associated with
          multiple WAN interfaces.

   MH-3:  When forwarding a packet from a LAN interface, the CE router
          MUST do a longest matching lookup based on the packet's Source
          Address in the SRIB.  A Destination Address lookup is then
          performed in the corresponding DRIB or DRIBs.  When there are
          multiple equal matches, the route with the lowest cost is
          chosen.

3.2.  6rd Sunsetting Requirements

   6RDS-1:  Multihoming as defined in section Section 3 MUST be
            supported, allowing 6rd and native packets to be sent and
            received as long as 6rd configuration is provided by the
            ISP.

   6RDS-2:  By default, the 6rd virtual interface MUST be assigned a
            higher routing cost than a native IPv6 interface.

   6RDS-3:  The IPv6 CE router MUST support that 6rd and native IPv6
            delegated prefixes are identical or different, and operate
            as defined in the multihoming section.








Townsley & Troan          Expires June 18, 2012                 [Page 5]


Internet-Draft           CE router requirements            December 2011


4.  IPv4 NAT Multihoming

   This section describes a general implementation model used to
   illustrate CE IPv4 multihoming, alongside specifics for using the
   model to support IPv6 transition technologies aimed at delivering
   IPv4 within an IPv6 transport (e.g., DS-Lite).

   A multihomed IPv4 CE router has multiple "physical" or "virtual" WAN
   interfaces connecting it to one or more Service Providers.  WAN
   interfaces are used to send Ingress traffic from the Internet to the
   End-User, and Egress traffic from the End-User network to the
   Internet.  Each WAN interface may be configured with a single public
   IPv4 address, private IPv4 address [RFC1918], a shared IPv4 address
   [A+P], or no IPv4 address at all.

   An IPv4 CE router WAN interface is often configured in the same
   manner as a single host, i.e., with a single 32-bit IPv4 address.  A
   CE router NAPT function, in turn, allows more than one device within
   the end-user network to appear as a single host with a single IPv4
   address facing the ISP network.  The CE router NAPT function is
   responsible for rewriting IPv4 headers with the address assigned to
   the associated WAN interface with the expectation that return traffic
   will be sent back to that address.

   IPv4 WAN interfaces which are not configured with an IPv4 address by
   the ISP (e.g., DS-Lite, L2-aware NAT), bypass the translation
   function of the NAPT when forwarding traffic.  In this case, the
   ISP's centralized NAPT function is responsible for rewriting IPv4
   headers with a source address which ensures return traffic will reach
   the proper NAPT binding within the ISP.

4.1.  IPv4 Multihoming Data Structures

   The CE router has a single NAPT Information Base (NPIB) which
   consists of Dynamic and Configured entries.  A WAN interface
   provisioned with an IPv4 address has an associated NAPT function
   which examines packet flow and programs the NPIB with Dynamic entries
   as they are identified.  For example, an active TCP session on the CE
   correlates to a single Dynamic entry within the NPIB.  A Dynamic
   entry in the NPIB table unambiguously identifies packets that are
   associated with it when an NPIB Lookup is performed.

   Configured NPIB entries allow for rules to be specified which direct
   traffic in a specific manner.  Unlike Dynamic entries, Configured
   entries allow for "wildcards", and may be end-user configured or
   configured by a protocol such as NAT-PMP, UPnP, PCP, etc.  Packets
   directed by configured entries may or may not instantiate Dynamic
   NPIB entries for specific flows.



Townsley & Troan          Expires June 18, 2012                 [Page 6]


Internet-Draft           CE router requirements            December 2011


   Finally, the CE router also has a single IPv4 Routing Information
   Base (RIB), containing IPv4 routes learned from active LAN and WAN
   interfaces.  The RIB is only consulted for packets that fail to match
   an NPIB entry.  The RIB supports a classic IPv4 routing function,
   including use of the longest matching algorithm and preferences that
   may be assigned to each interface.  A RIB lookup ultimately resolves
   to an output interface which, in turn may have an NAPT function
   enabled.  If the output interface has an NAPT function enabled, it is
   responsible for programming the NPIB with a new Dynamic entry and
   translating the packet before sending.

4.2.  IPv4 Packet flow

   Ingress (from the Internet to the End-User) traffic may be received
   on any active interface at any time.  Egress (from the End-User to
   the Internet) traffic follows a set of rules within the CE in order
   to choose the proper WAN interface and associated NAPT function on
   that interface if present.

   Egress packets arriving at the CE trigger a lookup in the NPIB.  A
   successful match on a Dynamic entry in the NPIB provides all
   information necessary to translate and send a packet out the proper
   interface (e.g., no additional lookup in the RIB or elsewhere is
   required).  Packets which do not have a matching NPIB entry but match
   a Configured entry are treated similarly.  Packets which fail the
   NPIB lookup entirely are sent to the RIB.

   The RIB performs a classic IPv4 longest-matching routing lookup based
   on the destination address of the IPv4 packet.  If more than one
   interface is selected (which will be the case when more than one
   active WAN interface programs a default route in the RIB), then
   packets are sent via the interface with the highest configured
   preference.  If the preference is the same, packets may be load-
   balanced.  After selecting the proper output interface for the
   packet, the packet is either sent immediately or translated and sent
   if a NAPT function is enabled.  If NAPT function is enabled on that
   interface, it is responsible for programming the NPIB with a new
   Dynamic entry and translating the packet before sending.

4.3.  Example RIB Policy for IPv4 to IPv6 Transition

   Interface preferences in the RIB allow policy definition for choosing
   one type of interface over another.  Well-defined defaults which
   encourage transition to IPv6, less use of NAPT, and more distributed
   state may be defined.  The policy may be represented as a simple
   table which may be altered by the operator or user without any change
   to the CE packet forwarding implementation itself.




Townsley & Troan          Expires June 18, 2012                 [Page 7]


Internet-Draft           CE router requirements            December 2011


   In this example, an interface with a higher preference value is
   preferred over an interface with a lower preference value.  Weighted
   values are assigned according to the following basic principles for
   IPv4 interface selection:

   1.  IPv6 transport is preferred over any other.

   2.  Less address translation occurrences is preferred over more.
       [RFC5864][I-D.donley-nat444-impacts]

   3.  The closer the state is to the edge, the better.[RFC1958]

   In the case of DS-Lite and Native IPv4 configuration being present at
   the same time, DS-Lite would be preferred as it uses IPv6 transport
   and Native IPv4 does not.  When transitioning an active dual-stack
   network to DS-Lite, this means that when the DS-Lite IPv4 interface
   is made active, traffic that does not match an active entry in the
   NPIB table would be directed over the DS-Lite tunnel.  As entries in
   the NPIB table naturally time out, or if the Native interface is
   deactivated, the CGN within the DS-Lite AFTR takes over the NAPT
   state of the CE router.  In the event the DS-Lite tunnel fails, the
   Native IPv4 interface and local NAPT will naturally begin taking
   over.

   The above principles may be applied to other methods of IPv4
   transport as well.  The following table indicates a basic ordering
   (least to most preferred) for some of the known IPv4 extension and
   IPv6 transition mechanisms under development today.

           +-------------+----------+---------+--------+-------+
           | Mechanism   | #1 (100) | #2 (10) | #3 (1) | Total |
           +-------------+----------+---------+--------+-------+
           | CGN         |     1    |    1    |    1   |  111  |
           | SD-NAT      |     1    |    1    |    2   |  112  |
           | Native IPv4 |     1    |    2    |    2   |  122  |
           | MAP-T       |     2    |    1    |    2   |  212  |
           | DS-lite     |     2    |    2    |    1   |  221  |
           | MAP-E       |     2    |    2    |    2   |  222  |
           +-------------+----------+---------+--------+-------+

                      Table 1: IPv4 Preference Table


5.  Security Considerations


6.  Acknowledgements




Townsley & Troan          Expires June 18, 2012                 [Page 8]


Internet-Draft           CE router requirements            December 2011


7.  IANA Considerations

   This memo includes no request to IANA.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

8.2.  Informative References

   [I-D.donley-nat444-impacts]
              Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.
              Colorado, "Assessing the Impact of Carrier-Grade NAT on
              Network Applications", draft-donley-nat444-impacts-03
              (work in progress), November 2011.

   [I-D.ietf-v6ops-6204bis]
              Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", draft-ietf-v6ops-6204bis-04 (work in progress),
              December 2011.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5864]  Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864,



Townsley & Troan          Expires June 18, 2012                 [Page 9]


Internet-Draft           CE router requirements            December 2011


              April 2010.

   [RFC6204]  Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", RFC 6204, April 2011.


Appendix A.  Configuration-oriented multihoming

   This method attempts to actively avoid multihoming by forcing only a
   single configured WAN egress interface to be active at any time for a
   given IP version.  For this to work, one of the following assumptions
   must hold.

   a.  From the perspective of the CE router, the network supports only
       one type of interface for a given IP version, or

   b.  The CE router is configured in advance of any IP configuration to
       support only one type of interface for a given IP version, or

   c.  The CE router goes through an ordered set of configuration
       attempts in series, each requiring a timeout before moving to the
       next.  Transition-oriented changes after steady-state is reached
       will require "reboot" to go through the ordered process from
       scratch.

   d.  The CE router chooses one type of interface and shuts down all
       others based on a predetermined priority when more than one
       interface with the same IP version is configured.  This allows
       parallel configuration attempts and changes after reaching
       steady-state, but requires the CE router and network to manage a
       "flash cut" from one configured interface to the other and may be
       prone to tricky race-conditions.


Authors' Addresses

   Mark Townsley
   cisco


   Email: mark@townsley.net









Townsley & Troan          Expires June 18, 2012                [Page 10]


Internet-Draft           CE router requirements            December 2011


   Ole Troan
   cisco


   Email: ot@cisco.com














































Townsley & Troan          Expires June 18, 2012                [Page 11]


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