idnits 2.17.1 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07.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 (July 10, 2012) is 4279 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: January 11, 2013 Comcast 6 O. Vautrin 7 Juniper Networks 8 July 10, 2012 10 6to4 Provider Managed Tunnels 11 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07 13 Abstract 15 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which 16 can help manage 6to4 tunnels operating in an anycast configuration. 17 The 6to4-PMT framework is intended to serve as an option for 18 operators to help improve the experience of 6to4 operation when 19 conditions of the network may provide sub-optimal performance or 20 break normal 6to4 operation. 6to4-PMT provides a stable provider 21 prefix and forwarding environment by utilizing existing 6to4 relays 22 with an added function of IPv6 Prefix Translation. This operation 23 may be particularly important in NAT444 infrastructures where a 24 customer endpoint may be assigned a non-RFC1918 address thus breaking 25 the return path for anycast based 6to4 operation. 6to4-PMT has 26 successfully been used in a production network, has been implemented 27 as open source code, and implemented by a major routing vendor. 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 January 11, 2013. 46 Copyright Notice 48 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . 5 66 3.1. 6to4 Provider Managed Tunnel Model . . . . . . . . . . . . 5 67 3.2. Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Prefix Translation . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Translation State . . . . . . . . . . . . . . . . . . . . 7 70 4. Deployment Considerations and Requirements . . . . . . . . . . 7 71 4.1. Customer Opt-out . . . . . . . . . . . . . . . . . . . . . 7 72 4.2. Shared CGN Space Considerations . . . . . . . . . . . . . 8 73 4.3. End to End Transparency . . . . . . . . . . . . . . . . . 8 74 4.4. Path MTU Discovery Considerations . . . . . . . . . . . . 9 75 4.5. Checksum Management . . . . . . . . . . . . . . . . . . . 9 76 4.6. Application Layer Gateways . . . . . . . . . . . . . . . . 9 77 4.7. Routing Requirements . . . . . . . . . . . . . . . . . . . 9 78 4.8. Relay Deployments . . . . . . . . . . . . . . . . . . . . 10 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 6to4 [RFC3056] tunnelling along with the anycast operation described 90 in [RFC3068] is widely deployed in modern Operating Systems and off 91 the shelf gateways sold throughout the retail and OEM channels. 92 Anycast [RFC3068] based 6to4 allows for tunnelled IPv6 connectivity 93 through IPv4 clouds without explicit configuration of a relay 94 address. Since the overall system utilizes anycast forwarding in 95 both directions, flow paths are difficult to determine, tend to 96 follow separate paths in either direction, and often change based on 97 network conditions. The return path is normally uncontrolled by the 98 local operator and can contribute to poor performance for IPv6, and 99 can also act as a breakage point. Many of the challenges with 6to4 100 are described in [RFC6343]. A specific critical use case for 101 problematic anycast 6to4 operation is related to conditions where the 102 consumer endpoints are downstream from a northbound CGN [RFC6264] 103 function when assigned non-RFC1918 IPv4 addresses, which are not 104 routed on interdomain links. 106 Operators which are actively deploying IPv6 networks and operate 107 legacy IPv4 access environments may want to utilize the existing 6to4 108 behaviour in customer site resident hardware and software as an 109 interim option to reach the IPv6 Internet in advance of being able to 110 offer full native IPv6. Operators may also need to address the 111 brokenness related to 6to4 operation originating from behind a 112 provider NAT function. 6to4-PMT offers an operator the opportunity to 113 utilize IPv6 Prefix Translation to enable deterministic traffic flow 114 and an unbroken path to and from the Internet for IPv6 based traffic 115 sourced originally from these 6to4 customer endpoints. 117 6to4-PMT translates the prefix portion of the IPv6 address from the 118 6to4 generated prefix to a provider assigned prefix which is used to 119 represent the source. This translation will then provide a stable 120 forward and return path for the 6to4 traffic by allowing the existing 121 IPv6 routing and policy environment to control the traffic. 6to4-PMT 122 is primarily intended to be used in a stateless manner to maintain 123 many of the elements inherent in normal 6to4 operation. 124 Alternatively, 6to4-PMT can be used in a stateful translation mode 125 should the operator choose this option. 127 2. Motivation 129 Many operators endeavour to deploy IPv6 as soon as possible so as to 130 ensure uninterrupted connectivity to all Internet applications and 131 content through the IPv4 to IPv6 transition process. The IPv6 132 preparations within these organizations are often faced with both 133 financial challenges and timing issues related to deploying IPv6 to 134 the network edge and related transition technologies. Many of the 135 new technologies available for IPv4 to IPv6 transition will require 136 the replacement of the customer CPE to support technologies like 6RD 137 [RFC5969], Dual-Stack Lite [RFC6333] and Native Dual Stack. 139 Operators face a number of challenges related to home equipment 140 replacement. Operator initiated replacement of this equipment will 141 take time due to the nature of mass equipment refresh programs or may 142 require the consumer to replace their own gear. Replacing consumer 143 owned and operated equipment, compounded by the fact that there is 144 also a general unawareness of what IPv6 is, also adds to the 145 challenges faced by operators. It is also important to note that 146 6to4 is found in much of the equipment found in networks today which 147 do not as of yet, or will not, support 6RD and/or Native IPv6. 149 Operators may still be motivated to provide a form of IPv6 150 connectivity to customers and would want to mitigate potential issues 151 related to IPv6-only deployments elsewhere on the Internet. 152 Operators also need to mitigate issues related to the fact that 6to4 153 operation often is on by default and may be subject to erroneous 154 behaviour. The undesired behaviour may be related to the use of non- 155 RFC1918 addresses on CPE equipment which operate behind large 156 operator NATs, or other conditions as described in a general advisory 157 as laid out in [RFC6343]. 159 6to4-PMT allows an operator to help mitigate such challenges by 160 leveraging the existing 6to4 deployment base, while maintaining 161 operator control of access to the IPv6 Internet. It is intended for 162 use when better options, such as 6RD or Native IPv6, are not yet 163 viable. One of key objectives of 6to4-PMT is to also help reverse 164 the negative impacts of 6to4 in CGN environments. The 6to4-PMT 165 operation can also be used immediately with the default parameters 166 which are often enough to allow it to operate in a 6to4-PMT 167 environment. Once native IPv6 is available to the endpoint, the 168 6to4-PMT operation is no longer needed and will cease to be used 169 based on correct address selection behaviours in end hosts [RFC3484]. 171 6to4-PMT thus helps operators remove the impact of 6to4 in CGN 172 environments, deals with the fact that 6to4 is often on by default, 173 allows access to IPv6-only endpoints from IPv4-only addressed 174 equipment and provides relief from many challenges related to mis- 175 configurations in other networks which control return flows via 176 foreign relays. Due to the simple nature of 6to4-PMT, it can also be 177 implemented in a cost effective and simple manner allowing operators 178 to concentrate their energy on deploying Native IPv6. 180 3. 6to4 Provider Managed Tunnels 182 3.1. 6to4 Provider Managed Tunnel Model 184 The 6to4 managed tunnel model behaves like a standard 6to4 service 185 between the customer IPv6 host or gateway and the 6to4-PMT Relay 186 (within the provider domain). The 6to4-PMT Relay shares properties 187 with 6RD [RFC5969] by decapsulating and forwarding encapsulated IPv6 188 flows within an IPv4 packet, to the IPv6 Internet. The model 189 provides an additional function which translates the source 6to4 190 prefix to a provider assigned prefix which is not found in 6RD 191 [RFC5969] or traditional 6to4 operation. 193 The 6to4-PMT Relay is intended to provide a stateless (or stateful) 194 mapping of the 6to4 prefix to a provider supplied prefix. 196 | 6to4-PMT Operation | 198 +-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+ 199 | CPE |-------------|6to4 BR |--| PT66 |--------- |Host| 200 +-----+ IPv4 +--------+ +------+ Provider +----+ 201 Network Prefix 202 Unified or Separate 203 Functions/Platforms 205 Figure 1: 6to4-PMT Functional Model 207 This mode of operation is seen as beneficial when compared to broken 208 6to4 paths and/or environments where 6to4 operation may be functional 209 but highly degraded. 211 3.2. Traffic Flow 213 Traffic in the 6to4-PMT model is intended to be controlled by the 214 operator's IPv6 peering operations. Egress traffic is managed 215 through outgoing routing policy, and incoming traffic is influenced 216 by the operator assigned prefix advertisements using normal 217 interdormain routing functions. 219 The routing model is as predictable as native IPv6 traffic and legacy 220 IPv4 based traffic. Figure 2 provides a view of the routing topology 221 needed to support this relay environment. The diagram references 222 PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32. 224 | 6to4 IPv4 Path | Native IPv6 Path | 225 ----------- ----------- ------------- 226 / IPv4 Net \ / IPv6 Net \ / IPv6 Internet \ 227 +------+ +--------+ +-------+ +---------+ 228 | CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST| 229 +------+ +--------+ +-------+ +---------+ 230 \ / \ / \ / 231 ---------- ------------ -------------- 233 IPv4 6to4 IPv6 Provider IPv6 Prefix 234 Anycast Prefix Propagation 236 Figure 2: 6to4-PMT Flow Model 238 Traffic between two 6to4 enabled devices would use the IPv4 path for 239 communication according to RFC3056 unless the local host still 240 prefers traffic via a relay. 6to4-PMT is intended to be deployed in 241 conjunction with the 6to4 relay function in an attempt to help 242 simplify it's deployment. The model can also provide the ability for 243 an operator to forward both 6to4-PMT (translated) and normal 6to4 244 flows (untranslated) simultaneously based on configured policy. 246 3.3. Prefix Translation 248 IPv6 Prefix Translation is a key part of the system as a whole. The 249 6to4-PMT framework is a combination of two concepts: 6to4 [RFC3056] 250 and IPv6 Prefix Translation. IPv6 Prefix Translation, as used in 251 6to4-PMT, has some similarities to concepts discussed in [RFC6296]. 252 6to4-PMT would provide prefix translation based on specific rules 253 configured on the translator which maps the 6to4 2002::/16 prefix to 254 an appropriate provider assigned prefix. In most cases, a ::/32 255 prefix would work best in 6to4-PMT which matches common RIR prefix 256 assignments to operators. 258 The provider can use any prefix mapping strategy they so choose, but 259 the simpler the better. Simple direct bit mapping can be used, or 260 more advanced forms of translation should the operator want to 261 achieve higher address compression. More advanced forms of 262 translation may require the use of stateful translation. 264 Figure 3 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a 265 provider assigned globally unique prefix (2001:db8::/32). With this 266 simple form of translation, there is support for only one Subnet-ID 267 per provider assigned prefix. In characterization of deployed OSs 268 and gateways, a Subnet-ID of "0000" is the most common default case 269 followed by Subnet-ID "0001". Use of Subnet-ID can be referenced in 270 [RFC4291]. It should be noted that in normal 6to4 operation the 271 endpoint (network) has access to 65,536 (16-bits) Subnet IDs. In the 272 6to4-PMT case as described above using the mapping in Figure 3, all 273 but the one Subnet-ID used for 6to4-PMT would still operate under 274 normal 6to4 operation. 276 Pre-Relayed Packet [Provider Access Network Side] 278 0 16 32 48 64 80 96 112 128 Bits 279 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 280 2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx 281 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 282 | | | | | | 283 ---- ---- | | | | 284 | | | | | | 285 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 286 2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx 287 | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 289 Post-Relayed Packet [Internet Side] 291 Figure 3: 6to4-PMT Prefix Mapping 293 3.4. Translation State 295 It is preferred that the overall system use deterministic prefix 296 translation mappings such that stateless operation can be 297 implemented. This allows the provider to place N number of relays 298 within the network without the need to manage translation state. 299 Deterministic translation also allows a customer to use inward 300 services using the translated (provider prefix) address. 302 If stateful operation is chosen, the operator would need to validate 303 state and routing requirements particular to that type of deployment. 304 The full body of considerations for this type of deployment are not 305 within this scope of this document. 307 4. Deployment Considerations and Requirements 309 4.1. Customer Opt-out 311 A provider enabling this function should provide a method to allow 312 customers to opt-out of such a service should the customer choose to 313 maintain normal 6to4 operation irrespective of degraded performance. 314 In cases where the customer is behind a CGN device, the customer 315 would not be advised to opt-out and can also be assisted to turn off 316 6to4. 318 Since the 6to4-PMT system is targeted at customers who are relatively 319 unaware of IPv6 and IPv4, and normally run network equipment with a 320 default configuration, an opt-out strategy is recommended. This 321 method provides 6to4-PMT operation for non-IPv6 savvy customers whose 322 equipment may turn on 6to4 automatically and allows savvy customers 323 to easily configure their way around the 6to4-PMT function. 325 Capable customers can also disable anycast based 6to4 entirely and 326 use traditional 6to4 or other tunnelling mechanisms if they are so 327 inclined. This is not considered the normal case, and most endpoints 328 with auto-6to4 functions will be subject to 6to4-PMT operation since 329 most users are unaware of it's existence. 6to4-PMT is targeted as an 330 option for stable IPv6 connectivity for average consumers. 332 4.2. Shared CGN Space Considerations 334 6to4-PMT operation can also be used to mitigate a known problem with 335 6to4 when shared address space [RFC6598] or Global Unicast Addresses 336 (GUA) are used behind a CGN and not routed on the Internet. Non- 337 RFC1918, yet un-routed (on interdomain links) address space would 338 cause many deployed OSs and network equipment to potentially auto- 339 enable 6to4 operation even without a valid return path (such as 340 behind a CGN function). The Operators' desire to use non-RFC1918 341 addresses, such as shared address space [RFC6598], is considered 342 highly likely based on real world deployments. 344 Such hosts, in normal cases, would send 6to4 traffic to the IPv6 345 Internet via the anycast relay, which would in fact provide broken 346 IPv6 connectivity since the return path flow is built using an IPv4 347 address that is not routed or assigned to the source Network. The 348 use of 6to4-PMT would help reverse these effects by translating the 349 6to4 prefix to a provider assigned prefix, masking this automatic and 350 undesired behaviour. 352 4.3. End to End Transparency 354 6to4-PMT mode operation removes the traditional end to end 355 transparency of 6to4. Remote hosts would connect to a 6to4-PMT 356 serviced host using a translated IPv6 address versus the original 357 6to4 address based on the 2002::/16 well-known prefix. This can be 358 seen as a disadvantage of the 6to4-PMT system. This lack of 359 transparency should also be contrasted with the normal operating 360 state of 6to4 which provides uncontrolled and often high latency 361 prone connectivity. The lack of transparency is however a better 362 form of operation when extreme poor performance, broken IPv6 363 connectivity, or no IPv6 connectivity is considered as the 364 alternative. 366 4.4. Path MTU Discovery Considerations 368 The MTU will be subject to a reduced value due to standard 6to4 369 tunnelling operation. Under normal 6to4 operation, the 6to4 service 370 agent would send an ICMP Packet Too Big Message as part of Path MTU 371 Discovery as described in [RFC4443] and [RFC1981] respectively. In 372 6to4-PMT operation, the PMT Service agent should be aware of the 373 reduced 6to4 MTU and send ICMP messages using the translated address 374 accordingly. 376 It is also possible to pre-constrain the MTU at the upstream router 377 from the 6to4-PMT service agents which would then have the upstream 378 router send the appropriate ICMP Packet Too Big Messages. 380 4.5. Checksum Management 382 Checksum management for 6to4-PMT can be implemented in one of two 383 ways. The first deployment model is based on the stateless 6to4-PMT 384 operational mode. In this case, checksum modifications are made 385 using the method described in [RFC3022] section 4.2. The checksum is 386 modified to match the parameters of the translated address of the 387 source 6to4-PMT host. In the second deployment model where stateful 388 6to4-PMT translation is used, the vendor can implement checksum 389 neutral mappings as defined in [RFC6296]. 391 4.6. Application Layer Gateways 393 Vendors can choose to deploy ALGs on their platforms that perform 394 6to4-PMT if they so choose. No ALGs were deployed as part of the 395 open source and vendor product deployments of 6to4-PMT. In the 396 vendor deployment case, the same rules were used as with their NPTv6 397 [RFC6296] base code. 399 4.7. Routing Requirements 401 The provider would need to advertise the well-known IP address range 402 used for normal anycast 6to4 [RFC3068] operation within the local 403 IPv4 routing environment. This advertisement would attract the 6to4 404 upstream traffic to a local relay. To control this environment and 405 make sure all northbound traffic lands on a provider controlled 406 relay, the operator may filter the anycast range from being 407 advertised from customer endpoints toward the local network (upstream 408 propagation). 410 The provider would not be able to control route advertisements inside 411 the customer domain, but that use case is not in scope for this 412 document. It is likely in that case the end network/customer 413 understands 6to4 and is maintaining their own relay environment and 414 therefore would not be subject to the operators 6to4 and/or PMT 415 operation. 417 The provider would also likely want to advertise the 2002::/16 range 418 within their own network to help bridge traditional 6to4 traffic 419 within their own network (Native IPv6 to 6to4-PMT based endpoint). 420 It would also be advised that the local 6to4-PMT operator not leak 421 the well-known 6to4 anycast IPv4 prefix to neighbouring Autonomous 422 Systems to prevent PMT operation for neighbouring networks. Policy 423 configuration on the local 6to4-PMT relay can also be used to 424 disallow PMT operation should the local provider service downstream 425 customer networks. 427 4.8. Relay Deployments 429 The 6to4-PMT function can be deployed onto existing 6to4 relays (if 430 desired) to help minimize network complexity and cost. 6to4-PMT has 431 already been developed on Linux based platforms which are package 432 add-ons to the traditional 6to4 code. The only additional 433 considerations beyond normal 6to4 relay operation would include the 434 need to route specific IPv6 provider prefix ranges used for 6to4-PMT 435 operation towards peers and transit providers. 437 5. IANA Considerations 439 No IANA considerations are defined at this time. 441 6. Security Considerations 443 6to4-PMT operation would be subject to the same security concerns as 444 normal 6to4 operation. 6to4-PMT is also not plainly perceptible by 445 external hosts and local entities appear as Native IPv6 hosts to the 446 external hosts. 448 7. Acknowledgements 450 Thanks to the following people for their textual contributions and/or 451 guidance on 6to4 deployment considerations: Dan Wing, Wes George, 452 Scott Beuker, JF Tremblay, John Brzozowski, Chris Metz and Chris 453 Donley 455 Additional thanks to the following for assisting with the coding and 456 testing of 6to4-PMT: Marc Blanchet, John Cianfarani, Tom Jefferd, Nik 457 Lavorato, Robert Hutcheon and Ida Leung 459 8. References 461 8.1. Normative References 463 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 464 via IPv4 Clouds", RFC 3056, February 2001. 466 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 467 RFC 3068, June 2001. 469 8.2. Informative References 471 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 472 for IP version 6", RFC 1981, August 1996. 474 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 475 Address Translator (Traditional NAT)", RFC 3022, 476 January 2001. 478 [RFC3484] Draves, R., "Default Address Selection for Internet 479 Protocol version 6 (IPv6)", RFC 3484, February 2003. 481 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 482 Architecture", RFC 4291, February 2006. 484 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 485 Message Protocol (ICMPv6) for the Internet Protocol 486 Version 6 (IPv6) Specification", RFC 4443, March 2006. 488 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 489 Infrastructures (6rd) -- Protocol Specification", 490 RFC 5969, August 2010. 492 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 493 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 494 June 2011. 496 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 497 Translation", RFC 6296, June 2011. 499 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 500 Stack Lite Broadband Deployments Following IPv4 501 Exhaustion", RFC 6333, August 2011. 503 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 504 RFC 6343, August 2011. 506 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 507 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 508 Space", BCP 153, RFC 6598, April 2012. 510 Authors' Addresses 512 Victor Kuarsingh (editor) 513 Rogers Communications 514 8200 Dixie Road 515 Brampton, Ontario L6T 0C1 516 Canada 518 Email: victor.kuarsingh@gmail.com 519 URI: http://www.rogers.com 521 Yiu L. Lee 522 Comcast 523 One Comcast Center 524 Philadelphia, PA 19103 525 U.S.A. 527 Email: yiu_lee@cable.comcast.com 528 URI: http://www.comcast.com 530 Olivier Vautrin 531 Juniper Networks 532 1194 N Mathilda Avenue 533 Sunnyvale, CA 94089 534 U.S.A. 536 Email: olivier@juniper.net 537 URI: http://www.juniper.net