idnits 2.17.1 draft-townsley-troan-ipv6-ce-transitioning-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2011) is 4512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2131' is defined on line 363, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-03 == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-6204bis-04 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Townsley 3 Internet-Draft O. Troan 4 Intended status: Informational cisco 5 Expires: June 18, 2012 December 16, 2011 7 Basic Requirements for Customer Edge Routers - multihoming and 8 transition 9 draft-townsley-troan-ipv6-ce-transitioning-02 11 Abstract 13 This document specifies general IPv6 multihoming and specific 6rd 14 transitioning requirements for an IPv6 Customer Edge (CE) router. It 15 also provides an illustrative implementation model for IPv4 16 multihoming in order to support shared IPv4 transition mechanisms 17 that utilize IPv6 as a transport for IPv4. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 18, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. IPv6 MultiPrefix Multihoming . . . . . . . . . . . . . . . . . 4 57 3.1. Multihoming requirements . . . . . . . . . . . . . . . . . 5 58 3.2. 6rd Sunsetting Requirements . . . . . . . . . . . . . . . 5 59 4. IPv4 NAT Multihoming . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. IPv4 Multihoming Data Structures . . . . . . . . . . . . . 6 61 4.2. IPv4 Packet flow . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Example RIB Policy for IPv4 to IPv6 Transition . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Appendix A. Configuration-oriented multihoming . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The CE requirements specified in RFC 6204 are based on a fundamental 75 assumption that a CE router has a single active WAN interface for 76 forwarding IPv4 and IPv6 traffic towards an ISP. The operation of 77 IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native 78 together, forces us to reconsider this basic assumption. 80 There are three possible steady-state combinations of "native" and 81 "virtual" (tunneled) dual-stack service models (an IPv6-only service 82 model, while imperative for finalizing the transition to IPv6, is 83 currently out of scope in [RFC6204] and [I-D.ietf-v6ops-6204bis]) 84 that do not break the fundamental assumption of having no more than 85 one WAN interface per IP version. 87 1. One Native IPv4 and IPv6 interface (Classic Dual-Stack) 89 2. One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires 90 Hub and Spoke via L2TP, TSP, etc) 92 3. One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, 93 etc) 95 For (1), IPv4 and IPv6 each share a single WAN interface, so there is 96 no problem when enabling one vs. the other. 98 For (2), when enabling tunneled IPv6 on an existing IPv4-only network 99 there is no significant change in the basic model as each IP version 100 still has its own distinct single WAN interface. Multihoming issues 101 arise when enabling native IPv6 alongside tunneled IPv6 (needed for 102 "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces 103 at the same time. 105 For (3) there similarly is no problem when enabling tunneled IPv4 on 106 an existing IPv6-only network, and we understand that there are 107 greenfield deployments just like this happening. Multihoming issues 108 arise when enabling tunneled IPv4 on a network that has native IPv4 109 available at the same time. 111 The multihoming model described in this document assumes the operator 112 or user can configure any WAN interface type at any time. The CE 113 follows forwarding rules defined in this document in order to ensure 114 packets make it out the right interface on WAN egress, and liberally 115 accepts packets on WAN ingress. This is "classic multihoming" and 116 should work for any order of planned incremental transition steps, as 117 well as failover and/or transient situations. 119 While this authors of this document believe that the forward-oriented 120 model, there is another approach which we identify as "Configuration- 121 oriented" and describe briefly in Appendix A. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Terminology 131 SRIB A Source Address Routing Information Base 132 containing an entry per delegated prefix. 133 Each entry points to one or more 134 Destination Address Routing Tables (DRIB). 136 DRIB A Destination Address Routing Information 137 Base used for destination address longest 138 matching lookups. Each entry points to one 139 or more next-hops. 141 NPIB Network Address and Port Translation (NAPT) 142 Information Base used binding "flows" to an 143 egress WAN interface. 145 NPIB entry The address and port mapping state 146 [RFC4787] at the NAT necessary for network 147 address and port translation. 149 3. IPv6 MultiPrefix Multihoming 151 A multihomed, multiprefix, IPv6 CE router has multiple WAN interfaces 152 connecting it to one or more Service Providers. The interfaces may 153 be "real" or "virtual" in the case of tunneling technology such as 154 6rd [RFC5969]. The CE router receives one or more delegated 155 prefixes, each associated with one or more WAN interfaces. The CE 156 router has a single SRIB, and one DRIB associated with each WAN 157 Interface. 159 WAN interfaces are used to send Ingress traffic from the Internet to 160 the End-User, and Egress traffic from the End-User network to the 161 Internet. Ingress traffic may be received on any active interface at 162 any time. Egress traffic follows a set of rules within the CE in 163 order to choose the proper WAN interface. This is important not only 164 in order to choose the best path, but also because the networks that 165 the CE are connected to typically employ source address verification 166 mechanisms. 168 Packets arriving at the CE have an IPv6 source address chosen by the 169 host [RFC3484]. The SRIB contains an entry for each delegated prefix 170 with a pointer to one or more DRIBs. A longest matching lookup based 171 upon the source address of each arriving packet is performed within 172 the SRIB to determine the DRIB(s). The egress WAN interface to use 173 for sending a packet is then chosen by performing a longest matching 174 lookup within the resulting DRIB(s). 176 3.1. Multihoming requirements 178 MH-1: An IPv6 CE router MUST create a separate DRIB for each WAN 179 interface (real or virtual) and installs a route for the 180 associated delegated prefix, default route and more specific 181 routes. 183 MH-2: An IPv6 CE router MUST create an SRIB containing entries for 184 associated delegated prefixes. Each entry points to one or 185 more DRIBs. An entry points to multiple DRIBs only in the 186 case where an identical delegated prefix is associated with 187 multiple WAN interfaces. 189 MH-3: When forwarding a packet from a LAN interface, the CE router 190 MUST do a longest matching lookup based on the packet's Source 191 Address in the SRIB. A Destination Address lookup is then 192 performed in the corresponding DRIB or DRIBs. When there are 193 multiple equal matches, the route with the lowest cost is 194 chosen. 196 3.2. 6rd Sunsetting Requirements 198 6RDS-1: Multihoming as defined in section Section 3 MUST be 199 supported, allowing 6rd and native packets to be sent and 200 received as long as 6rd configuration is provided by the 201 ISP. 203 6RDS-2: By default, the 6rd virtual interface MUST be assigned a 204 higher routing cost than a native IPv6 interface. 206 6RDS-3: The IPv6 CE router MUST support that 6rd and native IPv6 207 delegated prefixes are identical or different, and operate 208 as defined in the multihoming section. 210 4. IPv4 NAT Multihoming 212 This section describes a general implementation model used to 213 illustrate CE IPv4 multihoming, alongside specifics for using the 214 model to support IPv6 transition technologies aimed at delivering 215 IPv4 within an IPv6 transport (e.g., DS-Lite). 217 A multihomed IPv4 CE router has multiple "physical" or "virtual" WAN 218 interfaces connecting it to one or more Service Providers. WAN 219 interfaces are used to send Ingress traffic from the Internet to the 220 End-User, and Egress traffic from the End-User network to the 221 Internet. Each WAN interface may be configured with a single public 222 IPv4 address, private IPv4 address [RFC1918], a shared IPv4 address 223 [A+P], or no IPv4 address at all. 225 An IPv4 CE router WAN interface is often configured in the same 226 manner as a single host, i.e., with a single 32-bit IPv4 address. A 227 CE router NAPT function, in turn, allows more than one device within 228 the end-user network to appear as a single host with a single IPv4 229 address facing the ISP network. The CE router NAPT function is 230 responsible for rewriting IPv4 headers with the address assigned to 231 the associated WAN interface with the expectation that return traffic 232 will be sent back to that address. 234 IPv4 WAN interfaces which are not configured with an IPv4 address by 235 the ISP (e.g., DS-Lite, L2-aware NAT), bypass the translation 236 function of the NAPT when forwarding traffic. In this case, the 237 ISP's centralized NAPT function is responsible for rewriting IPv4 238 headers with a source address which ensures return traffic will reach 239 the proper NAPT binding within the ISP. 241 4.1. IPv4 Multihoming Data Structures 243 The CE router has a single NAPT Information Base (NPIB) which 244 consists of Dynamic and Configured entries. A WAN interface 245 provisioned with an IPv4 address has an associated NAPT function 246 which examines packet flow and programs the NPIB with Dynamic entries 247 as they are identified. For example, an active TCP session on the CE 248 correlates to a single Dynamic entry within the NPIB. A Dynamic 249 entry in the NPIB table unambiguously identifies packets that are 250 associated with it when an NPIB Lookup is performed. 252 Configured NPIB entries allow for rules to be specified which direct 253 traffic in a specific manner. Unlike Dynamic entries, Configured 254 entries allow for "wildcards", and may be end-user configured or 255 configured by a protocol such as NAT-PMP, UPnP, PCP, etc. Packets 256 directed by configured entries may or may not instantiate Dynamic 257 NPIB entries for specific flows. 259 Finally, the CE router also has a single IPv4 Routing Information 260 Base (RIB), containing IPv4 routes learned from active LAN and WAN 261 interfaces. The RIB is only consulted for packets that fail to match 262 an NPIB entry. The RIB supports a classic IPv4 routing function, 263 including use of the longest matching algorithm and preferences that 264 may be assigned to each interface. A RIB lookup ultimately resolves 265 to an output interface which, in turn may have an NAPT function 266 enabled. If the output interface has an NAPT function enabled, it is 267 responsible for programming the NPIB with a new Dynamic entry and 268 translating the packet before sending. 270 4.2. IPv4 Packet flow 272 Ingress (from the Internet to the End-User) traffic may be received 273 on any active interface at any time. Egress (from the End-User to 274 the Internet) traffic follows a set of rules within the CE in order 275 to choose the proper WAN interface and associated NAPT function on 276 that interface if present. 278 Egress packets arriving at the CE trigger a lookup in the NPIB. A 279 successful match on a Dynamic entry in the NPIB provides all 280 information necessary to translate and send a packet out the proper 281 interface (e.g., no additional lookup in the RIB or elsewhere is 282 required). Packets which do not have a matching NPIB entry but match 283 a Configured entry are treated similarly. Packets which fail the 284 NPIB lookup entirely are sent to the RIB. 286 The RIB performs a classic IPv4 longest-matching routing lookup based 287 on the destination address of the IPv4 packet. If more than one 288 interface is selected (which will be the case when more than one 289 active WAN interface programs a default route in the RIB), then 290 packets are sent via the interface with the highest configured 291 preference. If the preference is the same, packets may be load- 292 balanced. After selecting the proper output interface for the 293 packet, the packet is either sent immediately or translated and sent 294 if a NAPT function is enabled. If NAPT function is enabled on that 295 interface, it is responsible for programming the NPIB with a new 296 Dynamic entry and translating the packet before sending. 298 4.3. Example RIB Policy for IPv4 to IPv6 Transition 300 Interface preferences in the RIB allow policy definition for choosing 301 one type of interface over another. Well-defined defaults which 302 encourage transition to IPv6, less use of NAPT, and more distributed 303 state may be defined. The policy may be represented as a simple 304 table which may be altered by the operator or user without any change 305 to the CE packet forwarding implementation itself. 307 In this example, an interface with a higher preference value is 308 preferred over an interface with a lower preference value. Weighted 309 values are assigned according to the following basic principles for 310 IPv4 interface selection: 312 1. IPv6 transport is preferred over any other. 314 2. Less address translation occurrences is preferred over more. 315 [RFC5864][I-D.donley-nat444-impacts] 317 3. The closer the state is to the edge, the better.[RFC1958] 319 In the case of DS-Lite and Native IPv4 configuration being present at 320 the same time, DS-Lite would be preferred as it uses IPv6 transport 321 and Native IPv4 does not. When transitioning an active dual-stack 322 network to DS-Lite, this means that when the DS-Lite IPv4 interface 323 is made active, traffic that does not match an active entry in the 324 NPIB table would be directed over the DS-Lite tunnel. As entries in 325 the NPIB table naturally time out, or if the Native interface is 326 deactivated, the CGN within the DS-Lite AFTR takes over the NAPT 327 state of the CE router. In the event the DS-Lite tunnel fails, the 328 Native IPv4 interface and local NAPT will naturally begin taking 329 over. 331 The above principles may be applied to other methods of IPv4 332 transport as well. The following table indicates a basic ordering 333 (least to most preferred) for some of the known IPv4 extension and 334 IPv6 transition mechanisms under development today. 336 +-------------+----------+---------+--------+-------+ 337 | Mechanism | #1 (100) | #2 (10) | #3 (1) | Total | 338 +-------------+----------+---------+--------+-------+ 339 | CGN | 1 | 1 | 1 | 111 | 340 | SD-NAT | 1 | 1 | 2 | 112 | 341 | Native IPv4 | 1 | 2 | 2 | 122 | 342 | MAP-T | 2 | 1 | 2 | 212 | 343 | DS-lite | 2 | 2 | 1 | 221 | 344 | MAP-E | 2 | 2 | 2 | 222 | 345 +-------------+----------+---------+--------+-------+ 347 Table 1: IPv4 Preference Table 349 5. Security Considerations 351 6. Acknowledgements 352 7. IANA Considerations 354 This memo includes no request to IANA. 356 8. References 358 8.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 364 RFC 2131, March 1997. 366 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 367 Infrastructures (6rd) -- Protocol Specification", 368 RFC 5969, August 2010. 370 8.2. Informative References 372 [I-D.donley-nat444-impacts] 373 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 374 Colorado, "Assessing the Impact of Carrier-Grade NAT on 375 Network Applications", draft-donley-nat444-impacts-03 376 (work in progress), November 2011. 378 [I-D.ietf-v6ops-6204bis] 379 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 380 Troan, "Basic Requirements for IPv6 Customer Edge 381 Routers", draft-ietf-v6ops-6204bis-04 (work in progress), 382 December 2011. 384 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 385 E. Lear, "Address Allocation for Private Internets", 386 BCP 5, RFC 1918, February 1996. 388 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 389 RFC 1958, June 1996. 391 [RFC3484] Draves, R., "Default Address Selection for Internet 392 Protocol version 6 (IPv6)", RFC 3484, February 2003. 394 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 395 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 396 RFC 4787, January 2007. 398 [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, 399 April 2010. 401 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 402 Troan, "Basic Requirements for IPv6 Customer Edge 403 Routers", RFC 6204, April 2011. 405 Appendix A. Configuration-oriented multihoming 407 This method attempts to actively avoid multihoming by forcing only a 408 single configured WAN egress interface to be active at any time for a 409 given IP version. For this to work, one of the following assumptions 410 must hold. 412 a. From the perspective of the CE router, the network supports only 413 one type of interface for a given IP version, or 415 b. The CE router is configured in advance of any IP configuration to 416 support only one type of interface for a given IP version, or 418 c. The CE router goes through an ordered set of configuration 419 attempts in series, each requiring a timeout before moving to the 420 next. Transition-oriented changes after steady-state is reached 421 will require "reboot" to go through the ordered process from 422 scratch. 424 d. The CE router chooses one type of interface and shuts down all 425 others based on a predetermined priority when more than one 426 interface with the same IP version is configured. This allows 427 parallel configuration attempts and changes after reaching 428 steady-state, but requires the CE router and network to manage a 429 "flash cut" from one configured interface to the other and may be 430 prone to tricky race-conditions. 432 Authors' Addresses 434 Mark Townsley 435 cisco 437 Email: mark@townsley.net 438 Ole Troan 439 cisco 441 Email: ot@cisco.com