idnits 2.17.1 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01.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 (February 1, 2011) is 4833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.mrw-nat66' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'I-D.tremblay-pt66ac' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'I-D.weil-shared-transition-space-request' is defined on line 394, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) == Outdated reference: A later version (-16) exists of draft-mrw-nat66-07 == 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 (~~), 6 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: August 5, 2011 Comcast 6 O. Vautrin 7 Juniper Networks 8 February 1, 2011 10 6to4 Provider Managed Tunnels 11 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01 13 Abstract 15 6to4 Provider Managed Tunnels (6to4-PMT) provides 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 service providers to help improve the experience of 19 6to4 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 subject to a northbound Large Scale NAT 26 [draft-nishitani-cgn-05] translator breaking the normal IPv4 return 27 path. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 5, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. 6to4 Provider Managed Tunnels . . . . . . . . . . . . . . . . 4 66 3.1. 6to4 Provider Managed Tunnel Model . . . . . . . . . . . . 4 67 3.2. Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Prefix Translation . . . . . . . . . . . . . . . . . . . . 5 69 3.4. Translation State . . . . . . . . . . . . . . . . . . . . 6 70 4. Deployment Issues and Requirements . . . . . . . . . . . . . . 7 71 4.1. Customer Opt-out . . . . . . . . . . . . . . . . . . . . . 7 72 4.2. ISP Shared Space Interaction . . . . . . . . . . . . . . . 7 73 4.3. End to End Transparency . . . . . . . . . . . . . . . . . 8 74 4.4. Routing Requirements . . . . . . . . . . . . . . . . . . . 8 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 6to4 [RFC3056] tunneling along with anycast operation [RFC3068] is 86 widely deployed in modern host Operating Systems and off the shelf 87 gateways sold throughout the retail and OEM channels. RFC3068 based 88 6to4 allows for tunneled IPv6 connectivity through IPv4 clouds, but 89 due to the anycast nature of the ingress and egress flows, flows 90 paths are difficult to determine and often change based on network 91 conditions. The return path is uncontrolled by the local provider 92 and can contribute to poor performance for IPv6, and can also act as 93 a breakage point (i.e. mis-behaving relay/system). Additionally, 94 consumer endpoints which are subject to northbound NAT44 operation, 95 such as with NAT444, may be subject to broken IPv6 connectivity if 96 non-RFC1918 addresses are used on the CPE. 98 Providers which are actively deploying IPv6 networks and operate 99 legacy IPv4 access environments may want to utilize the existing 6to4 100 behavior in deployed hardware and software as an interim option to 101 reach the IPv6 internet in advance of being able to offer native 102 IPv6. 6to4-PMT offers a provider the opportunity to utilize IPv6 103 Prefix Translation to provide deterministic and an unbroken path to 104 and from the Internet for IPv6 based traffic. 106 6to4-PMT translates the prefix portion of the address from the 6to4 107 address to a provider assigned prefix which is used to represent the 108 source. This translation will then provide a stable forward and 109 return path for the 6to4 traffic by allowing the existing IPv6 110 routing and policy environment to control the traffic. 6to4-PMT is 111 primarily intended to be used in a stateless manner to maintain many 112 of the elements inherent in normal 6to4 operation. Alternatively, 113 6to4-PMT can be used in a stateful translation mode should the 114 operator choose this option. 116 2. Motivation 118 Providers endeavor to deploy IPv6 as soon as possible, so as to 119 ensure uninterrupted connectivity to all Internet applications and 120 content through the transition process. The IPv6 preparations within 121 these organizations are often faced with both financial challenges 122 and timing issues related to deploying IPv6 to the network edge and 123 related transition technologies. Many of the new technologies 124 addressing IPv4 to IPv6 transition will require the replacement of 125 the customer CPE to support technologies like 6RD [RFC5969] which 126 also require the replacement or upgrade of the customer endpoint 127 device.. 129 Provider initiated replacement of this equipment will take time due 130 to the nature of such mass equipment refresh programs. Additionally, 131 many providers also do not supply CPE related equipment and general 132 lack of awareness in the consumer space may delay the upgrade of many 133 in-home gateway and operating environments. Providers may still be 134 motivated to provide a form of IPv6 connectivity to customers to 135 mitigate potential issues related to IPv6-only deployments elsewhere 136 on the Internet. Providers may also need to mitigate issues of 137 default 6to4 operation in these existing home devices. After IPv4 138 run out, IPv6 content and addressed endpoints may grow rapidly in 139 number and in some cases, IPv4 may not be a connection option for 140 some web based content providers or the remote hosts (IPv6 Only). 142 6to4-PMT allows a provider to help mitigate such challenges by 143 leveraging a protocol which is already found on many CPE home 144 gateways, while maintaining operator control of access to the IPv6 145 Internet. It is intended for use when better options, such as 6RD or 146 native IPv6, are not yet viable. The 6to4-PMT operation can also be 147 used immediately with existing OS and gateway functionality (in the 148 wild) without the initial replacement of consumer equipment. The 149 default 6to4 operation on most consumer grade OSs and gateways will 150 allow for IPv6 connectivity over the IPv4 access network. Once 151 native IPv6 is available to the endpoint, the 6to4-PMT operation is 152 no longer needed. If 6to4-PMT operation was used to mitigate default 153 6to4 operation in a NAT444 environment, then native IPv6 addresses 154 will take precedence based on IPv6 address selection [RFC3484]. 156 3. 6to4 Provider Managed Tunnels 158 3.1. 6to4 Provider Managed Tunnel Model 160 The 6to4 managed tunnel model behaves like a standard 6to4 service 161 between the customer IPv6 host or gateway and the 6ot4-PMT Relay 162 (within the provider domain). The 6to4-PMT Relay shares properties 163 with 6RD [RFC5969] by decapsulating and forwarding embedded IPv6 164 flows, within an IPv4 packet, to the IPv6 Internet. The model 165 provides an additional function which translates the source 6to4 166 prefix to a provider assigned prefix which is not found in 6RD 167 [RFC5969] or traditional 6to4 operation. 169 The 6to4-PMT Relay is intended to provide a stateless (or stateful) 170 mapping of the 6to4 prefix to a provider supplied prefix by mapping 171 the embedded IPv4 address in the 6to4 prefix to the provider prefix. 173 | 6to4-PMT Operation | 175 +-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+ 176 | CPE |-------------|6to4 BR |--| PT66 |--------- |Host| 177 +-----+ IPv4 +--------+ +------+ Provider +----+ 178 Network Prefix 179 Unified or Separate 180 Functions/Platforms 182 Figure 1: 6to4-PMT Functional Model 184 This mode of operation is seen as beneficial when compared to broken 185 6to4 paths and or environments where 6to4 operation may be functional 186 but highly degraded. 188 3.2. Traffic Flow 190 Traffic in the 6to4-PMT model is intended to be controlled by the 191 operators IPv6 peering operations. Egress traffic is managed through 192 outgoing routing policy, and incoming traffic is influenced by the 193 operator assigned prefix advertisements. 195 The routing model is as predictable as native IPv6 traffic and legacy 196 IPv4 based traffic. Figure 1 provides a view of the routing topology 197 needed to support this relay environment. The diagram references 198 PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32. 200 | 6to4 IPv4 Path | Native IPv6 Path | 201 ----------- ----------- ------------- 202 / IPv4 Net \ / IPv6 Net \ / IPv6 Internet \ 203 +------+ +--------+ +-------+ +---------+ 204 | CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST| 205 +------+ +--------+ +-------+ +---------+ 206 \ / \ / \ / 207 ---------- ------------ -------------- 209 IPv4 6to4 IPv6 Provider IPv6 Prefix 210 Anycast Prefix Advertisement 212 Figure 2: 6to4-PMT Flow Model 214 Traffic between two 6to4 enabled devices would use the IPv4 path for 215 communication according to RFC3056. 217 3.3. Prefix Translation 219 The IPv6 Prefix Translation is a key part of the system as a whole. 220 The 6to4-PMT framework is a combination of two concepts: 6to4 222 [RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation has 223 some similarities to concepts discussed in [draft-mrw-nat66]. The 224 only change in this particular case is that the provider would build 225 specific rules on the translator to map the 6to4 prefix to an 226 appropriate provider assigned prefix. 228 The provider can use any prefix mapping strategy they so choose, but 229 the simpler the better. Simple direct bit mapping can be used such 230 as in Figure 2, or more advanced forms of translation can used to 231 achieve higher address compression. 233 Figure 2 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a 234 provider globally unique prefix (2001:db8::/32). With this simple 235 form of translation, there is support for only one Subnet-ID per 236 provider assigned prefix. In characterization of deployed OSs and 237 gateways, a subnet-id of "0000" is the most common default case. 239 Pre-Relayed Packet [Provider Access Network Side] 241 0 16 32 48 64 80 96 112 128 Bits 242 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 243 2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx 244 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 245 | | | | | | 246 ---- ---- | | | | 247 | | | | | | 248 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 249 2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx 250 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 252 Post-Relayed Packet [Internet Side] 254 Figure 3: 6to4-PMT Prefix Mapping 256 Additional prefix compression techniques can be used such as those 257 described in [draft-tremblay-pt66ac]. These techniques would allow 258 for a more flexible implementation potentially supporting more 259 Subnet-IDs per provider prefix. 261 3.4. Translation State 263 It is preferred that the overall system use deterministic prefix 264 translation mappings such that stateless operation can be 265 implemented. This allows the provider to place N number of relays 266 within the network without the need to manage translation state. 268 If stateful is chosen, the operation would need to validate state and 269 routing requirements particular to that type of deployment full 270 deployment considerations for this type of deployment are not within 271 this scope of this document. 273 4. Deployment Issues and Requirements 275 4.1. Customer Opt-out 277 A provider enabling this function should provide a method to allow 278 customers to opt-out of such a service should the customer choose to 279 maintain normal 6to4 operation irrespective of degraded performance. 281 Since the 6to4-PMT system is targeted at customers who are relatively 282 unaware of IPv6 and IPv4, and normally run network equipment with a 283 default configuration, an opt-out strategy is recommended. This 284 method provides the 6to4-PMT operation for non-IPv6 savvy customers 285 whose equipment may turn on 6to4 automatically. 287 Customers who are aware of IPv6 operation can request an opt-out, or 288 more appropriately use an automated mechanism to opt-out of the 6to4- 289 PMT operation. One automated opt-out strategy can include the use of 290 Subnet-Id triggers (well known IDs which are determined by policy in 291 the relay to not be translated). Other policy based strategies can 292 be employed by the provider to enable opt-out. 294 Capable customers can also disable anycast based 6to4 entirely and 295 use traditional 6to4 or other tunneling mechanisms if they are so 296 capable. This is not considered the normal case, and most endpoints 297 with auto-6to4 operation will be subject to 6to4-PMT operation 298 operation since most users are unaware of it's existence. 6to4-PMT is 299 targeted as an option for stable IPv6 connectivity for average 300 consumers. 302 4.2. ISP Shared Space Interaction 304 6to4-PMT operation can also be used to mitigate a known problem with 305 6to4 when ISP Shared Space 306 [draft-weil-shared-transition-space-request-01] or public but non- 307 routed IPv4 space is used. Public but un-routed address space would 308 cause many deployed OSs and network equipment to potentially auto- 309 enable 6to4 operation even without a valid return path. This use 310 case is considered highly likely based on points made in 311 [draft-weil-shared-transition-space-request] and in reports such as 312 [wide-tr-kato-as112-rep-01] 314 Such hosts, in normal cases, would send 6to4 traffic to the IPv6 315 Internet via the IPv4 anycast relay, which would in fact provide 316 broken IPv6 connectivity since the return path is based on an address 317 that is not routed or assigned to the source Network. The use of 318 6to4-PMT would help reverse these effects by translating the 6to4 319 prefix to a provided assigned prefix, masking this automatic and 320 undesired behavior. It is conceivable that 6to4-PMT can also used to 321 help provide 6to4 operation with the use of ISP Shared Space. 323 4.3. End to End Transparency 325 6to4-PMT mode operation removes the traditional end to end 326 transparency of 6to4. Remote hosts would connect to a translated 327 IPv6 address versus the original 6to4 based prefix. This can be seen 328 as a disadvantage to the 6to4-PMT system. This lack of transparency 329 should also be contrasted with the normal operating state of 6to4 330 which provides uncontrolled and often high latency prone 331 connectivity. The lack of transparency is however a better form of 332 operation when extreme poor performance or broken connectivity is 333 considered as the alternative. 335 4.4. Routing Requirements 337 The provider would need to advertise the anycast IP range within the 338 IPv4 routing environment (service customers of interest) to attract 339 the 6to4 upstream traffic. To control this environment and make sure 340 all northbound traffic lands on a provider BR, the operator may 341 filter the anycast range form being advertised form customer 342 endpoints. 344 The provider would not be able to control route advertisements inside 345 the customer domain, but this use case is out of scope. It is likely 346 in this case the end network/customer understands IPv6 operation and 347 is maintaining their own environment. 349 The provider would also likely want to advertise the 2002::/16 range 350 within their own network to help bridge within their own network 351 (Native IPv6 to 6to4-IPv6 based endpoint). 353 5. IANA Considerations 355 No IANA considerations are defined at this time. 357 6. Security Considerations 359 6to4-PMT operation would be subject to the same security concerns as 360 normal 6to4 operation and with the operation of tunnels. 361 Considerations may also include operation modes related to Prefix 362 Translation. Additional considerations may be found after real 363 deployment data is gathered or further analysis is made. 365 7. Acknowledgements 367 Thanks to the following people for their textual contributions and/or 368 guidance on 6to4 deployment considerations: Dan Wing, Scott Beuker, 369 JF Tremblay, John Brzozowski and Chris Donley 371 8. References 373 8.1. Normative References 375 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 376 via IPv4 Clouds", RFC 3056, February 2001. 378 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 379 RFC 3068, June 2001. 381 8.2. Informative References 383 [I-D.mrw-nat66] 384 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 385 Translation", draft-mrw-nat66-07 (work in progress), 386 January 2011. 388 [I-D.tremblay-pt66ac] 389 Tremblay, J. and S. Beuker, "Addressing bit compression 390 for stateless IPv6 prefix translation", 391 draft-tremblay-pt66ac-00 (work in progress), 392 November 2010. 394 [I-D.weil-shared-transition-space-request] 395 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 396 M. Azinger, "IANA Reserved IPv4 Prefix for Shared 397 Transition Space", 398 draft-weil-shared-transition-space-request-01 (work in 399 progress), November 2010. 401 [RFC3484] Draves, R., "Default Address Selection for Internet 402 Protocol version 6 (IPv6)", RFC 3484, February 2003. 404 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 405 Infrastructures (6rd) -- Protocol Specification", 406 RFC 5969, August 2010. 408 Authors' Addresses 410 Victor Kuarsingh (editor) 411 Rogers Communications 412 8200 Dixie Road 413 Brampton, Ontario L6T 0C1 414 Canada 416 Email: victor.kuarsingh@rci.rogers.com 417 URI: http://www.rogers.com 419 Yiu L. Lee 420 Comcast 421 One Comcast Center 422 Philadelphia, PA 19103 423 U.S.A. 425 Email: yiu_lee@cable.comcast.com 426 URI: http://www.comcast.com 428 Olivier Vautrin 429 Juniper Networks 430 1194 N Mathilda Avenue 431 Sunnyvale, CA 94089 432 U.S.A. 434 Email: olivier@juniper.net 435 URI: http://www.juniper.net