idnits 2.17.1 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3068], [RFC3056]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4786 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-softwire-dual-stack-lite' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'I-D.mrw-nat66' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'I-D.tremblay-pt66ac' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'I-D.weil-shared-transition-space-request' is defined on line 431, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 == Outdated reference: A later version (-16) exists of draft-mrw-nat66-10 == Outdated reference: A later version (-15) exists of draft-weil-shared-transition-space-request-01 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6ops WG V. Kuarsingh, Ed. 3 Internet-Draft Rogers Communications 4 Intended status: Informational Y. Lee 5 Expires: September 15, 2011 Comcast 6 O. Vautrin 7 Juniper Networks 8 March 14, 2011 10 6to4 Provider Managed Tunnels 11 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 13 Abstract 15 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which 16 can help manage 6to4 [RFC3056] tunnels operating an an anycast 17 [RFC3068] configuration. The 6to4-PMT framework is intended to serve 18 as an option to operators to help improve the experience of 6to4 19 operation when conditions of the network may provide sub-optimal 20 performance or break normal 6to4 operation. 6to4-PMT provides a 21 stable provider prefix and forwarding environment by utilizing 22 existing 6to4 Relays with an added function of IPv6 Prefix 23 Translation. This operation may be particularly important in NAT444 24 infrastructures where a customer endpoint may be assigned a non- 25 RFC1918 address thus breaking the return path for anycast [RFC3068] 26 based 6to4 operation. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 15, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. 6to4 Provider Managed Tunnels . . . . . . . . . . . . . . . . 5 65 3.1. 6to4 Provider Managed Tunnel Model . . . . . . . . . . . . 5 66 3.2. Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Prefix Translation . . . . . . . . . . . . . . . . . . . . 6 68 3.4. Translation State . . . . . . . . . . . . . . . . . . . . 7 69 4. Deployment Considerations and Requirements . . . . . . . . . . 7 70 4.1. Customer Opt-out . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. ISP Shared Space Considerations . . . . . . . . . . . . . 8 72 4.3. End to End Transparency . . . . . . . . . . . . . . . . . 8 73 4.4. Routing Requirements . . . . . . . . . . . . . . . . . . . 9 74 4.5. Relay Deployments . . . . . . . . . . . . . . . . . . . . 9 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 6to4 [RFC3056] tunneling along with the anycast operation described 86 in [RFC3068] is widely deployed in modern Operating Systems and off 87 the shelf gateways sold throughout the retail and OEM channels. 88 Anycast [RFC3068] based 6to4 allows for tunneled IPv6 connectivity 89 through IPv4 clouds without explicit configuration of a relay 90 address. Since the overall system utilizes anycast forwarding in 91 both directions, flow paths are difficult to determine, tend to 92 follow separate paths in either direction, and often change based on 93 network conditions. The return path is normally uncontrolled by the 94 local operator and can contribute to poor performance for IPv6, and 95 can also act as a breakage point. Many of the challenges with 6to4 96 are described in [draft-carpenter-v6ops-6to4-teredo-advisor]. A 97 specific critical use case for problematic anycast 6to4 operation is 98 related to when the consumer endpoints are downstream from a 99 northbound NAT44 function when assigned non-RFC1918 addresses (common 100 future case in wireline networks and very common in wireless 101 networks). 103 Operators which are actively deploying IPv6 networks and operate 104 legacy IPv4 access environments may want to utilize the existing 6to4 105 behavior in customer site resident hardware and software as an 106 interim option to reach the IPv6 Internet in advance of being able to 107 offer full native IPv6. Operators may also need to address the 108 brokenness related to 6to4 operation originating from behind a 109 provider NAT function. 6to4-PMT offers a operator the opportunity to 110 utilize IPv6 Prefix Translation to enable deterministic and an 111 unbroken path to and from the Internet for IPv6 based traffic sourced 112 originally from these 6to4 customer endpoints. 114 6to4-PMT translates the prefix portion of the IPv6 address from the 115 6to4 generated prefix to a provider assigned prefix which is used to 116 represent the source. This translation will then provide a stable 117 forward and return path for the 6to4 traffic by allowing the existing 118 IPv6 routing and policy environment to control the traffic. 6to4-PMT 119 is primarily intended to be used in a stateless manner to maintain 120 many of the elements inherent in normal 6to4 operation. 121 Alternatively, 6to4-PMT can be used in a stateful translation mode 122 should the operator choose this option. 124 2. Motivation 126 Many operators endeavor to deploy IPv6 as soon as possible so as to 127 ensure uninterrupted connectivity to all Internet applications and 128 content through the IPv4 to IPv6 transition process. The IPv6 129 preparations within these organizations are often faced with both 130 financial challenges and timing issues related to deploying IPv6 to 131 the network edge and related transition technologies. Many of the 132 new technologies addressing IPv4 to IPv6 transition will require the 133 replacement of the customer CPE to support technologies like 6RD 134 [RFC5969], Dual Stack Lite [draft-ietf-softwire-dual-stack-lite] and 135 Native Dual Stack. 137 Operators face a number of challenges related to home equipment 138 replacement. Operator initiated replacement of this equipment will 139 take time due to the nature of mass equipment refresh programs or may 140 require the consumer to replace their own gear. Replacing consumer 141 owned and operated equipment, compounded by the fact that there is 142 also a general unawareness of what IPv6 is, also adds the the 143 challenges faced by operators. It is also important to note that 144 6to4 is found in much of the equipment in networks today which do not 145 as of yet, or will not, support 6RD and/or Native Dual Stack. 147 Operators may still be motivated to provide a form of IPv6 148 connectivity to customers and would want to mitigate potential issues 149 related to IPv6-only deployments elsewhere on the Internet. 150 Operators also need to mitigate issues related to the fact that 6to4 151 operation often is on by default and may be subject to erroneous 152 behavior. The undesired behavior may be related to the use of non- 153 RFC1918 addresses on CPE equipment which operate behind large NATs, 154 or other conditions as described in a general advisory as laid out in 155 [draft-carpenter-v6ops-6to4-teredo-advisory]. 157 6to4-PMT allows a operator to help mitigate such challenges by 158 leveraging the existing 6to4 deployment base, while maintaining 159 operator control of access to the IPv6 Internet. It is intended for 160 use when better options, such as 6RD or native IPv6, are not yet 161 viable. One of key objectives of 6to4-PMT is to also help reverse 162 the negative impacts of 6to4 in NAT444 environments. The 6to4-PMT 163 operation can also be used immediately and the default parameters are 164 often enough to allow it to operate in a 6to4-PMT environment. Once 165 native IPv6 is available to the endpoint, the 6to4-PMT operation is 166 no longer needed and will cease to be used based on correct address 167 selection behaviors in end hosts [RFC3484]. 169 6to4-PMT thus helps operators remove the impact of 6to4 in NAT444 170 environments, deals with the fact that 6to4 is often on by default, 171 allows access to IPv6-only endpoints from IPv4-only addressed 172 equipment and provides relief from may challenges related to mis- 173 configuations in other networks. Due to the simple nature of 6to4- 174 PMT, it can also be implemented in a cost effective and simple manner 175 allowing operators to concentrate their energy on deploying native 176 IPv6. 178 3. 6to4 Provider Managed Tunnels 180 3.1. 6to4 Provider Managed Tunnel Model 182 The 6to4 managed tunnel model behaves like a standard 6to4 service 183 between the customer IPv6 host or gateway and the 6ot4-PMT Relay 184 (within the provider domain). The 6to4-PMT Relay shares properties 185 with 6RD [RFC5969] by decapsulating and forwarding embedded IPv6 186 flows, within an IPv4 packet, to the IPv6 Internet. The model 187 provides an additional function which translates the source 6to4 188 prefix to a provider assigned prefix which is not found in 6RD 189 [RFC5969] or traditional 6to4 operation. 191 The 6to4-PMT Relay is intended to provide a stateless (or stateful) 192 mapping of the 6to4 prefix to a provider supplied prefix by mapping 193 the embedded IPv4 address in the 6to4 prefix to the provider prefix. 195 | 6to4-PMT Operation | 197 +-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+ 198 | CPE |-------------|6to4 BR |--| PT66 |--------- |Host| 199 +-----+ IPv4 +--------+ +------+ Provider +----+ 200 Network Prefix 201 Unified or Separate 202 Functions/Platforms 204 Figure 1: 6to4-PMT Functional Model 206 This mode of operation is seen as beneficial when compared to broken 207 6to4 paths and or environments where 6to4 operation may be functional 208 but highly degraded. 210 3.2. Traffic Flow 212 Traffic in the 6to4-PMT model is intended to be controlled by the 213 operator's IPv6 peering operations. Egress traffic is managed 214 through outgoing routing policy, and incoming traffic is influenced 215 by the operator assigned prefix advertisements. 217 The routing model is as predictable as native IPv6 traffic and legacy 218 IPv4 based traffic. Figure 2 provides a view of the routing topology 219 needed to support this relay environment. The diagram references 220 PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32. 222 | 6to4 IPv4 Path | Native IPv6 Path | 223 ----------- ----------- ------------- 224 / IPv4 Net \ / IPv6 Net \ / IPv6 Internet \ 225 +------+ +--------+ +-------+ +---------+ 226 | CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST| 227 +------+ +--------+ +-------+ +---------+ 228 \ / \ / \ / 229 ---------- ------------ -------------- 231 IPv4 6to4 IPv6 Provider IPv6 Prefix 232 Anycast Prefix Advertisement 234 Figure 2: 6to4-PMT Flow Model 236 Traffic between two 6to4 enabled devices would use the IPv4 path for 237 communication according to RFC3056. 6to4-PMT is intended to be 238 deployed in conjunction with the 6to4 relay function in an attempt to 239 help simplify it's deployment. The model can also provide the 240 ability for an operator to forward both 6to4-PMT (translated) and 241 normal 6to4 flows (untranslated) simultaneously based on policy. 243 3.3. Prefix Translation 245 The IPv6 Prefix Translation is a key part of the system as a whole. 246 The 6to4-PMT framework is a combination of two concepts: 6to4 247 [RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation has 248 some similarities to concepts discussed in [draft-mrw-nat66]. The 249 only change in this particular case is that the provider would build 250 specific rules on the translator to map the 6to4 prefix to an 251 appropriate provider assigned prefix. 253 The provider can use any prefix mapping strategy they so choose, but 254 the simpler the better. Simple direct bit mapping can be used such 255 as in Figure 2, or more advanced forms of translation can be used to 256 achieve higher address compression. 258 Figure 2 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a 259 provider globally unique prefix (2001:db8::/32). With this simple 260 form of translation, there is support for only one Subnet-ID per 261 provider assigned prefix. In characterization of deployed OSs and 262 gateways, a subnet-id of "0000" is the most common default case. 264 Pre-Relayed Packet [Provider Access Network Side] 266 0 16 32 48 64 80 96 112 128 Bits 267 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 268 2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx 269 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 270 | | | | | | 271 ---- ---- | | | | 272 | | | | | | 273 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 274 2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx 275 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 277 Post-Relayed Packet [Internet Side] 279 Figure 3: 6to4-PMT Prefix Mapping 281 Additional prefix compression techniques can be used such as those 282 described in [draft-tremblay-pt66ac]. These techniques would allow 283 for a more flexible implementation potentially supporting more 284 Subnet-IDs per provider prefix. 286 3.4. Translation State 288 It is preferred that the overall system use deterministic prefix 289 translation mappings such that stateless operation can be 290 implemented. This allows the provider to place N number of relays 291 within the network without the need to manage translation state. 293 If stateful operation is chosen, the operation would need to validate 294 state and routing requirements particular to that type of deployment. 295 The full body of considerations for this type of deployment are not 296 within this scope of this document. 298 4. Deployment Considerations and Requirements 300 4.1. Customer Opt-out 302 A provider enabling this function should provide a method to allow 303 customers to opt-out of such a service should the customer choose to 304 maintain normal 6to4 operation irrespective of degraded performance. 305 In cases where the customer is behind a NAT44 device (Provider CGN), 306 the customer would not be advised to opt-out and can also be assisted 307 to turn off 6to4. 309 Since the 6to4-PMT system is targeted at customers who are relatively 310 unaware of IPv6 and IPv4, and normally run network equipment with a 311 default configuration, an opt-out strategy is recommended. This 312 method provides the 6to4-PMT operation for non-IPv6 savvy customers 313 whose equipment may turn on 6to4 automatically and allows savvy 314 customers to easily configure they way around the PMT function. 316 Capable customers can also disable anycast based 6to4 entirely and 317 use traditional 6to4 or other tunneling mechanisms if they are so 318 inclined. This is not considered the normal case, and most endpoints 319 with auto-6to4 operation will be subject to 6to4-PMT operation since 320 most users are unaware of it's existence. 6to4-PMT is targeted as an 321 option for stable IPv6 connectivity for average consumers. 323 4.2. ISP Shared Space Considerations 325 6to4-PMT operation can also be used to mitigate a known problem with 326 6to4 when ISP Shared Space 327 [draft-weil-shared-transition-space-request-01] or public but non- 328 routed IPv4 space is used. Public but un-routed address space would 329 cause many deployed OSs and network equipment to potentially auto- 330 enable 6to4 operation even without a valid return path (such as 331 behind NAT44 provider function). Operators' desire to use public but 332 un-routed IP space is considered highly likely based on points made 333 in [draft-weil-shared-transition-space-request] and in reports such 334 as [wide-tr-kato-as112-rep-01]. 336 Such hosts, in normal cases, would send 6to4 traffic to the IPv6 337 Internet via the IPv4 anycast relay, which would in fact provide 338 broken IPv6 connectivity since the return path is based on an address 339 that is not routed or assigned to the source Network. The use of 340 6to4-PMT would help reverse these effects by translating the 6to4 341 prefix to a provided assigned prefix, masking this automatic and 342 undesired behavior. 344 4.3. End to End Transparency 346 6to4-PMT mode operation removes the traditional end to end 347 transparency of 6to4. Remote hosts would connect to a translated 348 IPv6 address versus the original 6to4 based prefix. This can be seen 349 as a disadvantage of the 6to4-PMT system. This lack of transparency 350 should also be contrasted with the normal operating state of 6to4 351 which provides uncontrolled and often high latency prone 352 connectivity. The lack of transparency is however a better form of 353 operation when extreme poor performance, broken IPv6 connectivity, or 354 no IPv6 connectivity is considered as the alternative. 356 4.4. Routing Requirements 358 The provider would need to advertise the anycast IP range within the 359 IPv4 routing environment (service customers of interest) to attract 360 the 6to4 upstream traffic. To control this environment and make sure 361 all northbound traffic lands on a provider BR, the operator may 362 filter the anycast range from being advertised from customer 363 endpoints. 365 The provider would not be able to control route advertisements inside 366 the customer domain, but this use case is out of this document's 367 scope. It is likely in this case the end network/customer 368 understands IPv6 operation and is maintaining their own environment. 370 The provider would also likely want to advertise the 2002::/16 range 371 within their own network to help bridge within their own network 372 (Native IPv6 to 6to4-IPv6 based endpoint). 374 4.5. Relay Deployments 376 The 6to4-PMT function can be deployed onto existing 6to4 relays (if 377 desired) to help minimize network complexity. If used on Linux based 378 relays, 6to4-PMT can be a low cost add-on which can help align normal 379 6to4 and 6to4-PMT operation. The only additional considerations 380 beyond normal 6to4 relay operation would include the need to route 381 specific IPv6 address ranges to the IPv6 side interface to manage 382 return traffic. 384 5. IANA Considerations 386 No IANA considerations are defined at this time. 388 6. Security Considerations 390 6to4-PMT operation would be subject to the same security concerns as 391 normal 6to4 operation and with the operation of tunnels. 393 7. Acknowledgements 395 Thanks to the following people for their textual contributions and/or 396 guidance on 6to4 deployment considerations: Dan Wing, Wes George, 397 Scott Beuker, JF Tremblay, John Brzozowski, and Chris Donley 399 Additional thanks to the following for assisting with the coding and 400 testing of 6to4-PMT: Marc Blanchet, John Cianfarani, and Nik Lavorato 402 8. References 404 8.1. Normative References 406 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 407 via IPv4 Clouds", RFC 3056, February 2001. 409 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 410 RFC 3068, June 2001. 412 8.2. Informative References 414 [I-D.ietf-softwire-dual-stack-lite] 415 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 416 Stack Lite Broadband Deployments Following IPv4 417 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 418 in progress), March 2011. 420 [I-D.mrw-nat66] 421 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 422 Translation", draft-mrw-nat66-10 (work in progress), 423 March 2011. 425 [I-D.tremblay-pt66ac] 426 Tremblay, J. and S. Beuker, "Addressing bit compression 427 for stateless IPv6 prefix translation", 428 draft-tremblay-pt66ac-00 (work in progress), 429 November 2010. 431 [I-D.weil-shared-transition-space-request] 432 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 433 M. Azinger, "IANA Reserved IPv4 Prefix for Shared 434 Transition Space", 435 draft-weil-shared-transition-space-request-01 (work in 436 progress), November 2010. 438 [RFC3484] Draves, R., "Default Address Selection for Internet 439 Protocol version 6 (IPv6)", RFC 3484, February 2003. 441 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 442 Infrastructures (6rd) -- Protocol Specification", 443 RFC 5969, August 2010. 445 Authors' Addresses 447 Victor Kuarsingh (editor) 448 Rogers Communications 449 8200 Dixie Road 450 Brampton, Ontario L6T 0C1 451 Canada 453 Email: victor.kuarsingh@rci.rogers.com 454 URI: http://www.rogers.com 456 Yiu L. Lee 457 Comcast 458 One Comcast Center 459 Philadelphia, PA 19103 460 U.S.A. 462 Email: yiu_lee@cable.comcast.com 463 URI: http://www.comcast.com 465 Olivier Vautrin 466 Juniper Networks 467 1194 N Mathilda Avenue 468 Sunnyvale, CA 94089 469 U.S.A. 471 Email: olivier@juniper.net 472 URI: http://www.juniper.net