idnits 2.17.1 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00.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 22, 2010) is 4936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.mrw-behave-nat66' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'I-D.weil-opsawg-provider-address-space' is defined on line 375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) -- No information found for draft-weil-opsawg-provider-address-space - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 3 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: March 26, 2011 Comcast 6 O. Vautrin 7 Juniper Networks 8 September 22, 2010 10 6to4 Provider Managed Tunnels 11 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00 13 Abstract 15 This document provides an overview of a framework describing the 16 management of 6to4 [RFC3056] tunnels within a provider network. The 17 6to4 provider managed tunnel, or 6to4-PMT, combines the current 18 behavior of 6to4 [RFC3056] utilizing the IPv4 anycast based 19 connectivity defined in [RFC3068] along with IPv6 Prefix Translation. 20 The framework is intended to allow Service Providers an option to 21 translate 6to4 based addresses to provider based addresses utilizing 22 provider assigned prefixes. The framework offers IPv6 connectivity 23 to 6to4 compatible endpoints [RFC3056] with the advantage of a stable 24 provider assigned prefix. The 6to4-PMT operation is not intended to 25 replace Native IPv6 connectivity nor 6RD, but rather provide a 26 connectivity before such options can be deployed by an operator. 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 26, 2011. 45 Copyright Notice 47 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . 4 65 3.1. 6to4 Provider Managed Tunnel Model . . . . . . . . . . . . 4 66 3.2. Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Prefix Translation . . . . . . . . . . . . . . . . . . . . 5 68 3.4. Translation State . . . . . . . . . . . . . . . . . . . . . 6 69 4. Deployment Issues and Requirements . . . . . . . . . . . . . . 7 70 4.1. Customer Opt-out . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. ISP Shared Space Interaction . . . . . . . . . . . . . . . 7 72 4.3. End to End Transparency . . . . . . . . . . . . . . . . . . 8 73 4.4. Routing Requirements . . . . . . . . . . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 6to4 [RFC3056] tunneling is widely deployed in modern host OSs and 85 off the shelf gateways sold throughout the retail and OEM channels. 86 6to4 allows for tunneled IPv6 connectivity through IPv4 clouds, but 87 due to the anycast nature of the ingress and egress flows, flows 88 paths are difficult to determine and often change based on network 89 conditions. The return path is uncontrolled by the local provider 90 and can contribute to poor performance for IPv6, and can also act as 91 a breakage point (i.e. mis-behaving relay/system). For this reason, 92 despite being widely available today, many providers choose not to 93 directly support a 6to4 environment. 95 Providers which are actively deploying IPv6 networks and operate 96 legacy IPv4 access environments may want to utilize the existing 6to4 97 behavior in deployed hardware and software and offer a more 98 controlled access to the IPv6 Internet for 6to4 capable endpoints. 99 6to4-PMT offers a provider the opportunity to utilize IPv6 Prefix 100 Translation to provide a more deterministic path to and from the 101 Internet for 6to4 based traffic. 103 6to4-PMT translates the prefix portion of the address from the 6to4 104 address to a provider assigned prefix which is used to represent the 105 source. This translation will then provide a stable forward and 106 return path for the 6to4 traffic by allowing the existing IPv6 107 routing and policy environment to control the traffic. 6to4-PMT is 108 intended to be used in a stateless manner to maintain many of the 109 elements inherent in normal 6to4 operation. 111 2. Motivation 113 Providers endeavor to deploy IPv6 as soon as possible, so as to 114 ensure uninterrupted connectivity to all Internet applications and 115 content through the transition process. The IPv6 preparations within 116 these organizations are often faced with both financial challenges 117 and timing issues related to deploying IPv6 to the network edge and 118 related transition technologies. Many of the new technologies 119 addressing IPv4 to IPv6 transition will require the replacement of 120 the customer CPE to support technologies like 6RD [RFC5569]. 122 Provider initiated replacement of this equipment will take time due 123 to the nature of such mass equipment refresh programs. Additionally, 124 many providers also do not supply CPE related equipment and general 125 lack of awareness in the consumer space may delay the upgrade of many 126 in-home gateway and operating environments. Providers may still be 127 motivated to provide a form of IPv6 connectivity to customers to 128 mitigate potential issues related to IPv6-only deployments elsewhere 129 on the Internet. After IPv4 run out, IPv6 content may grow rapidly 130 and in some cases, IPv4 may not be a connection option for some web 131 based content providers or the remote host (IPv6 Only). 133 6to4-PMT allows a provider to help mitigate such challenges by 134 leveraging a protocol which is already found on many CPE home 135 gateways, while maintaining operator control of access to the IPv6 136 Internet. It is intended for use when better options, such as 6RD or 137 native IPv6, are not yet viable. The 6to4-PMT operation can also be 138 used immediately with existing OS and gateway functionality (in the 139 wild) without the initial costly replacement of consumer equipment. 140 The default 6to4 operation on most consumer grade OSs and gateways 141 will allow for IPv6 connectivity over the IPv4 access network. Once 142 native IPv6 is available to the endpoint, the 6to4-PMT operation is 143 not longer needed. Next step options can include 6RD or Native IPv6. 144 6to4-PMT offers an opportunity to fill the gap between now and when 145 the provider can feasibly replace the CPE equipment. 147 3. 6to4 Provider Managed Tunnels 149 3.1. 6to4 Provider Managed Tunnel Model 151 The 6to4 managed tunnel model behaves like a standard 6to4 service 152 between the customer IPv6 host or gateway and the 6ot4-PMT Relay 153 (within the provider domain). The 6to4-PMT Relay shares properties 154 with 6RD [RFC5569] by decapsulating and forwarding embedded IPv6 155 flows, within an IPv4 packet, to the IPv6 Internet. The model 156 provides an additional function which translates the source 6to4 157 prefix to a provider assigned prefix which is not found in 6RD 158 [RFC5569] or normal 6to4 operation. 160 The 6to4-PMT Relay is intended to provide a stateless mapping of the 161 6to4 prefix to a provider supplied prefix by mapping the embedded 162 IPv4 address in the 6to4 prefix to the provider prefix. 164 | 6to4-PMT Operation | 166 +-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+ 167 | CPE |-------------|6to4 BR |--| PT66 |--------- |Host| 168 +-----+ IPv4 +--------+ +------+ Provider +----+ 169 Network Prefix 170 Unified or Separate 171 Functions/Platforms 173 Figure 1: 6to4-PMT Functional Model 175 3.2. Traffic Flow 177 Traffic in the 6to4-PMT model is intended to be controlled by the 178 operators IPv6 peering operations. Egress traffic is managed through 179 outgoing routing policy, and incoming traffic is influenced by the 180 operator assigned prefix advertisements. 182 The routing model is as predictable as native IPv6 traffic and legacy 183 IPv4 based traffic. Figure 1 provides a view of the routing topology 184 needed to support this relay environment. The diagram references 185 PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32. 187 | 6to4 IPv4 Path | Native IPv6 Path | 188 ----------- ----------- ------------- 189 / IPv4 Net \ / IPv6 Net \ / IPv6 Internet \ 190 +------+ +--------+ +-------+ +---------+ 191 | CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST| 192 +------+ +--------+ +-------+ +---------+ 193 \ / \ / \ / 194 ---------- ------------ -------------- 196 IPv4 6to4 IPv6 Provider IPv6 Prefix 197 Anycast Prefix Advertisement 199 Figure 2: 6to4-PMT Flow Model 201 Traffic normally between two 6to4 enabled devices would use the IPv4 202 path for communication according to RFC3056 204 3.3. Prefix Translation 206 The IPv6 Prefix Translation is a key part of the system as a whole. 207 The 6to4-PMT framework is a combination of two concepts: 6to4 208 [RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation has 209 some similarities to concepts discussed in [draft-mrw-behave-nat66]. 210 The only change in this particular case is that the provider would 211 build specific rules on the translator to map the 6to4 prefix to an 212 appropriate provider assigned prefix. 214 The provider can use any prefix mapping strategy they so choose, but 215 the simpler the better. Simple direct bit mapping can be used such 216 as in Figure 2, or more advanced forms of translation can used 217 [reference to I-D here] to achieve higher address compression. 219 Figure 2 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a 220 provider globally unique prefix (2001:db8::/32). With this simple 221 form of translation, there is support for only one Subnet-ID per 222 provider assigned prefix. In characterization of deployed OSs and 223 gateways, a subnet-id of "0000" is the most common default case. 225 Pre-Relayed Packet [Provider Access Network Side] 227 0 16 32 48 64 80 96 112 128 Bits 228 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 229 2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx 230 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 231 | | | | | | 232 ---- ---- | | | | 233 | | | | | | 234 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 235 2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx 236 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 238 Post-Relayed Packet [Internet Side] 240 Figure 3: 6to4-PMT Prefix Mapping 242 Additional prefix compression techniques can be used such as those 243 described in [draft-treamblay-pt66-compression]. These techniques 244 would allow for a more flexible implementation potentially supporting 245 more Subnet-IDs per provider prefix 247 3.4. Translation State 249 It is preferred that the overall system use deterministic prefix 250 translation mappings such that stateless operation can be 251 implemented. This allows the provider to place N number of relays 252 within the network without the need to route traffic specifically to 253 support 6to4-PMT. 255 If stateful operation is used, then the provider would need to force 256 all return traffic to pass back through the same relay as the exit 257 packets. The assumption here is that the provider would operate the 258 6to4 anycast environment on the IPv4 side of the relay. To control 259 the ingress traffic, the provider would need to craft IPv6 routes 260 (more specific then provider assigned prefix) which match the IPv4 261 ranges for a given relay. 263 Maintaining these additional routes would subject the provider's IPv6 264 network to maintaining a number of fragmented IPv4 network router 265 (level of fragmentation dependant on network), these routes do not 266 need to be advertised to peer networks, nor should hey. 268 4. Deployment Issues and Requirements 270 4.1. Customer Opt-out 272 A provider enabling this function should provide a method to allow 273 customers to opt-out of such a service should the customer choose to, 274 or wish to maintain normal 6to4 operation. 276 Since the 6to4-PMT system is targeted at customers who are relatively 277 unaware of IPv6 and IPv4, and normally run network equipment with a 278 default configuration, an opt-out strategy is preferred. This method 279 provides the 6to4-PMT operation for non-IPv6 savvy customers whose 280 equipment may turn on 6to4 automatically. 282 Customers who are aware of IPv6 operation can request an opt-out, or 283 more appropriately use an automated mechanism to opt-out of the 6to4- 284 PMT operation. One automated opt-out strategy can include the use of 285 Subnet-Id triggers (well known IDs which are determined by policy in 286 the relay to not be translated). Other policy based strategies can 287 be employed by the provider to enable opt-out. 289 Capable customers can also disable 6to4 entirely and use other 290 tunneling mechanisms if they are so capable. This is not considered 291 the normal case, and most endpoints with auto-6to4 operation will be 292 subject to 6to4-PMT operation operation. 6to4-PMT is targeted as an 293 option for deterministic IPv6 connectivity for average consumers 295 4.2. ISP Shared Space Interaction 297 6to4-PMT operation can also be used to mitigate a known problem with 298 6to4 when ISP Shared Space 299 [draft-weil-opsawg-provider-address-spaces] is used. ISP Shared 300 Space would cause many deployed OSs and network equipment to 301 potentially auto-enable 6to4 operation should non-RFC1918 addressing 302 be used on the CPE IPv4 address assignments. 304 Such hosts, in normal cases, would send 6to4 traffic to the IPv6 305 Internet via the IPv4 anycast relay, which would in fact provide 306 broken IPv6 connectivity since the return path is based on an address 307 that is not routed or assigned to the source Network. The use of 308 6to4-PMT would help reverse these effects by translating the 6to4 309 prefix to a provided assigned prefix, masking this automatic and 310 undesired behavior. It is conceivable that 6to4-PMT can also used to 311 help provide 6to4 operation with the use of ISP Shared Space. 313 4.3. End to End Transparency 315 6to4-PMT mode operation removes the traditional end to end 316 transparency of 6to4. Remote hosts would connect to a translated 317 IPv6 address versus the original 6to4 based prefix. This can be seen 318 as a disadvantage to the 6to4-PMT system. This lack of transparency 319 should also be contrasted with the normal operating state of 6to4 320 which provides uncontrolled and often high latency prone connectivity 322 4.4. Routing Requirements 324 The provider would need to advertise the anycast IP range within the 325 IPv4 routing environment (service customers of interest) to attract 326 the 6to4 upstream traffic. To control this environment and make sure 327 all northbound traffic lands on a provider BR, the operator may 328 filter the anycast range form being advertised form customer 329 endpoints. 331 The provider would not be able to control route advertisements inside 332 the customer domain, but this use case is out of scope. It is likely 333 in this case the end network/customer understands IPv6 operation and 334 is maintaining their own environment. 336 The provider would also likely want to advertise the 2002::/16 range 337 within their own network to help bridge within their own network 338 (Native IPv6 to 6to4-IPv6 based endpoint) 340 5. IANA Considerations 342 No IANA considerations are defined at this time. 344 6. Security Considerations 346 6to4-PMT operation would be subject to the same security concerns as 347 normal 6to4 operation and with the operation of tunnels. 348 Considerations may also include operation modes related to Prefix 349 Translation. Additional considerations may be found after real 350 deployment data is gathered or further analysis is made. 352 7. Acknowledgements 354 Thanks to the following people for their textual contributions and/or 355 guidance on 6to4 deployment considerations: Dan Wing, Scott Beuker, 356 JF Tremblay, John Brzozowski and Chris Donley 358 8. References 360 8.1. Normative References 362 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 363 via IPv4 Clouds", RFC 3056, February 2001. 365 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 366 RFC 3068, June 2001. 368 8.2. Informative References 370 [I-D.mrw-behave-nat66] 371 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 372 Translation (NAT66)", draft-mrw-behave-nat66-02 (work in 373 progress), March 2009. 375 [I-D.weil-opsawg-provider-address-space] 376 Weil, J., Kuarsingh, V., and C. Donley, "IANA Reserved 377 IPv4 Prefix for IPv6 Transition", 378 draft-weil-opsawg-provider-address-space-01 (work in 379 progress), August 2010. 381 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 382 Infrastructures (6rd)", RFC 5569, January 2010. 384 Authors' Addresses 386 Victor Kuarsingh (editor) 387 Rogers Communications 388 8200 Dixie Road 389 Brampton, Ontario L6T 0C1 390 Canada 392 Email: victor.kuarsingh@rci.rogers.com 393 URI: http://www.rogers.com 395 Yiu L. Lee 396 Comcast 397 One Comcast Center 398 Philadelphia, PA 19103 399 U.S.A. 401 Email: yiu_lee@cable.comcast.com 402 URI: http://www.comcast.com 403 Olivier Vautrin 404 Juniper Networks 405 1194 N Mathilda Avenue 406 Sunnyvale, CA 94089 407 U.S.A. 409 Email: olivier@juniper.net 410 URI: http://www.juniper.net