idnits 2.17.00 (12 Aug 2021) /tmp/idnits51976/draft-bdgks-arin-shared-transition-space-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2011) is 3890 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-arkko-ipv6-only-experience has been published as RFC 6586 == Outdated reference: draft-donley-nat444-impacts has been published as RFC 7021 == Outdated reference: A later version (-05) exists of draft-ietf-6man-rfc3484-revise-04 == Outdated reference: draft-ietf-behave-lsn-requirements has been published as RFC 6888 == Outdated reference: draft-ietf-v6ops-6to4-to-historic has been published as RFC 7526 == Outdated reference: A later version (-08) exists of draft-shirasaki-isp-shared-addr-06 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-04 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-06 == Outdated reference: draft-weil-shared-transition-space-request has been published as RFC 6598 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Barber 3 Internet-Draft Cox Communications 4 Intended status: Informational O. Delong 5 Expires: March 22, 2012 Hurricane Electric 6 C. Grundemann 7 CableLabs 8 V. Kuarsingh 9 Rogers Communications 10 B. Schliesser 11 Cisco Systems 12 September 19, 2011 14 ARIN Draft Policy 2011-5: Shared Transition Space 15 draft-bdgks-arin-shared-transition-space-03 17 Abstract 19 This memo discusses the applicability of a Shared Transition Space, 20 an IPv4 prefix designated for local use within service provider 21 networks during the period of IPv6 transition. This address space 22 has been proposed at various times in the IETF, and more recently 23 come to consensus within the ARIN policy development community where 24 it was recommended for adoption as Draft Policy 2011-5. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 22, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Intended Use of Shared Transition Space . . . . . . . . . 5 60 2.1.1. CGN . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1.2. SP Services & Infrastructure . . . . . . . . . . . . . 5 62 2.1.3. Note of Caution . . . . . . . . . . . . . . . . . . . 5 63 2.2. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.2.1. Global Unicast Addresses . . . . . . . . . . . . . . . 6 65 2.2.2. Private . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.2.3. Class E . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.2.4. Prefix Squatting . . . . . . . . . . . . . . . . . . . 7 68 2.2.5. Regional Re-use of Allocated Prefix . . . . . . . . . 8 69 2.2.6. Consortium . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Analysis of Benefits . . . . . . . . . . . . . . . . . . . . . 9 71 3.1. Continued Operation Post-exhaustion . . . . . . . . . . . 9 72 3.2. Delayed Need for CGN Deployment . . . . . . . . . . . . . 9 73 3.3. Recovery of Existing Addresses . . . . . . . . . . . . . . 9 74 3.3.1. Re-deployment Where Needed . . . . . . . . . . . . . . 10 75 3.3.2. Return or Transfer . . . . . . . . . . . . . . . . . . 10 76 3.4. Impact on Allocations of RIR Inventory . . . . . . . . . . 10 77 3.5. Benefit of Standardization . . . . . . . . . . . . . . . . 10 78 3.6. IPv6 Deployments . . . . . . . . . . . . . . . . . . . . . 11 79 4. Analysis of Detractors' Arguments . . . . . . . . . . . . . . 11 80 4.1. It Breaks . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.1.1. NAT is Bad . . . . . . . . . . . . . . . . . . . . . . 11 82 4.1.2. Breaks Assumptions about Address Scope . . . . . . . . 11 83 4.1.2.1. 6to4 . . . . . . . . . . . . . . . . . . . . . . . 11 84 4.1.3. Potential Misuse as Private Space . . . . . . . . . . 12 85 4.2. It's Not Needed . . . . . . . . . . . . . . . . . . . . . 12 86 4.2.1. Nobody Will Use It . . . . . . . . . . . . . . . . . . 12 87 4.2.2. ISPs Are Not Actually Growing . . . . . . . . . . . . 12 88 4.2.3. RIR IPv4 Inventory is Not Actually Exhausted . . . . . 13 89 4.2.4. ISP IPv4 Inventory is Not Actually Exhausted . . . . . 13 90 4.3. Address Inventory . . . . . . . . . . . . . . . . . . . . 13 91 4.3.1. Shared Transition Space Uses Up Address Inventory . . 13 92 4.3.2. /10 is not Enough . . . . . . . . . . . . . . . . . . 14 93 4.4. IPv6 Arguments . . . . . . . . . . . . . . . . . . . . . . 14 94 4.4.1. Use IPv6 Instead . . . . . . . . . . . . . . . . . . . 14 95 4.4.2. Delay of IPv6 Deployment . . . . . . . . . . . . . . . 14 97 5. ARIN Draft Policy 2011-5 . . . . . . . . . . . . . . . . . . . 14 98 5.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 5.1.1. Shared Address Space . . . . . . . . . . . . . . . . . 15 100 5.1.2. Proposal . . . . . . . . . . . . . . . . . . . . . . . 15 101 5.2. Policy Text . . . . . . . . . . . . . . . . . . . . . . . 17 102 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 105 9. Informative References . . . . . . . . . . . . . . . . . . . . 19 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 108 1. Introduction 110 As the Internet community approaches exhaustion of unallocated IPv4 111 numbers, the value of globally unique addresses is becoming manifest. 112 More than ever network operators recognize the need to transition to 113 the IPv6 address family. However, the immediate necessity of 114 continued IPv4 connectivity poses a near-term challenge - without 115 adequate IPv4 resources, most network operators must deploy more 116 efficient addressing architectures and many must deploy address- 117 sharing technologies. 119 In order to facilitate these operators' need for near-term IPv4 120 connectivity, [I-D.weil-shared-transition-space-request] proposes the 121 reservation of a /10 IPv4 prefix for use in Service Provider (SP) 122 networks. Referred to as Shared Transition Space, this address block 123 would facilitate SP deployment of non-unique address plans that do 124 not conflict with traditional Private [RFC1918] address space. By 125 using the Shared Transition Space operators may deploy CGN 126 [I-D.ietf-behave-lsn-requirements] internal networks, extranet 127 [RFC4364] communities, and/or SP-local services without consuming 128 Global Unicast Addresses. 130 However, given the Feb 2011 depletion of the IANA Free Pool inventory 131 [NRO-IANA-exhaust] it is not currently possible for the IANA to 132 reserve an IPv4 /10 prefix as recommended in 133 [I-D.weil-shared-transition-space-request]. Thus the ARIN community 134 has proposed in Draft Policy [ARIN-2011-5] the reservation of a 135 Shared Transition Space from the ARIN inventory of unallocated IPv4 136 numbers. After much discussion by the ARIN community, [ARIN-2011-5] 137 reached consensus and was recommended by the ARIN Advisory Council 138 for approval by the ARIN Board of Trustees. 140 Following the community's recommendation of [ARIN-2011-5] the ARIN 141 Board requested clarification from the IAB with regard to 142 responsibilities outlined in [RFC2860]. The ARIN Board received a 143 response in [IAB-response] indicating that the IETF holds 144 responsibility for the reservation of specialized address blocks. 145 Thus, the ARIN Board believes that it is not within ARIN's authority 146 to unilaterally make specialized allocations of the sort proposed in 147 Draft Policy 2011-5. [PPML-022778] 149 This memo explains the intended use and discusses the merits and 150 drawbacks of using Shared Transition Space. 152 2. Applicability 153 2.1. Intended Use of Shared Transition Space 155 The Shared Transition Space is intended for use by service providers 156 and should not be thought of as additional RFC1918 space. There are 157 a number of specific use-cases for the Shared Transition Space. This 158 section discusses the primary scenarios envisioned at the time of 159 this writing. Equipment vendors and non-ISP network operators should 160 be aware that using the Shared Transition Space outside of its 161 intended scope may result in unpredictable behavior. 163 2.1.1. CGN 165 The primary use-case for the Shared Transition Space will be 166 deployment in CGN [I-D.ietf-behave-lsn-requirements] internal 167 networks. A key benefit of CGN is the ability to share a smaller 168 number of Global Unicast Addresses (GUA) amongst a larger number of 169 end-sites. 171 In one CGN deployment scenario sometimes referred to as NAT444 172 [I-D.shirasaki-nat444], the CGN internal network is numbered with 173 IPv4 addresses that are not globally routed while the end-sites are 174 numbered with Private [RFC1918] addresses. In this scenario the 175 Shared Transition Space will be used to provide contextually unique 176 IPv4 addresses to end-site CPE devices and intermediate 177 infrastructure. [I-D.shirasaki-nat444-isp-shared-addr] 179 2.1.2. SP Services & Infrastructure 181 In networks that contain local services (such as nameservers, content 182 repositories or caches, etc) the Shared Transition Space will offer 183 an alternative to GUA. For instance, video content servers that are 184 available only to customers directly connected to the SP network 185 might be addressed from the Shared Transition Space, preserving GUA 186 for services that require global connectivity. Where these services 187 are accessed by customers who have their own IPv4-only equipment, use 188 of the Shared Transition Space will reduce or eliminate the need for 189 NAT. Similarly, those infrastructure elements which touch IPv4-only 190 customer-managed equipment could also be numbered from the Shared 191 Transition Space. In cases where the provider manages both 192 endpoints, IPv6 should be used. 194 2.1.3. Note of Caution 196 In any case, care must be taken to ensure the Shared Transition Space 197 is not used in scenarios where routing may be ambiguous. For 198 instance, when multiple provider networks may be simultaneously 199 reachable the use of Shared Transition Space might result in address 200 conflicts etc. Conversely, operators may choose to allow (not 201 filter) ICMP messages from the Shared Transition Space in order to 202 enable Path MTU Discovery etc. This topic requires further 203 investigation so that best practices may be developed. 205 2.2. Alternatives 207 A number of possible alternatives to Shared Transition Space have 208 been proposed and/or discussed by the Internet community. See, for 209 instance, [RFC6319] for a discussion of alternatives and potential 210 issues. This section outlines these possible alternatives and 211 briefly discusses their applicability. 213 2.2.1. Global Unicast Addresses 215 Every discussion of the Shared Transition Space begins with an 216 assumption that Global Unicast Addresses (GUA) are a preferable 217 choice for numbering. This is almost always technically true. 218 However, given the fundamental driver of IPv4 address exhaustion, GUA 219 is not a pragmatic alternative to the Shared Transition Space. 221 Additionally, if various organizations use various GUA ranges to 222 number CGN zones, it will be difficult for other networks and/or 223 systems to deterministically know if the endpoints are using true 224 Internet reachable IPs, or if the source network may be using them as 225 CGN zone space. This situation would likely lead to additional 226 technical issues during various leakage conditions, filter rule 227 issues (routing) and for CDN or other third party providers who may 228 be present within the source network, to name a few. 230 2.2.2. Private 232 In each of the use-cases for Shared Transition Space, it may be 233 possible to instead use Private [RFC1918] address space. In 234 situations where all endpoints in the network are managed by a single 235 organization, this may be a viable option. However when end-sites 236 are administered by different organizations and/or individuals, the 237 possibility of address conflict becomes a significant risk to 238 operations. Private [RFC1918] address space is not generally 239 intended to be used for purposes which cross administrative domains. 240 Further, these recommendations involve use of the Shared Transition 241 Space to provide services in one administrative domain to leaf 242 networks which are generally single-homed to the serving 243 administrative domain. This is also a significant difference from 244 the intent of Private [RFC1918] address space. 246 A study of DNS traffic [v6ops-msg06187] has shown that effectively 247 all of the existing Private [RFC1918] address space is currently 248 being used by end-sites attached to the Internet. While individual 249 network environments may vary in this regard, most SP operators face 250 the risk that their use of Private address space will conflict with 251 their customer end-sites. defined private space is not generally 252 intended to be used for purposes which cross administrative domains. 254 In the event of conflict, it is possible that the end-site CPE will 255 fail and/or not function correctly. Some CPE implementations are 256 known to support overlapping addresses on the "inside" and "outside" 257 interfaces, however many others are known to fail under such 258 circumstances. For SP operators, the Shared Transition Space offers 259 a less risky alternative to GUA that retains the benefit of non- 260 conflict. 262 Also, the use of Private [RFC1918] address space on interfaces and 263 hosts often causes default behaviors on such hosts which may not be 264 desirable when the endpoint is actually connected to the Internet. 265 There are often behavioral expectations for Internet connected 266 endpoints, regardless of them being subject to a NAT. 268 Incorrect affiliation of the WAN side interface being in a 269 "protected" zone and/or on a trusted network may not be desirable. 270 With NAT444 deployments, it is important that the endpoint (i.e. 271 CPE) behave like any other Internet node. One example of this from 272 our testing was observed behaviors where some CPEs did not filter 273 and/or firewall correctly when Private [RFC1918] address space was 274 used on both WAN and LAN interfaces. 276 2.2.3. Class E 278 One proposed alternative to Shared Transition Space is the re- 279 classification and use of the 240.0.0.0/4 "Class E" address space as 280 unicast. This has been proposed, for instance, by 281 [I-D.fuller-240space] and [I-D.wilson-class-e]. While this 282 alternative might be possible in tightly constrained environments, 283 where all of the network elements are known to support Class E 284 address space, it is not generally useful in the use-cases described 285 above. At this time, a significant number of IPv4 stack 286 implementations treat the Class E address space as reserved and will 287 not route, forward, and/or originate traffic for that range. For 288 example, [CISCO] states that: "No addresses are allowed with the 289 highest-order bits set to 1111." For the scenarios described herein, 290 it should be noted that this alternative would create additional SP 291 dependencies on customer selected CPE support for Class E addressing. 293 2.2.4. Prefix Squatting 295 An unfortunate alternative to the Shared Transition Space is "prefix 296 squatting", in which the operator re-uses another organization's IPv4 297 allocation for their own numbering needs. When this approach results 298 in the other organization's prefix being announced globally by the 299 "squatting" operator, it is often referred to as "prefix hijacking". 300 However, this discussion is focused on scenarios in which the prefix 301 is not announced globally but is, rather, used for internal numbering 302 only. 304 In this scenario, the allocation may not be routed globally by the 305 legitimate address holder, making it attractive for such purposes. 306 Or it may be routed but "uninteresting" to the SP network's 307 endpoints. In either case there is a potential for conflict in the 308 event that any end-site actually wishes to communicate with the 309 legitimate address holder. Indeed, various RIRs attempt to discover 310 and "recycle" abandoned or unused IPv4 address space, making it more 311 likely that such conflicts will be experienced in time. As such, 312 this alternative is to be discouraged with prejudice. 314 It is important to note that there are no behavioral advantages to 315 using "squat space" over using assigned "shared space". Both options 316 subject the CPE to the same general behaviors (GUA space, but not 317 globally reachable). The only real difference is the negative 318 impacts of squatting (as noted above) and the advantages of a 319 community coordinated and standardized prefix. 321 The primary reason that any network would be likely to adopt "prefix 322 squatting" is if they are faced with the operational realities of CGN 323 before/without the allocation of a shared transition space. 325 2.2.5. Regional Re-use of Allocated Prefix 327 Similar to "Prefix Squatting" but significantly less dangerous, this 328 alternative involves the reuse by an operator of their own address 329 allocations. In this scenario, a network operator might use the same 330 prefix for multiple "regions" and/or extranet communities. For 331 instance, in CGN deployments the operator might reuse the same GUA 332 prefix across multiple geographic regions (e.g. without announcing it 333 globally). 335 Here again, it is important to note that there are no behavioral 336 advantages gained over a "shared space" but there is the added 337 community cost of each network having to dedicate a unique block of 338 addresses to this purpose, consuming far more resources than a single 339 block of "shared space". 341 2.2.6. Consortium 343 In the event that the Internet community doesn't set aside an IPv4 344 prefix for Shared Transition Space, it is possible that a number of 345 SP operators can come together and designate an address block to be 346 "shared" amongst them for an identical purpose. This would have the 347 same technical merits as an IETF and/or RIR sponsored Shared 348 Transition Space, however it would lack the efficiency of a community 349 coordinated and standardized prefix for such purposes, gain no 350 behavioral advantages, remove the deterministic nature of managing a 351 single range and also subjects the Internet (users of the space) to 352 additional risk since any member of the consortium who has 353 contributed space could later pull out and potentially cause 354 disruptions in multiple networks. 356 3. Analysis of Benefits 358 3.1. Continued Operation Post-exhaustion 360 Availability of a Shared Transition Space helps SPs continue to meet 361 the demands of IPv4 addressing and/or connectivity post exhaustion. 362 For environments where CGN in a NAT444 scenario is necessary, 363 addresses from this space can be used to provide addressing for the 364 network between the CGN device(s) and CPE which will enable IPv4 flow 365 continuity for customers using these services. In other 366 circumstances, the shared transition space allows SPs to number 367 devices in the network which do not require global reachability 368 without the need for fulfillment thorough an RIR. 370 3.2. Delayed Need for CGN Deployment 372 If operators are required to use their individually allocated GUA 373 where "shared space" would have applied, e.g. for internal services, 374 they will face exhaustion sooner and thus be forced to deploy CGN 375 sooner as well. Operators may be able to postpone the deployment of 376 CGN by using "shared space" for internal uses, because that allows 377 more efficient use of their remaining GUA in places where global 378 uniqueness is truly mandatory. 380 Further, without this shared transition space, some service providers 381 may be forced to reclaim GUA from existing customers in order to 382 deploy CGN and address the required infrastructure. Having this 383 transition space will enable deployment of CGN where it is required, 384 in a manner that is less disruptive and with impact to fewer 385 customers. 387 3.3. Recovery of Existing Addresses 389 The shared transition space can also be used to number and reclaim 390 IPv4 addresses within provider networks which do not require global 391 reachability. This option can be used by many networks worldwide, it 392 provides an option for using currently assigned space much more 393 efficiently. 395 3.3.1. Re-deployment Where Needed 397 Operators can re-deploy recovered addresses for customers that need 398 them (including new / static / GUA customers), hosted servers, etc. 399 or to facilitate other efforts that might provide even more efficient 400 use of GUA space within the network. The freed addresses can be 401 assigned to endpoints which require IPv4 global reachablity and thus 402 help delay and/or remove the need for CGN. 404 3.3.2. Return or Transfer 406 In cases where the operator is not deploying CGN and doesn't need the 407 recovered addresses, they can be made available to others that do 408 need them for connectivity to the public IPv4 Internet. This may be 409 through voluntary return to the RIR, or through transfer to another 410 network operator. For example, in the ARIN region, there are 411 transfer mechanisms defined in the ARIN NRPM 8.3 [ARIN-NRPM-8.3]. 413 3.4. Impact on Allocations of RIR Inventory 415 While making Shared Transition Space available to the community may 416 or may not lessen the demand on the RIRs for allocations, it will 417 help ensure that the address resources which remain in inventory are 418 used most efficiently, maximizing the use of that inventory for 419 services that require Global Unicast Addresses. 421 3.5. Benefit of Standardization 423 Standardizing on a single block will help the community develop 424 standard ways of selecting, routing, filtering and managing shared 425 space. This task would be much more difficult or impractical for any 426 of the alternative options. 428 Standard internal routing policy and filtering can be applied 429 uniformly inside network environments. Additionally, exchange points 430 between networks can have standard policies applied allowing 431 operators to protect each other from CGN zone IPs leaking between 432 networks. This may not be possible with squat space since many 433 operators will not divulge what space may be used and with Private 434 [RFC1918] address space where each operator may only be able to free 435 up certain portions of the space which are not likely to be 436 consistent between networks. 438 3.6. IPv6 Deployments 440 Operators will need to grapple with the need to provide IPv4 based 441 flow continuity to customers post exhaustion. By removing the burden 442 of operators needing to find adequate IPv4 address space to meet the 443 needs that a Shared Transition Space can fulfill, they can 444 concentrate on the real task at hand: Deploying IPv6. 446 4. Analysis of Detractors' Arguments 448 4.1. It Breaks 450 4.1.1. NAT is Bad 452 NAT is understood to be less than optimal [RFC6269], especially when 453 implemented as CGN [I-D.donley-nat444-impacts]. That said, it is a 454 necessary technology for many networks and cannot be completely 455 avoided. Since the number of IPv4 Internet endpoints will exceed the 456 number of IPv4 addresses which are available for Internet 457 connectivity, NATs are needed. 459 While the authors agree that "NAT is bad", it must also be understood 460 that shared transition space does not change the fundamental 461 motivations or issues with NAT and so those problems will not be 462 discussed at length here. 464 4.1.2. Breaks Assumptions about Address Scope 466 Some host or CPE functions incorrectly assume global reachability 467 based on the type of address that is configured, potentially causing 468 issues when deployed in a NAT444 scenario. Whether an operator uses 469 this proposed Shared Transition Space or some other GUA space (e.g. 470 through squatting or reuse), the net effect on hosts and/or CPE 471 making such assumptions about reachability is identical. Conversely, 472 with an identified Shared Transition Space hosts that make these 473 mistaken assumptions can be modified to treat the identified block as 474 having restricted reachability semantics. This would not be possible 475 (or at least not nearly as easy) with the other solutions. 477 4.1.2.1. 6to4 479 Although 6to4 can break in CGN scenarios using the Shared Transition 480 Space, recent guidance suggests that it should be turned off by 481 default. [RFC6343] [I-D.ietf-v6ops-6to4-to-historic] Indeed, recent 482 versions of operating systems de-preference 6to4 addresses as 483 described in [I-D.ietf-6man-rfc3484-revise], mitigating effects from 484 incorrect 6to4 instantiation behind a firewall that obstructs its 485 function. 487 Since the volume of impacted endpoints will be low, operators can 488 likely manage the disabling of 6to4 when needed. More fundamentally, 489 broken 6to4 should not be an issue if service providers deploy (and 490 user equipment supports) native IPv6 connectivity. 492 4.1.3. Potential Misuse as Private Space 494 Shared Transition Space is intended to be used solely by Service 495 Providers for IPv4 to IPv6 transition purposes. 496 [I-D.weil-shared-transition-space-request] The value of a Shared 497 Transition Space may be diminished if commonly misused by end-sites 498 as generic Private addresses. Thus, the reservation must be clearly 499 designated for use by SPs that are providing infrastructure as 500 described herein. 502 4.2. It's Not Needed 504 4.2.1. Nobody Will Use It 506 This argument is simply incorrect. Post IPv4-exaustion, any SP that 507 wishes to continue providing IPv4 connectivity will necessarily 508 deploy network architectures and technologies that require such an 509 address space. Thus, in absense of a designated Shared Transition 510 Space, operators will use GUA space in essentially the same ways 511 described in this memo, with or without IETF or RIR acknowledgement. 513 4.2.2. ISPs Are Not Actually Growing 515 While customer growth for some ISPs has slowed, for many service 516 providers new services are growing at a faster rate than has been 517 anticipated. Wireline voice customers for example require two-way 518 communication paths to allow them to function properly. IP enabled 519 televisions is another example of devices that support video and 520 voice services and require IP addresses. The only way to maintain 521 these services, which in many cases are considered lifeline, is to 522 provide them with an IP address that is unique within the service 523 provider network. 525 Likewise, growth continues to exist in some geographical regions. 526 While some areas have slower growth, as a result of significant 527 penetration of Internet access, there are still many areas with unmet 528 needs, growing populations, or both. 530 4.2.3. RIR IPv4 Inventory is Not Actually Exhausted 532 With the IANA inventory essentially exhausted [NRO-IANA-exhaust] it 533 is only a matter of time before each of the RIRs are unable to 534 satisfy requests for IPv4 addresses. [GIH-When] In fact, the APNIC 535 has already allocated all but their final /8 of inventory 536 [APNIC-final-slash8] and is no longer making allocations larger than 537 a /22 prefix. Each of the other RIRs is on a trajectory toward 538 exhaustion in the near future. 540 4.2.4. ISP IPv4 Inventory is Not Actually Exhausted 542 While some SPs have existing inventory that will outlast the RIR 543 inventories, this is not universally true. In fact, the distribution 544 of IPv4 number resources amongst operators is highly variable (based 545 on size, history, etc) and in the worst cases is already becoming 546 problematic. 548 4.3. Address Inventory 550 4.3.1. Shared Transition Space Uses Up Address Inventory 552 While true that this Shared Transition Space will remove a block of 553 global unicast IPv4 addresses from the free pool, it must also be 554 noted that the use of the same "shared space" repeatedly across 555 multiple networks will very likely increase the available pool of 556 unique IPv4 addresses through operational efficiency. For example, 557 if just two operators use their own GUA /10, the Internet community 558 effectively loses a /9 of unique space while if both operators use 559 the same "shared" /10, the Internet community loses that single /10. 560 This benefit becomes more significant as more operators use the 561 Shared Transition Space. 563 It remains to be seen whether the reservation of a Shared Transition 564 Space will actually delay the impending exhaustion of RIRs' IPv4 565 inventory. Certainly, the availability of this Shared Transition 566 Space will satisfy a number of demands that would otherwise become 567 requests for GUA resources. However, whether this translates to an 568 actual reduction in requests is up to the RIRs and requesting 569 organizations. Regardless of the allocation of Shared Transition 570 Space, RIR IPv4 exhaustion may happen at roughly the same time. 571 However, as noted above, Shared Transition Space does provide the 572 opportunity for more efficient use of the remaining RIR IPv4 573 addresses. Additionally, the reservation of a Shared Transition 574 Space will enable continued deployment of IPv4 connectivity by SP 575 networks beyond the free pool depletion horizon; another clear 576 benefit. 578 4.3.2. /10 is not Enough 580 Although previous requests for Shared Transition Space asked for a 581 full /8, it has been determined by many operators that a /10 will in 582 fact be sufficient. A /10 provides for roughly 4 million hosts and 583 although many of the largest SPs have subscriber counts in the tens 584 of millions, none will be placing all of their subscribers behind a 585 single CGN. In the event that a /10 does not provide enough 586 addresses for an operators entire CGN deployment, it could be re-used 587 multiple times in distinct "NAT zones" or regions. 589 4.4. IPv6 Arguments 591 4.4.1. Use IPv6 Instead 593 Although IPv6 is the strategic long term answer for IPv4 address 594 exhaustion, it does not immediately solve IPv4 connectivity 595 requirements. There is an entire eco-system which exists on the 596 Internet today and is not IPv6 ready at this time 597 [I-D.arkko-ipv6-only-experience]. IPv4 flow continuity will be 598 required for at least several years. 600 Many businesses have long procurement and fulfillment cycles which 601 will need to be used to upgrade networks to support IPv6. Also, the 602 consumer (home) space is years away from being all IPv6 capable. 603 Many homes are filled with IPv4 only consumer electronics, computers, 604 TVs, accessories and other systems. 606 There are still a number of products that are either not IPv6 607 compliant, or for which the necessary criteria for being "IPv6 608 compliant" is unclear or undefined. Some examples include security 609 products, a large number of software applications, and there are 610 still production systems (both inside companies and as products) 611 being rolled out that are not IPv6 aware. 613 4.4.2. Delay of IPv6 Deployment 615 The whole Internet needs to get to IPv6 more or less at the same time 616 in order to avoid significant deployment of transition technologies. 617 This proposal may help delay some transition technology deployment 618 while IPv6 deployments move ahead. More IPv6 should mean less 619 transition technology. 621 5. ARIN Draft Policy 2011-5 622 5.1. History 624 5.1.1. Shared Address Space 626 Proposals for additional Private space date back at least to 627 [I-D.hain-1918bis] in April 2004. Some of these proposals and 628 surrounding discussion may have considered similar use-cases as 629 described herein. However, they were fundamentally intended to 630 increase the size of the [RFC1918] pool, whereas a defining 631 characteristic of Shared Transition Space is that it is distinctly 632 not part of the Private [RFC1918] address pool. 634 Rather, the Shared Transition Space is reserved for more narrow 635 deployment scenarios, specifically for use by SPs to meet the needs 636 of ongoing IPv4 connectivity during the period of IPv6 transition. 637 This key feature emerged in more recent proposals such as 638 [I-D.shirasaki-isp-shared-addr] in June 2008 where a proposal to set 639 aside "ISP Shared Space" was made. During discussion of these more 640 recent proposals, many of the salient points where commented upon, 641 including challenges with RFC1918 in the ISP NAT Zone, Avoidance of 642 IP Address Conflicts, and challenges with 240/4. 644 This effort was followed up by 645 [I-D.weil-opsawg-provider-address-space] in July 2010 which was re- 646 worked in November 2010 as 647 [I-D.weil-shared-transition-space-request]. These latter efforts 648 continued to point out the operators' need for Shared Transition 649 Space, with full acknowledgement that challenges may arise with 650 NAT444 as per [I-D.donley-nat444-impacts] and that such space does 651 not reduce the need for IPv6 deployment. 653 Most recently, following exhaustion of the IANA's /8 pool 654 [NRO-IANA-exhaust], this proposal has been discussed by various RIR 655 policy development participants. As described herein, the body of 656 ARIN policy development participants has reached consensus and 657 recommended a Shared Address Space policy for adoption [ARIN-2011-5]. 659 This history shows that operators and other industry contributors 660 have consistently identified the need for a Shared Transition Space 661 assignment, based on pragmatic operational needs. The previous work 662 has also described the awareness of the challenges of this space, but 663 points to this option as the most manageable and workable solution 664 for IPv6 transition space. 666 5.1.2. Proposal 668 The following is a brief history of the proposal for Shared Address 669 Space within ARIN, ultimately resulting in the recommendation of ARIN 670 Draft Policy 2011-5 [ARIN-2011-5]. 672 In January 2011, a policy was proposed to the ARIN policy development 673 community called ARIN-prop-127: Shared Transition Space for IPv4 674 Address Extension [ARIN-prop-127]. This policy proposal would 675 reserve an IPv4 /10 prefix by ARIN, to be shared by any Service 676 Providers who wish to use it with no further registration actions 677 required. 679 After generating much discussion (over 100 posts) on the ARIN Public 680 Policy Mailing List (PPML), the ARIN Advisory Council (AC) accepted 681 the proposal as Draft Policy 2011-5 [ARIN-AC-28Jan2011], formally 682 announced on PPML 3 February 2011 [ARIN-2011-5-AC]. 684 On 14 February 2011, ARIN staff made the following statement with 685 regard to 2011-5: "In keeping with the spirit of RFC 2860 with 686 respect to the assignment of specialized address blocks, ARIN Staff 687 will consult with the IANA and the IAB regarding implementation of 688 this draft policy." [ARIN-2011-5-Staff] 690 In the ensuing PPML discussion there was a roughly two to one ratio 691 of those clearly in support of the policy versus those clearly 692 against. ARIN Draft Policy 2011-5 was then discussed at the ARIN 693 XXVII public policy meeting on 12 April 2011. Following the 694 discussion, there was a straw poll of the room. With a total number 695 of people in the meeting room and remote of 116; in favor of it were 696 30 and against it were 15. [ARIN27.2011-5] 698 Seeing an obvious need in the service provider community, the AC 699 voted to send the Draft Policy to last call [ARIN-AC-13Apr2011] for 700 final comments 18 April through 2 May 2011. [ARIN-2011-5-LC] 701 Following a strong show of support from the operator community during 702 last call, the AC voted [ARIN-AC-19May2011] to recommend adoption of 703 2011-5 to the ARIN Board of Trustees with a vote of 10 in favor and 2 704 abstentions. [ARIN-2011-5-Rec] 706 Following this recommendation, ARIN staff consulted with the IAB and 707 IANA as committed. The IAB response [IAB-response] stated, in short, 708 that they believed the adoption of [ARIN-2011-5] was in conflict with 709 the provisions in [RFC2860] and requested that the community re- 710 review the operational and technical merits of shared transition 711 space in the IETF. That process is now underway, with this draft an 712 attempt at more fully analyzing said operational and technical 713 merits. 715 5.2. Policy Text 717 Draft Policy ARIN-2011-5 719 Shared Transition Space for IPv4 Address Extension 721 Date: 20 January 2011 723 Policy statement: 725 Updates 4.10 of the NRPM: 727 A second contiguous /10 IPv4 block will be reserved to facilitate 728 IPv4 address extension. This block will not be allocated or assigned 729 to any single organization, but is to be shared by Service Providers 730 for internal use for IPv4 address extension deployments until 731 connected networks fully support IPv6. Examples of such needs 732 include: IPv4 addresses between home gateways and NAT444 translators. 734 Rationale: 736 The Internet community is rapidly consuming the remaining supply of 737 unallocated IPv4 addresses. During the transition period to IPv6, it 738 is imperative that Service Providers maintain IPv4 service for 739 devices and networks that are currently incapable of upgrading to 740 IPv6. Consumers must be able to reach the largely IPv4 Internet 741 after exhaustion. Without a means to share addresses, people or 742 organizations who gain Internet access for the first time, or those 743 who switch providers, or move to another area, will be unable to 744 reach the IPv4 Internet. 746 Further, many CPE router devices used to provide residential or 747 small-medium business services have been optimized for IPv4 748 operation, and typically require replacement in order to fully 749 support the transition to IPv6 (either natively or via one of many 750 transition technologies). In addition, various consumer devices 751 including IP-enabled televisions, gaming consoles, medical and family 752 monitoring devices, etc. are IPv4-only, and cannot be upgraded. 753 While these will eventually be replaced with dual-stack or IPv6 754 capable devices, this transition will take many years. As these are 755 typically consumer-owned devices, service providers do not have 756 control over the speed of their replacement cycle. However, 757 consumers have an expectation that they will continue to receive IPv4 758 service, and that such devices will continue to have IPv4 Internet 759 connectivity after the IPv4 pool is exhausted, even if the customer 760 contracts for new service with a new provider. 762 Until such customers replace their Home Gateways and all IPv4-only 763 devices with IPv6-capable devices, Service Providers will be required 764 to continue to offer IPv4 services through the use of an IPv4 address 765 sharing technology such as NAT444. A recent study showed that there 766 is no part of RFC1918 space which would not overlap with some IPv4 767 gateways, and therefore to prevent address conflicts, new address 768 space is needed. 770 Service providers are currently presented with three options for 771 obtaining sufficient IPv4 address space for NAT444/IPv4 extension 772 deployments: (1) Request allocations under the NRPM; (2) share 773 address space with other providers (this proposal); or (3) use 774 address space allocated to another entity (i.e. 'squat'). Of the 775 three options, option 2 (this proposal) is preferable, as it will 776 minimize the number of addresses used for IPv4 extension deployments 777 while preserving the authority of IANA and RIRs. 779 Timetable for implementation: immediately 781 6. Acknowledgements 783 The authors would like to thank the following individuals for their 784 contributions: John Curran, David Farmer, Jeffrey Finkelstein, 785 William Herrin, and Dan Wing. 787 The authors would also like to thank the following people for their 788 review, comments, and support: Gary Buhrmaster, Chris Donley, Wes 789 George, Chris Metz, Richard Von Scherr, and Lane Wigley. 791 7. IANA Considerations 793 Upon notification by the IAB that that an address reservation should 794 be made, ARIN is willing to proceed with the implementation of its 795 Draft Policy 2011-5 which would result in ARIN reserving IPv4 /10 796 block for shared transition. The IANA is to record the allocation of 797 the IPv4 address block for this purpose. Alternatively, the IAB may 798 direct the IANA to request return of sufficient address space from 799 ARIN's available IPv4 number resource pool to allow the IANA to 800 perform this reservation directly. 802 8. Security Considerations 804 This memo makes reference to a number of deployment scenarios that 805 have unique security considerations, and the reader is advised to 806 investigate these independently. 808 While this memo does not introduce any specific technical issues that 809 may be subject to detailed security considerations, it does 810 reccommend the reservation of a new IPv4 address space that might 811 have unique properties when deployed. As such, all implementors of 812 this Shared Transition Space are encouraged to consider carefully the 813 best practices associated with the use of this space, including 814 considerations relating to filtering, routing, etc. 816 9. Informative References 818 [APNIC-final-slash8] 819 APNIC, "APNIC IPv4 Address Pool Reaches Final /8", 820 Apr 2011, 821 . 823 [ARIN-2011-5] 824 ARIN, "Draft Policy ARIN-2011-5: Shared Transition Space 825 for IPv4 Address Extension", 2011, 826 . 828 [ARIN-2011-5-AC] 829 ARIN, "Message to ARIN-PPML, announcing selection of ARIN- 830 prop-127 for Discussion as Draft Policy 2011-5", Feb 2011, 831 . 834 [ARIN-2011-5-LC] 835 ARIN, "Message to ARIN-PPML, announcing Last Call for 836 Draft Policy 2011-5", Apr 2011, . 839 [ARIN-2011-5-Rec] 840 ARIN, "Message to ARIN-PPML, announcing Advisory Council 841 meeting results Recommending 2011-5 for Board Approval", 842 May 2011, . 845 [ARIN-2011-5-Staff] 846 ARIN, "Message to ARIN-PPML, providing additional ARIN 847 Staff Assessment of Draft Policy 2011-5", Feb 2011, . 851 [ARIN-AC-13Apr2011] 852 ARIN, "Minutes: Meeting of the ARIN Advisory Committee - 853 13 Apr 2011", Apr 2011, 854 . 856 [ARIN-AC-19May2011] 857 ARIN, "Minutes: Meeting of the ARIN Advisory Committee - 858 19 May 2011", May 2011, 859 . 861 [ARIN-AC-28Jan2011] 862 ARIN, "Minutes: Meeting of the ARIN Advisory Committee - 863 28 Jan 2011", Jan 2011, 864 . 866 [ARIN-NRPM-8.3] 867 ARIN, "ARIN Number Resource Policy Manual, section 8.3 - 868 Transfers to Specified Recipients", Jul 2011, 869 . 871 [ARIN-prop-127] 872 Donley, C., "ARIN-prop-127: Shared Transition Space for 873 IPv4 Address Extension", Jan 2011, . 876 [ARIN27.2011-5] 877 ARIN, "ARIN XXVII Meeting - Participant Vote on 2011-5", 878 Apr 2011, . 881 [CISCO] Cisco, "TCP/IP Overview: Class E Addresses", . 885 [GIH-When] 886 Huston, G., "When?", Sep 2010, 887 . 889 [I-D.arkko-ipv6-only-experience] 890 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 891 Network", draft-arkko-ipv6-only-experience-03 (work in 892 progress), April 2011. 894 [I-D.donley-nat444-impacts] 895 Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., 896 and V. Ganti, "Assessing the Impact of NAT444 on Network 897 Applications", draft-donley-nat444-impacts-01 (work in 898 progress), October 2010. 900 [I-D.fuller-240space] 901 Fuller, V., "Reclassifying 240/4 as usable unicast address 902 space", draft-fuller-240space-02 (work in progress), 903 March 2008. 905 [I-D.hain-1918bis] 906 Hain, T., "Expanded Address Allocation for Private 907 Internets", draft-hain-1918bis-01 (work in progress), 908 January 2005, . 911 [I-D.ietf-6man-rfc3484-revise] 912 Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, 913 "Update to RFC 3484 Default Address Selection for IPv6", 914 draft-ietf-6man-rfc3484-revise-04 (work in progress), 915 July 2011. 917 [I-D.ietf-behave-lsn-requirements] 918 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 919 and H. Ashida, "Common requirements for Carrier Grade NAT 920 (CGN)", draft-ietf-behave-lsn-requirements-03 (work in 921 progress), August 2011. 923 [I-D.ietf-v6ops-6to4-to-historic] 924 Troan, O., "Request to move Connection of IPv6 Domains via 925 IPv4 Clouds (6to4) to Historic status", 926 draft-ietf-v6ops-6to4-to-historic-05 (work in progress), 927 June 2011. 929 [I-D.shirasaki-isp-shared-addr] 930 Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 931 and H. Ashida, "ISP Shared Address", 932 draft-shirasaki-isp-shared-addr-06 (work in progress), 933 July 2011. 935 [I-D.shirasaki-nat444] 936 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 937 and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work 938 in progress), July 2011. 940 [I-D.shirasaki-nat444-isp-shared-addr] 941 Yamaguchi, J., Shirasaki, Y., Miyakawa, S., Nakagawa, A., 942 and H. Ashida, "NAT444 addressing models", 943 draft-shirasaki-nat444-isp-shared-addr-06 (work in 944 progress), July 2011. 946 [I-D.weil-opsawg-provider-address-space] 947 Weil, J., Kuarsingh, V., and C. Donley, "IANA Reserved 948 IPv4 Prefix for IPv6 Transition", 949 draft-weil-opsawg-provider-address-space-02 (work in 950 progress), September 2010. 952 [I-D.weil-shared-transition-space-request] 953 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 954 M. Azinger, "IANA Reserved IPv4 Prefix for Shared 955 Transition Space", 956 draft-weil-shared-transition-space-request-03 (work in 957 progress), August 2011. 959 [I-D.wilson-class-e] 960 Wilson, P., Michaelson, G., and G. Huston, "Redesignation 961 of 240/4 from "Future Use" to "Private Use"", 962 draft-wilson-class-e-02 (work in progress), 963 September 2008. 965 [IAB-response] 966 IAB, "IAB responds to ARIN request for guidance regarding 967 Draft Policy ARIN-2011-5", Jun 2011, . 972 [NRO-IANA-exhaust] 973 NRO, "Free Pool of IPv4 Address Space Depleted", Feb 2011, 974 . 976 [PPML-022778] 977 "Message to ARIN-PPML, indicating the Board's disposition 978 toward 2011-5", July 2011, . 981 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 982 E. Lear, "Address Allocation for Private Internets", 983 BCP 5, RFC 1918, February 1996. 985 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 986 Understanding Concerning the Technical Work of the 987 Internet Assigned Numbers Authority", RFC 2860, June 2000. 989 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 990 Networks (VPNs)", RFC 4364, February 2006. 992 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 993 Roberts, "Issues with IP Address Sharing", RFC 6269, 994 June 2011. 996 [RFC6319] Azinger, M. and L. Vegoda, "Issues Associated with 997 Designating Additional Private IPv4 Address Space", 998 RFC 6319, July 2011. 1000 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1001 RFC 6343, August 2011. 1003 [v6ops-msg06187] 1004 WIDE, "Re: [v6ops] IETF 79 Meeting minutes - Draft", 1005 Nov 2010, . 1008 Authors' Addresses 1010 Stan Barber 1011 Cox Communications 1013 Email: stan.barber2@cox.com 1015 Owen Delong 1016 Hurricane Electric 1018 Email: owen@delong.com 1020 Chris Grundemann 1021 CableLabs 1023 Email: c.grundemann@cablelabs.com 1025 Victor Kuarsingh 1026 Rogers Communications 1028 Email: victor.kuarsingh@rci.rogers.com 1030 Benson Schliesser 1031 Cisco Systems 1033 Email: bschlies@cisco.com