idnits 2.17.1 draft-durand-dual-stack-lite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2008) is 5771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-droms-softwires-snat-00 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Durand 3 Internet-Draft Comcast 4 Intended status: Informational July 7, 2008 5 Expires: January 8, 2009 7 Dual-stack lite broadband deployments post IPv4 exhaustion 8 draft-durand-dual-stack-lite-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 8, 2009. 35 Abstract 37 The common thinking for the last 10+ years has been that the 38 transition to IPv6 will be based on the dual stack model and that 39 most things would be converted this way before we ran out of IPv4. 41 It has not happened. The IANA free pool of IPv4 addresses will be 42 depleted soon, way before any significant IPv6 deployment will have 43 occurred. 45 This document revisits the dual-stack model and introduces the dual- 46 stack lite technology aimed at better aligning the cost and the 47 benefits of deploying IPv6. It will provide the necessary bridge 48 between the two protocols, offering an evolution path of the Internet 49 post IANA IPv4 depletion. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements language . . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. IPv4 exhaustion coming sooner than expected . . . . . . . 3 57 2. Handling the legacy . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Legacy edges of the Internet for broadband customers . . . 4 59 2.2. Content and Services available on the Internet . . . . . . 4 60 2.3. Additional impact on new broadband deployment . . . . . . 4 61 2.4. Burden on service providers . . . . . . . . . . . . . . . 4 62 2.5. The dual-stack lite model: IPv4 address sharing on top 63 of IPv6-only provisioning . . . . . . . . . . . . . . . . 4 64 2.6. Domain of application . . . . . . . . . . . . . . . . . . 5 65 3. Expectations for dual-stack lite deployment . . . . . . . . . 5 66 3.1. Expectations for home gateway based scenarios . . . . . . 5 67 3.2. Expectations for devices directly connected to the 68 broadband service provider network . . . . . . . . . . . . 6 69 3.3. Application expectations . . . . . . . . . . . . . . . . . 6 70 3.4. Service provider network expectations . . . . . . . . . . 6 71 4. Dual-stack lite . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Dual-stack lite interface . . . . . . . . . . . . . . . . 6 73 4.2. Dual-stack lite device . . . . . . . . . . . . . . . . . . 7 74 4.3. Dual-stack lite home router . . . . . . . . . . . . . . . 7 75 4.4. Discovery of the dual-stack lite carrier-grade NAT 76 device . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.5. Dual-stack lite carrier-grade NAT . . . . . . . . . . . . 8 78 4.6. Carrier-grade NAT considerations . . . . . . . . . . . . . 8 79 5. Multicast considerations . . . . . . . . . . . . . . . . . . . 8 80 6. Comparison with an architecture with multiple-layers of NAT . 8 81 7. Comparison with NAT-PT (or its potential replacements) . . . . 9 82 8. Comparison with DSTM . . . . . . . . . . . . . . . . . . . . . 10 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 12.1. Normative references . . . . . . . . . . . . . . . . . . . 11 88 12.2. Informative references . . . . . . . . . . . . . . . . . . 11 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 Intellectual Property and Copyright Statements . . . . . . . . . . 13 92 1. Introduction 94 This memo will present views on deployments post IPv4 exhaustion and 95 some of the necessary technologies to achieve it. The views 96 expressed are the author personal opinions and in no way imply that 97 Comcast is going to deploy the technologies described here. 99 1.1. Requirements language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 1.2. Terminology 107 This document makes a distinction between a dual-stack capable and a 108 dual-stack provisioned device. The former is a device that has code 109 that implements both IPv4 and IPv6, from the network layer to the 110 applications. The later is a similar device that has been 111 provisioned with both an IPv4 and an IPv6 address on its 112 interface(s). This document will also further refine this notion by 113 distinguishing between interfaces provisioned directly by the service 114 provider from those provisioned by the customer. 116 1.3. IPv4 exhaustion coming sooner than expected 118 Global public IPv4 addresses coming from the IANA free pool are 119 running out faster than many predicted a few years ago. The current 120 model shows that exhaustion could happen as early as 2010 or 2011. 121 See http://ipv4.potaroo.net for more details. Those projection are 122 based on the assumption that tomorrow is going to be very similar to 123 today, ie looking at recent address consumption figures is a good 124 indicator of future consumption patterns. This of course, does not 125 take into account any new large scale deployment of IP technology or 126 any human reaction when facing an upcoming shortage. 128 The prediction of the exact date of exhaustion of the IANA free pool 129 is outside the scope of this document, however one conclusion must be 130 drawn from that study: there will be in the near future a point where 131 new global public IPv4 addresses will not be available in large 132 enough quantity thus any new broadband deployment may have to 133 consider the option of not provisioning any (global) IPv4 addresses 134 to the WAN facing interface of edge devices. However, the classic 135 IPv6 deployment model known as "dual stack provisioning" can be a non 136 starter in such environments. 138 2. Handling the legacy 140 2.1. Legacy edges of the Internet for broadband customers 142 Broadband home customers have a mix and match of IP enable devices. 143 The most recent operating systems (eg Windows Vista or MacOS-X) can 144 operate in an IPv6-only environment, however most of the legacy one 145 can't. It has been reported, for example, that windows XP cannot 146 process DNS requests over IPv6 transport. Expecting broadband 147 customers to massively upgrade their software (and in most cases the 148 corresponding hardware) to deploy IPv6 is a very tall order. 150 2.2. Content and Services available on the Internet 152 IPv6 deployment has been very long to take off, so the current 153 situation is that almost none of the contents and services available 154 on the Internet are accessible over IPv6. This will probably change 155 in the future, but for now, one has to make the assumption that most 156 of the traffic generated by (and to) broadband customers will be sent 157 to (and originated by) IPv4 nodes. 159 2.3. Additional impact on new broadband deployment 161 Even when considering new, green field, broadband deployments, such 162 as always-on 4G, service providers have to face the same situation as 163 described above, that is, contents and services available on the 164 Internet are, today, generally accessible only over IPv4 and not 165 IPv6. This makes adoption of IPv6 for green field deployment 166 difficult. Solutions like NAT-PT, now deprecated, do not provide, as 167 of today, a satisfying and scalable answer. 169 2.4. Burden on service providers 171 As a conclusion, broadband service providers may be faced with the 172 situation where they have IPv4 customers willing to communicate with 173 IPv4 servers on the Internet but may not have any IPv4 addresses left 174 to assign to them... However, without some form of backward 175 compatibility with IPv4, the cost and the benefits of deploying IPv6 176 are not a aligned, making incremental IPv6 deployment very difficult. 178 2.5. The dual-stack lite model: IPv4 address sharing on top of IPv6- 179 only provisioning 181 The core idea behind dual-stack lite is to move from a deployment 182 model where a globally unique IPv4 address is provisoned per customer 183 and shared among several devices within that customer premise to a 184 deployment model where that globally unique IPv4 address is shared 185 among many customers. Instead of relying on a cascade of NATs, the 186 dual-stack lite model is build on IPv4 over IPv6 tunnels to cross the 187 network to reach a carrier-grade IPv4-IPv4 NAT. As such, it simplify 188 the management of the service provider network and provide the 189 customer the benefit of having only one layer of NAT. The additional 190 benefit of this model is to gradually introduce IPv6 in the Internet 191 by making it virtually backward compatible with IPv4. 193 2.6. Domain of application 195 The dual-stack lite deployment model has been designed with broadband 196 networks in mind. It is certainly applicable to other domains 197 although the author does not make any specific claim of suitability. 199 3. Expectations for dual-stack lite deployment 201 3.1. Expectations for home gateway based scenarios 203 This section mainly address home style networks characterized by the 204 presence of a home gateway. 206 Legacy, unmodified, IPv4-only devices inside the home network are 207 expected to keep using RFC1918 address space, a-la 192.168.0.0/16 and 208 should be able to access the IPv4 Internet in a similar way they do 209 it today through a home gateway IPv4 NAT. 211 Unmodified IPv6 capable devices are expected to be able to reach 212 directly the IPv6 Internet, without going through any translation. 213 It is expected that most IPv6 capable devices will also be IPv4 214 capable and will simply be configured with an IPv4 RFC1918 style 215 address within the home network and access the IPv4 Internet the same 216 way as the legacy IPv4-only devices within the home. 218 IPv6-only devices that do not include code for an IPv4 stack are 219 outside of the scope of this document. 221 It is expected that the home gateway is either software upgradable, 222 replaceable or provided by the service provider as part of a new 223 contract. Outside of early IPv6 deployments done prior to IPv4 224 exhaustion using some form of tunnel, this is pretty much a 225 requirement to deploy any IPv6 service to the home. It is expected 226 that this home gateway will be a dual stack capable device that would 227 only be provisioned with IPv6 on its WAN side. IPv4 and IPv6 are 228 expected to be locally provisonned on any LAN interfaces of such 229 devices. IPv4 addresses on such interfaces are expected to be 230 RFC1918. The key point here is that the service provider will not 231 provision any IPv4 addresses for those home gateway devices. 233 3.2. Expectations for devices directly connected to the broadband 234 service provider network 236 Under this deployment model, devices directly connected to the 237 broadband service provider network without the presence of a home 238 gateway will have to be dual stack capable devices. The service 239 provider facing interface(s) of such device will only be provisioned 240 with IPv6. IPv4 may or may not be provisioned locally on other 241 interfaces of such devices. Similarly to the above section, the key 242 point here is that the service provider will not provision any IPv4 243 addresses for those directly connected devices. 245 It is expected that directly connected devices will implement code to 246 support the dual-stack lite functionality. The minimum support 247 required is an IPv4 over IPv6 tunnel. 249 IPv4-only devices and IPv6-only devices are specifically left out of 250 scope for this document. It is expected that most modern device 251 directly connected to the service provider network would not have 252 memory constraints to implement both stack. 254 3.3. Application expectations 256 Most applications that today work transparently through an IPv4 home 257 gateway NAT should keep working the same way. However, it is not 258 expected that applications that requires specific port assignment or 259 port mapping from the NAT box will keep working. Details and 260 recommendations for application behavior are outside the scope of 261 this document and should be discussed in the behave working group. 263 3.4. Service provider network expectations 265 The dual-stack lite deployment model is based on the notion that IPv4 266 addresses will be shared by several customers. This implies that the 267 NAT functionality will move from the home gateway to a device hosted 268 within the service provider network. It is important to observe that 269 this functionality does not have to be performed deep in the core of 270 the network and that it might be better implemented close to the 271 aggregation point of customer traffic. 273 4. Dual-stack lite 275 4.1. Dual-stack lite interface 277 A dual-stack lite interface on a dual-stack capable device is modeled 278 as a point to point IPv4 over IPv6 tunnel. Its configuration 279 requires that the device is provisioned with IPv6 but does not 280 require it to be provisioned with a global IPv4 by the service 281 provider. 283 Any locally unique IPv4 address can be configure on the local side of 284 the dual-stack lite tunnel. It is recommended that dual-stack lite 285 implementations use simply 0.0.0.1. 287 Note: A future version of this draft may request IANA to reserve an 288 IPv4 address for this usage. 290 The tunnel end point of a dual-stack lite interface is the IPv6 291 address of a dual-stack lite carrier-grade NAT within the service 292 provider network. 294 A dual-stack lite interface is not required to maintain any state 295 beside the IPv6 address of the remote tunnel end point and the local 296 IPv4 address assigned to the local tunnel end point. 298 4.2. Dual-stack lite device 300 A dual-stack lite device is a dual-stack capable device implementing 301 a dual-stack lite interface. In the absence of better routing 302 information, a dual-stack lite device will configure a static IPv4 303 default route over the dual-stack lite interface. 305 4.3. Dual-stack lite home router 307 A dual-stack lite home router is a dual-stack capable home router 308 implementing a dual-stack lite interface layered on top of its WAN 309 interface. In the absence of better routing information, a dual- 310 stack lite home router will configure a static IPv4 default route 311 over the dual-stack lite interface. 313 Note: a dual-stack lite home router SHOULD NOT perform any IPv4 314 address translation. It should simply act as a router and pass 315 packets from the LAN to the dual-stack lite interface and back 316 without changing any address. The dual-stack lite router will have 317 to take into account the lowered MTU of the tunnel and possibly 318 perform IPv4 fragmentation. 320 4.4. Discovery of the dual-stack lite carrier-grade NAT device 322 The IPv6 address of a dual-stack lite carrier-grade NAT device can be 323 configured on a dual-stack lite interface using a variety of way, 324 ranging from out-of-band mechanism, manual configuration, a to-be- 325 defined DHCPv6 option or a to-be-defined IPv6 router advertisement. 326 It is expected that over time all the above methods and maybe more 327 will be defined. The requirements and specifications of such methods 328 are out of scope for this document. 330 4.5. Dual-stack lite carrier-grade NAT 332 A dual-stack lite carrier grade NAT is a special IPv4 to IPv4 NAT 333 deployed within the service provider network. It is reachable by 334 customers via a series of point to point IPv4 over IPv6 tunnels. 336 A dual-stack lite carrier-grade NAT uses a combination of the IPv6 337 source address of the tunnel and the inner IPv4 source address to 338 establish and maintain the IPv4 NAT mapping table. 340 A dual-stack lite carrier-grade NAT does not have to perform any 341 IPv6-IPv6, IPv6-IPv4 or IPv4-IPv6 NAT. 343 A dual-stack lite carrier-grade NAT should implement a full-cone NAT 344 with hair-pinning (symmetric NAT may break applications using several 345 simultaneous connections). It will have to implement the ALGs to 346 support the classic applications. However, manual port forwarding or 347 UPnP may or may not be supported. 349 4.6. Carrier-grade NAT considerations 351 Because IPv4 addresses will be share among customers and potentially 352 a large address space reduction factor may be applied, in average, 353 only a limited number of TCP or UDP port numbers will be available 354 per customer. This means that applications opening a very large 355 number of TCP ports may have a harder time to work. For example, it 356 has been reported that a very well know web site was using AJAX 357 techniques and was opening up to 69 TCP ports per web page... If we 358 make the hypothesis of an address space reduction of a factor 100 359 (one IPv4 address per 100 customers), and 65k ports per IPv4 360 addresses available, that makes a total of 650 ports available 361 simultaneously to be shared among the various devices behind the 362 dual-stack lite tunnel end-point. 364 5. Multicast considerations 366 This document only describes unicast IPv4 as IPv4 Multicast is not 367 widely deployed in broadband networks. Some multicast IPv4 368 considerations might to be discussed as well in a future revision of 369 this document. 371 6. Comparison with an architecture with multiple-layers of NAT 373 An alternative architecture could consist on layering multiple levels 374 of IPv4-IPv4 NAT toward the edges of the service provider network. 375 Such architecture has a key advantage: it would work with any 376 existing IPv4 home gateway. However, it would have a number of 377 drawbacks: 379 o Each NAT device in the path will have its own application level 380 gateways, increasing the odds of failure or miss-configuration. 382 o The larger private IPv4 address space available today is Net 383 10.0.0.0/8. It can in theory accommodate for about 16 million 384 addresses, in practice, with an 80% allocation efficiency, it can 385 address about 13 million devices. This may not be enough for 386 existing and future large scale deployments, thus multiple 387 overlapping copies of Net 10 might have to be used simultaneously. 388 This in itself create more complexity: 390 * If multiple copies of Net 10 are in use, network 391 troubleshooting gets more difficult. One first need to figure 392 out in which Net 10 realm the customer is before sending a ping 393 to a home gateway to test it. This means that provisioning 394 systems need to be modified to include this information. 396 * Multiple overlapping copies of Net 10 often intersect in some 397 places with routers and firewalls. The configuration of such 398 devices need to carefully take into accounts the overlapping 399 address space. Debugging problems created by miss- 400 configuration can be time consuming. 402 o Both legacy customers with global IPv4 addresses and new customers 403 with private IPv4 addresses may be connected to the same 404 aggregation router. That router will have to make the decision to 405 send packets directly to the Internet or via a translator based on 406 the source address of those packets, which is known as source- 407 based routing. Although not impossible to implement, this adds 408 complexity to the management of the network. 410 None of the issues described above are show stoppers, but put 411 together, they seriously increase the complexity of the management of 412 the network. 414 7. Comparison with NAT-PT (or its potential replacements) 416 NAT-PT [RFC2766] deals with the translation from IPv6 to IPv4 and 417 vice versa. As such, it would not help solving the problem of 418 offering IPv4 service to legacy IPv4 hosts. NAT-PT is targeted at 419 green field IPv6 deployments, allowing them to access services and 420 content on the IPv4 Internet. In that sense, NAT-PT could be in 421 competition with dual-stack lite for green field deployment of new 422 devices directly connected to the broadband service provider network. 424 In this situation, NAT-PT has the advantage of enabling to remove 425 entirely the IPv4 stack on edge devices. This may be critical on 426 sensor type devices with a very small memory footprint. However, it 427 is unclear if such devices really need to have access to the whole 428 global IPv4 Internet in the first place or if they only need to 429 communicate with servers that can be made IPv6 enable. 431 In the more general case, dual-stack lite has several advantages over 432 NAT-PT: 434 o Dual-stack lite does not require any hack to the DNS. In other 435 words, there is no need to synthesize fake AAAA records to 436 represent IPv4 addresses. This make DNSsec works more reliably. 438 o Because of the DNS ALG hack, NAT-PT places restriction on the 439 topology, in most cases requiring that all exiting traffic go 440 through a single point of contention. Because there is no DNS ALG 441 with dual-stack lite and because each dual-stack lite device can 442 be directed independently to a different dual-stack lite NAT, the 443 dual-stack lite architecture can scale better. 445 o ALG sometimes need to manipulate literal IP address in the payload 446 of packets. In the case of an IPv4-IPv4 NAT, this is a simple 32 447 bit field replacement. In the case of IPv6-IPv4 (or IPv4-IPv6) 448 NAT, a 128 bit field need to be substituted by a 32 bit field (or 449 vice versa). This makes NAT-PT ALG more complex than dual-stack 450 lite NAT ALG. 452 For more detail on NAT-PT related issues, see [RFC4966]. 454 8. Comparison with DSTM 456 DSTM [I-D.bound-dstm-exp] was adressing IPv6 backward compatibility 457 with IPv4 by providing a temporary IPv4 address to dual-stack nodes. 458 Connectivity was also provided by the way of IPv4 over IPv6 tunnels. 459 However, DSTM was relying on nodes acquiring and releasing IPv4 460 addresses on a need to have basis. It is the author opinion that 461 such mechanism may not provide the necessary savings in address space 462 for large scale broadband deployments. 464 9. Acknowledgements 466 The author would like to acknowledge the role of Mark Townsley for 467 his input on the overall architecture of this technology by pointing 468 this work in the direction of [I-D.droms-softwires-snat]. Also to be 469 acknowledged are the many discussions with a number of people 470 including Shin Miyakawa, Katsuyasu Toyama, Akihide Hiura, Takashi 471 Uematsu, Tetsutaro Hara, Yasunori Matsubayashi, Ichiro Mizukoshi. 472 The auhor would also like to thank David Ward, Jari Arkko, Thomas 473 Narten and Geoff Huston for their constructive feedback. 475 10. IANA Considerations 477 This draft does not request any IANA action. 479 11. Security Considerations 481 Security issues associated with NAT have long been documented. See 482 [RFC2663] and [RFC2993]. 484 However, moving the NAT functionality from the home gateway to the 485 core of the service provider network and sharing IPv4 addresses among 486 customers create additional requirements when logging data for abuse 487 treatment. With any architecture including a carrier-grade NAT, IPv4 488 addresses and a timestamps are no longer sufficient to identify a 489 particular broadband customer. Additional information like TCP port 490 numbers will be be required for that purpose. 492 12. References 494 12.1. Normative references 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 12.2. Informative references 501 [I-D.bound-dstm-exp] 502 Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism 503 (DSTM)", draft-bound-dstm-exp-04 (work in progress), 504 October 2005. 506 [I-D.droms-softwires-snat] 507 Droms, R. and B. Haberman, "Softwires Network Address 508 Translation (SNAT)", draft-droms-softwires-snat-00 (work 509 in progress), February 2008. 511 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 512 Translator (NAT) Terminology and Considerations", 513 RFC 2663, August 1999. 515 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 516 Translation - Protocol Translation (NAT-PT)", RFC 2766, 517 February 2000. 519 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 520 November 2000. 522 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 523 Address Translator - Protocol Translator (NAT-PT) to 524 Historic Status", RFC 4966, July 2007. 526 Author's Address 528 Alain Durand 529 Comcast 530 1500 Market st 531 Philadelphia, PA 19102 532 USA 534 Email: alain_durand@cable.comcast.com 536 Full Copyright Statement 538 Copyright (C) The IETF Trust (2008). 540 This document is subject to the rights, licenses and restrictions 541 contained in BCP 78, and except as set forth therein, the authors 542 retain all their rights. 544 This document and the information contained herein are provided on an 545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 547 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 548 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 549 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Intellectual Property 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org.