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]