idnits 2.17.1 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03.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 (September 13, 2011) is 4609 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.bdgks-arin-shared-transition-space' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'I-D.weil-shared-transition-space-request' is defined on line 418, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) == Outdated reference: A later version (-03) exists of draft-bdgks-arin-shared-transition-space-02 == Outdated reference: A later version (-15) exists of draft-weil-shared-transition-space-request-04 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops V. Kuarsingh, Ed. 3 Internet-Draft Rogers Communications 4 Intended status: Informational Y. Lee 5 Expires: March 16, 2012 Comcast 6 O. Vautrin 7 Juniper Networks 8 September 13, 2011 10 6to4 Provider Managed Tunnels 11 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03 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 March 16, 2012. 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. Shared Transition Space Considerations . . . . . . . . . . 8 72 4.3. End to End Transparency . . . . . . . . . . . . . . . . . 8 73 4.4. Routing Requirements . . . . . . . . . . . . . . . . . . . 8 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] tunnelling 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 tunnelled 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 [RFC6343]. A specific critical use case for 97 problematic anycast 6to4 operation is related to when the consumer 98 endpoints are downstream from a northbound NAT44 function when 99 assigned non-RFC1918 addresses (common future case in wireline 100 networks and very common in wireless networks). 102 Operators which are actively deploying IPv6 networks and operate 103 legacy IPv4 access environments may want to utilize the existing 6to4 104 behaviour in customer site resident hardware and software as an 105 interim option to reach the IPv6 Internet in advance of being able to 106 offer full native IPv6. Operators may also need to address the 107 brokenness related to 6to4 operation originating from behind a 108 provider NAT function. 6to4-PMT offers an operator the opportunity to 109 utilize IPv6 Prefix Translation to enable deterministic traffic flow 110 and an unbroken path to and from the Internet for IPv6 based traffic 111 sourced originally from these 6to4 customer endpoints. 113 6to4-PMT translates the prefix portion of the IPv6 address from the 114 6to4 generated prefix to a provider assigned prefix which is used to 115 represent the source. This translation will then provide a stable 116 forward and return path for the 6to4 traffic by allowing the existing 117 IPv6 routing and policy environment to control the traffic. 6to4-PMT 118 is primarily intended to be used in a stateless manner to maintain 119 many of the elements inherent in normal 6to4 operation. 120 Alternatively, 6to4-PMT can be used in a stateful translation mode 121 should the operator choose this option. 123 2. Motivation 125 Many operators endeavour to deploy IPv6 as soon as possible so as to 126 ensure uninterrupted connectivity to all Internet applications and 127 content through the IPv4 to IPv6 transition process. The IPv6 128 preparations within these organizations are often faced with both 129 financial challenges and timing issues related to deploying IPv6 to 130 the network edge and related transition technologies. Many of the 131 new technologies addressing IPv4 to IPv6 transition will require the 132 replacement of the customer CPE to support technologies like 6RD 133 [RFC5969], Dual-Stack Lite [RFC6333] and Native Dual Stack. 135 Operators face a number of challenges related to home equipment 136 replacement. Operator initiated replacement of this equipment will 137 take time due to the nature of mass equipment refresh programs or may 138 require the consumer to replace their own gear. Replacing consumer 139 owned and operated equipment, compounded by the fact that there is 140 also a general unawareness of what IPv6 is, also adds to the 141 challenges faced by operators. It is also important to note that 142 6to4 is found in much of the equipment found in networks today which 143 do not as of yet, or will not, support 6RD and/or Native IPv6. 145 Operators may still be motivated to provide a form of IPv6 146 connectivity to customers and would want to mitigate potential issues 147 related to IPv6-only deployments elsewhere on the Internet. 148 Operators also need to mitigate issues related to the fact that 6to4 149 operation often is on by default and may be subject to erroneous 150 behaviour. The undesired behaviour may be related to the use of non- 151 RFC1918 addresses on CPE equipment which operate behind large NATs, 152 or other conditions as described in a general advisory as laid out in 153 [RFC6343]. 155 6to4-PMT allows an operator to help mitigate such challenges by 156 leveraging the existing 6to4 deployment base, while maintaining 157 operator control of access to the IPv6 Internet. It is intended for 158 use when better options, such as 6RD or Native IPv6, are not yet 159 viable. One of key objectives of 6to4-PMT is to also help reverse 160 the negative impacts of 6to4 in NAT444 environments. The 6to4-PMT 161 operation can also be used immediately and the default parameters are 162 often enough to allow it to operate in a 6to4-PMT environment. Once 163 native IPv6 is available to the endpoint, the 6to4-PMT operation is 164 no longer needed and will cease to be used based on correct address 165 selection behaviours in end hosts [RFC3484]. 167 6to4-PMT thus helps operators remove the impact of 6to4 in NAT444 168 environments, deals with the fact that 6to4 is often on by default, 169 allows access to IPv6-only endpoints from IPv4-only addressed 170 equipment and provides relief from many challenges related to mis- 171 configuations in other networks. Due to the simple nature of 6to4- 172 PMT, it can also be implemented in a cost effective and simple manner 173 allowing operators to concentrate their energy on deploying Native 174 IPv6. 176 3. 6to4 Provider Managed Tunnels 178 3.1. 6to4 Provider Managed Tunnel Model 180 The 6to4 managed tunnel model behaves like a standard 6to4 service 181 between the customer IPv6 host or gateway and the 6ot4-PMT Relay 182 (within the provider domain). The 6to4-PMT Relay shares properties 183 with 6RD [RFC5969] by decapsulating and forwarding encapsulated IPv6 184 flows within an IPv4 packet, to the IPv6 Internet. The model 185 provides an additional function which translates the source 6to4 186 prefix to a provider assigned prefix which is not found in 6RD 187 [RFC5969] or traditional 6to4 operation. 189 The 6to4-PMT Relay is intended to provide a stateless (or stateful) 190 mapping of the 6to4 prefix to a provider supplied prefix. 192 | 6to4-PMT Operation | 194 +-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+ 195 | CPE |-------------|6to4 BR |--| PT66 |--------- |Host| 196 +-----+ IPv4 +--------+ +------+ Provider +----+ 197 Network Prefix 198 Unified or Separate 199 Functions/Platforms 201 Figure 1: 6to4-PMT Functional Model 203 This mode of operation is seen as beneficial when compared to broken 204 6to4 paths and or environments where 6to4 operation may be functional 205 but highly degraded. 207 3.2. Traffic Flow 209 Traffic in the 6to4-PMT model is intended to be controlled by the 210 operator's IPv6 peering operations. Egress traffic is managed 211 through outgoing routing policy, and incoming traffic is influenced 212 by the operator assigned prefix advertisements. 214 The routing model is as predictable as native IPv6 traffic and legacy 215 IPv4 based traffic. Figure 2 provides a view of the routing topology 216 needed to support this relay environment. The diagram references 217 PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32. 219 | 6to4 IPv4 Path | Native IPv6 Path | 220 ----------- ----------- ------------- 221 / IPv4 Net \ / IPv6 Net \ / IPv6 Internet \ 222 +------+ +--------+ +-------+ +---------+ 223 | CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST| 224 +------+ +--------+ +-------+ +---------+ 225 \ / \ / \ / 226 ---------- ------------ -------------- 228 IPv4 6to4 IPv6 Provider IPv6 Prefix 229 Anycast Prefix Propagation 231 Figure 2: 6to4-PMT Flow Model 233 Traffic between two 6to4 enabled devices would use the IPv4 path for 234 communication according to RFC3056. 6to4-PMT is intended to be 235 deployed in conjunction with the 6to4 relay function in an attempt to 236 help simplify it's deployment. The model can also provide the 237 ability for an operator to forward both 6to4-PMT (translated) and 238 normal 6to4 flows (untranslated) simultaneously based on configured 239 policy. 241 3.3. Prefix Translation 243 The IPv6 Prefix Translation is a key part of the system as a whole. 244 The 6to4-PMT framework is a combination of two concepts: 6to4 245 [RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation has 246 some similarities to concepts discussed in [RFC6296]. The only 247 change in this particular case is that the provider would build 248 specific rules on the translator to map the 6to4 prefix to an 249 appropriate provider assigned prefix. 251 The provider can use any prefix mapping strategy they so choose, but 252 the simpler the better. Simple direct bit mapping can be used such 253 as in Figure 3, or more advanced forms of translation can be used to 254 achieve higher address compression. 256 Figure 3 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a 257 provider globally unique prefix (2001:db8::/32). With this simple 258 form of translation, there is support for only one Subnet-ID per 259 provider assigned prefix. In characterization of deployed OSs and 260 gateways, a subnet-id of "0000" is the most common default case. 262 Pre-Relayed Packet [Provider Access Network Side] 264 0 16 32 48 64 80 96 112 128 Bits 265 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 266 2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx 267 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 268 | | | | | | 269 ---- ---- | | | | 270 | | | | | | 271 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 272 2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx 273 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 275 Post-Relayed Packet [Internet Side] 277 Figure 3: 6to4-PMT Prefix Mapping 279 Additional prefix compression techniques can be used as developed and 280 deployed by the vendor community. These techniques would allow for a 281 more flexible implementation potentially supporting more Subnet-IDs 282 per provider prefix. 284 3.4. Translation State 286 It is preferred that the overall system use deterministic prefix 287 translation mappings such that stateless operation can be 288 implemented. This allows the provider to place N number of relays 289 within the network without the need to manage translation state. 291 If stateful operation is chosen, the operator would need to validate 292 state and routing requirements particular to that type of deployment. 293 The full body of considerations for this type of deployment are not 294 within this scope of this document. 296 4. Deployment Considerations and Requirements 298 4.1. Customer Opt-out 300 A provider enabling this function should provide a method to allow 301 customers to opt-out of such a service should the customer choose to 302 maintain normal 6to4 operation irrespective of degraded performance. 303 In cases where the customer is behind a NAT44 device (Provider CGN), 304 the customer would not be advised to opt-out and can also be assisted 305 to turn off 6to4. 307 Since the 6to4-PMT system is targeted at customers who are relatively 308 unaware of IPv6 and IPv4, and normally run network equipment with a 309 default configuration, an opt-out strategy is recommended. This 310 method provides the 6to4-PMT operation for non-IPv6 savvy customers 311 whose equipment may turn on 6to4 automatically and allows savvy 312 customers to easily configure their way around the 6to4-PMT function. 314 Capable customers can also disable anycast based 6to4 entirely and 315 use traditional 6to4 or other tunnelling mechanisms if they are so 316 inclined. This is not considered the normal case, and most endpoints 317 with auto-6to4 operation will be subject to 6to4-PMT operation since 318 most users are unaware of it's existence. 6to4-PMT is targeted as an 319 option for stable IPv6 connectivity for average consumers. 321 4.2. Shared Transition Space Considerations 323 6to4-PMT operation can also be used to mitigate a known problem with 324 6to4 when Shared Transition Space [I-D.weil-shared-transition-space- 325 request] or public but non-routed IPv4 space is used. Public but un- 326 routed address space would cause many deployed OSs and network 327 equipment to potentially auto-enable 6to4 operation even without a 328 valid return path (such as behind a NAT44 provider function). The 329 Operators' desire to use public but un-routed IP space is considered 330 highly likely based on points made in [I-D.bdgks-arin-shared- 331 transition-space]. 333 Such hosts, in normal cases, would send 6to4 traffic to the IPv6 334 Internet via the IPv4 anycast relay, which would in fact provide 335 broken IPv6 connectivity since the return path flow is built using an 336 address that is not routed or assigned to the source Network. The 337 use of 6to4-PMT would help reverse these effects by translating the 338 6to4 prefix to a provided assigned prefix, masking this automatic and 339 undesired behaviour. 341 4.3. End to End Transparency 343 6to4-PMT mode operation removes the traditional end to end 344 transparency of 6to4. Remote hosts would connect to a translated 345 IPv6 address versus the original 6to4 based prefix. This can be seen 346 as a disadvantage of the 6to4-PMT system. This lack of transparency 347 should also be contrasted with the normal operating state of 6to4 348 which provides uncontrolled and often high latency prone 349 connectivity. The lack of transparency is however a better form of 350 operation when extreme poor performance, broken IPv6 connectivity, or 351 no IPv6 connectivity is considered as the alternative. 353 4.4. Routing Requirements 355 The provider would need to advertise the anycast IP range within the 356 IPv4 routing environment (devices to be serviced) to attract the 6to4 357 upstream traffic. To control this environment and make sure all 358 northbound traffic lands on a provider BR, the operator may filter 359 the anycast range from being advertised from customer endpoints 360 toward the network (upstream propagation). 362 The provider would not be able to control route advertisements inside 363 the customer domain, but this use case is out of this document's 364 scope. It is likely in this case the end network/customer 365 understands IPv6 operation and is maintaining their own environment. 367 The provider would also likely want to advertise the 2002::/16 range 368 within their own network to help bridge traditional 6to4 traffic 369 within their own network (Native IPv6 to 6to4-PMT based endpoint). 371 4.5. Relay Deployments 373 The 6to4-PMT function can be deployed onto existing 6to4 relays (if 374 desired) to help minimize network complexity. 6ot4-PMT has already 375 been developed on Linux based platforms which are package add-ons to 376 the traditional 6to4 code. The only additional considerations beyond 377 normal 6to4 relay operation would include the need to route specific 378 IPv6 provide prefix ranges towards peers and the Internet. 380 5. IANA Considerations 382 No IANA considerations are defined at this time. 384 6. Security Considerations 386 6to4-PMT operation would be subject to the same security concerns as 387 normal 6to4 operation and with the operation of tunnels. 6to4-PMT is 388 also not plainly perceptible by external hosts and entities appearing 389 as Native IPv6. 391 7. Acknowledgements 393 Thanks to the following people for their textual contributions and/or 394 guidance on 6to4 deployment considerations: Dan Wing, Wes George, 395 Scott Beuker, JF Tremblay, John Brzozowski, and Chris Donley 397 Additional thanks to the following for assisting with the coding and 398 testing of 6to4-PMT: Marc Blanchet, John Cianfarani, and Nik Lavorato 400 8. References 401 8.1. Normative References 403 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 404 via IPv4 Clouds", RFC 3056, February 2001. 406 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 407 RFC 3068, June 2001. 409 8.2. Informative References 411 [I-D.bdgks-arin-shared-transition-space] 412 Barber, S., Delong, O., Grundemann, C., Kuarsingh, V., and 413 B. Schliesser, "ARIN Draft Policy 2011-5: Shared 414 Transition Space", 415 draft-bdgks-arin-shared-transition-space-02 (work in 416 progress), August 2011. 418 [I-D.weil-shared-transition-space-request] 419 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 420 M. Azinger, "IANA Reserved IPv4 Prefix for Shared 421 Transition Space", 422 draft-weil-shared-transition-space-request-04 (work in 423 progress), August 2011. 425 [RFC3484] Draves, R., "Default Address Selection for Internet 426 Protocol version 6 (IPv6)", RFC 3484, February 2003. 428 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 429 Infrastructures (6rd) -- Protocol Specification", 430 RFC 5969, August 2010. 432 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 433 Translation", RFC 6296, June 2011. 435 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 436 Stack Lite Broadband Deployments Following IPv4 437 Exhaustion", RFC 6333, August 2011. 439 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 440 RFC 6343, August 2011. 442 Authors' Addresses 444 Victor Kuarsingh (editor) 445 Rogers Communications 446 8200 Dixie Road 447 Brampton, Ontario L6T 0C1 448 Canada 450 Email: victor.kuarsingh@gmail.com 451 URI: http://www.rogers.com 453 Yiu L. Lee 454 Comcast 455 One Comcast Center 456 Philadelphia, PA 19103 457 U.S.A. 459 Email: yiu_lee@cable.comcast.com 460 URI: http://www.comcast.com 462 Olivier Vautrin 463 Juniper Networks 464 1194 N Mathilda Avenue 465 Sunnyvale, CA 94089 466 U.S.A. 468 Email: olivier@juniper.net 469 URI: http://www.juniper.net