| Network Working Group | S. Barber |
| Internet-Draft | Cox Communications |
| Intended status: Informational | O. Delong |
| Expires: January 13, 2012 | Hurricane Electric |
| C. Grundemann | |
| CableLabs | |
| V. Kuarsingh | |
| Rogers Communications | |
| B. Schliesser | |
| Cisco Systems | |
| July 12, 2011 |
ARIN Draft Policy 2011-5: Shared Transition Space
draft-bdgks-arin-shared-transition-space-01
This memo encourages the reservation of a Shared Transition Space, an IPv4 prefix designated for local use within service provider networks during the period of IPv6 transition. This address space has been proposed at various times in the IETF, and more recently come to consensus within the ARIN policy development community where it was recommended for adoption as Draft Policy 2011-5.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
As the Internet community approaches exhaustion of unallocated IPv4 numbers, the value of globally unique addresses is becoming manifest. More than ever network operators recognize the need to transition to the IPv6 address family. However, the immediate necessity of continued IPv4 connectivity poses a near-term challenge - without adequate IPv4 resources, most network operators must deploy more efficient addressing architectures and many must deploy address-sharing technologies.
In order to facilitate these operators' need for near-term IPv4 connectivity, [I-D.weil-shared-transition-space-request] proposes the reservation of a /10 IPv4 prefix for use in Service Provider (SP) networks. Referred to as Shared Transition Space, this address block would facilitate SP deployment of non-unique address plans that do not conflict with traditional Private [RFC1918] address space. By using the Shared Transition Space operators may deploy CGN [I-D.ietf-behave-lsn-requirements] internal networks, extranet [RFC4364] communities, and/or SP-local services without consuming globally unique addresses.
However, given the Feb 2011 depletion of the IANA Free Pool inventory [NRO-IANA-exhaust] it is not currently possible for the IANA to reserve an IPv4 /10 prefix as recommended in [I-D.weil-shared-transition-space-request]. Thus the ARIN community has proposed in Draft Policy [ARIN-2011-5] the reservation of a Shared Transition Space from the ARIN inventory of unallocated IPv4 numbers. After much discussion by the ARIN community, [ARIN-2011-5] reached consensus and was recommended by the ARIN Advisory Council for approval by the ARIN Board of Trustees.
Following the community's recommendation of [ARIN-2011-5] the ARIN Board requested clarification from the IAB with regard to responsibilities outlined in [RFC2860]. The ARIN Board received a response in [IAB-response] indicating that the IETF holds responsibility for the reservation of specialized address blocks. Thus, the ARIN Board believes that it is not within ARIN's authority to unilaterally make specialized allocations of the sort proposed in Draft Policy 2011-5. [PPML-022778]
This memo is a discussion of the merits of a Shared Transition Space, and is a call for consensus between the IETF and RIR communities that such an address reservation should be made.
There are a number of use-cases for the Shared Transition Space. This section discusses the primary scenarios envisioned at the time of this writing.
A primary use-case for the Shared Transition Space will be deployment in CGN [I-D.ietf-behave-lsn-requirements] internal networks. A key benefit of CGN is the ability to share a smaller number of Globally Unique Addresses (GUA) amongst a larger number of end-sites.
In one CGN deployment scenario sometimes referred to as NAT444 [I-D.shirasaki-nat444], the CGN internal network is numbered with IPv4 addresses that are not globally routed while the end-sites are numbered with Private [RFC1918] addresses. In this scenario the Shared Transition Space will be used to provide contextually unique IPv4 addresses to end-site CPE devices and intermediate infrastructure. [I-D.shirasaki-nat444-isp-shared-addr]
Another use-case for the Shared Transition Space is in building private Extranet community networks. In these networks, multiple end-sites administered by different organizations are connected together via VPN technology. Because different organizations may be using Private address space internally, an Extranet addressing plan is often unable to effectively use Private address space without conflicting. The Shared Transition Space will provide an alternative to the use of GUA space in such a scenario.
In networks that contain local services (such as nameservers, content repositories or caches, etc) the Shared Transition Space will offer an alternative to GUA. For instance, video content servers that are available only to customers directly connected to the SP network might be addressed from the Shared Transition Space, preserving GUA for services that require global connectivity.
In any case, care must be taken to ensure the Shared Transition Space is not used in scenarios where routing may be ambiguous. For instance, when multiple provider networks may be simultaneously reachable the use of Shared Transition Space might result in address conflicts etc. Conversely, operators may choose to allow (not filter) ICMP messages from the Shared Transition Space in order to enable Path MTU Discovery etc. This topic requires further investigation so that best practices may be developed.
A number of possible alternatives to Shared Transition Space have been proposed and/or discussed by the Internet community. See, for instance, [I-D.azinger-additional-private-ipv4-space-issues] for a discussion of alternatives and potential issues. This section outlines these possible alternatives and briefly discusses their applicability.
Every discussion of the Shared Transition Space begins with an assumption that Globally Unique Addresses (GUA) are a preferable choice for numbering. This is almost always technically true. However, given the fundamental driver of IPv4 address exhaustion, GUA is not a pragmatic alternative to the Shared Transition Space.
Additionally, if various organizations use various GUA ranges to number CGN zones, it will be difficult for other networks and/or systems to deterministically know if the endpoints are using true Internet reachable IPs, or if the source network may be using them as CGN zone space. This situation would likely lead to additional technical issues during various leakage conditions, filter rule issues (routing) and for CDN or other third party providers who may be present within the source network, to name a few.
In each of the use-cases for Shared Transition Space, it may be possible to instead use Private [RFC1918] address space. In situations where all endpoints in the network are managed by a single organization, this may be a viable option. However when end-sites are administered by different organizations and/or individuals, the possibility of address conflict becomes a significant risk to operations.
A study of DNS traffic [v6ops-msg06187] has shown that effectively all of the existing Private [RFC1918] address space is currently being used by end-sites attached to the Internet. While individual network environments may vary in this regard, most SP operators face the risk that their use of Private address space will conflict with their customer end-sites.
In the event of conflict, it is possible that the end-site CPE will fail and/or not function correctly. Some CPE implementations are known to support overlapping addresses on the "inside" and "outside" interfaces, however many others are known to fail under such circumstances. For SP operators, the Shared Transition Space offers a less risky alternative to GUA that retains the benefit of non-conflict.
Also, the use of Private [RFC1918] address space on interfaces and hosts often causes default behaviors on such hosts which may not be desirable when the endpoint is actually connected to the Internet. There are often behavioral expectations for Internet connected endpoints, regardless of them being subject to a NAT.
Incorrect affiliation of the WAN side interface being in a "protected" zone and/or on a trusted network may not be desirable. With NAT444 deployments, it is important that the endpoint (i.e. CPE) behave like any other Internet node. One example of this from our testing was observed behaviors where some CPEs did not filter and/or firewall correctly when Private [RFC1918] address space was used on both WAN and LAN interfaces.
One proposed alternative to Shared Transition Space is the re-classification and use of the 240.0.0.0/4 "Class E" address space as unicast. This has been proposed, for instance, by [I-D.fuller-240space] and [I-D.wilson-class-e]. While this alternative might be possible in tightly constrained environments, where all of the network elements are known to support Class E address space, it is not generally useful in the use-cases described above. At this time, a significant number of IPv4 stack implementations treat the Class E address space as reserved and will not route, forward, and/or originate traffic for that range. For the scenarios described herein, it should be noted that this alternative would create additional SP dependencies on customer selected CPE support for Class E addressing.
An unfortunate alternative to the Shared Transition Space is "prefix squatting", in which the operator re-uses another organization's IPv4 allocation for their own numbering needs. When this approach results in the other organization's prefix being announced globally by the "squatting" operator, it is often referred to as "prefix hijacking". However, this discussion is focused on scenarios in which the prefix is not announced globally but is, rather, used for internal numbering only.
In this scenario, the allocation may not be routed globally by the legitimate address holder, making it attractive for such purposes. Or it may be routed but "uninteresting" to the SP network's endpoints. In either case there is a potential for conflict in the event that any end-site actually wishes to communicate with the legitimate address holder. Indeed, various RIRs attempt to discover and "recycle" abandoned or unused IPv4 address space, making it more likely that such conflicts will be experienced in time. As such, this alternative is to be discouraged with prejudice.
It is important to note that there are no behavioral advantages to using "squat space" over using assigned "shared space". Both options subject the CPE to the same general behaviors (GUA space, but not globally reachable). The only real difference is the negative impacts of squatting (as noted above) and the advantages of a community coordinated and standardized prefix.
The primary reason that any network would be likely to adopt "prefix squatting" is if they are faced with the operational realities of CGN before/without the allocation of a shared transition space.
Similar to "Prefix Squatting" but significantly less dangerous, this alternative involves the reuse by an operator of their own address allocations. In this scenario, a network operator might use the same prefix for multiple "regions" and/or extranet communities. For instance, in CGN deployments the operator might reuse the same GUA prefix across multiple geographic regions (e.g. without announcing it globally).
Here again, it is important to note that there are no behavioral advantages gained over a "shared space" but there is the added community cost of each network having to dedicate a unique block of addresses to this purpose, consuming far more resources than a single block of "shared space".
In the event that the Internet community doesn't set aside an IPv4 prefix for Shared Transition Space, it is possible that a number of SP operators can come together and designate an address block to be "shared" amongst them for an identical purpose. This would have the same technical merits as an IETF and/or RIR sponsored Shared Transition Space, however it would lack the efficiency of a community coordinated and standardized prefix for such purposes, gain no behavioral advantages, remove the deterministic nature of managing a single range and also subjects the Internet (users of the space) to additional risk since any member of the consortium who has contributed space could later pull out and potentially cause disruptions in multiple networks.
Availability of a Shared Transition Space helps SPs continue to meet the demands of IPv4 address and/or connectivity post exhaustion. For environments where CGN in a NAT444 scenario is necessary, addresses from this space can be used to provide addressing for the network between the CGN device(s) and CPE which will enable IPv4 flow continuity for customers using these services. In other circumstances, the shared transition space allows SPs to number devices in the network which do not require global reachability without the need for fulfillment thorough an RIR.
If operators are required to use their individually allocated GUA where "shared space" would have applied, e.g. for internal services, they will face exhaustion sooner and thus be forced to deploy CGN sooner as well. Operators may be able to postpone the deployment of CGN by using "shared space" for internal uses, because that allows more efficient use of their remaining GUA in places where global uniqueness is truly mandatory.
Further, without this shared transition space, some service providers may be forced to reclaim GUA from existing customers in order to deploy CGN and address the required infrastructure. Having this transition space will enable deployment of CGN where it is required, in a manner that is less disruptive and with impact to fewer customers.
The shared transition space can also be used to number and reclaim IPv4 addresses within provider networks which do not require global reachability. This option can be used by many networks worldwide, it provides an option for using currently assigned space much more efficiently.
Operators can re-deploy recovered addresses for customers that need them (including new / static / GUA customers), hosted servers, etc. or to facilitate other efforts that might provide even more efficient use of GUA space within the network. The freed addresses can be assigned to endpoints which require IPv4 global reachablity and thus help delay and/or remove the need for CGN.
In cases where the operator doesn't need the recovered addresses, they can be made available to others that do need them. This may be through voluntary return to the RIR, or through transfer to another network operator. For example, in the ARIN region, there are transfer mechanisms defined in the ARIN NRPM 8.3 [ARIN-NRPM-8.3].
While making Shared Transition Space available to the community may or may not lessen the demand on the RIRs for allocations, it will help ensure that the address resources which remain in inventory are used most efficiently, maximizing the use of that inventory for services that require globally unique addresses.
Standardizing on a single block will help the community develop standard ways of selecting, routing, filtering and managing shared space. This task would be much more difficult or impractical for any of the alternative options.
Standard internal routing policy and filtering can be applied uniformly inside network environments. Additionally, exchange points between networks can have standard policies applied allowing operators to protect each other from CGN zone IPs leaking between networks. This may not be possible with squat space since many operators will not divulge what space may be used and with Private [RFC1918] address space where each operator may only be able to free up certain portions of the space which are not likely to be consistent between networks.
Operators will need to grapple with the need to provide IPv4 based flow continuity to customers post exhaustion. By removing the burden of operators needing to find adequate IPv4 address space to meet the needs that a shared transition space can fulfill, they can concentrate on the real task at hand: Deploying IPv6.
Endless cycles can be avoided where operators squat, free up space and/or segment networks in an effort to find valid IPv4 space. The saved effort, time and cost can be re-directed to provide quality IPv6 connectivity therefore expediting the removal of the overall need for IPv4 addresses and connectivity.
NAT is understood to be less then optimal [RFC6269], especially when implemented as CGN [I-D.donley-nat444-impacts]. That said, it is a necessary technology for many networks and cannot be completely avoided. Since the number of IPv4 Internet endpoints will exceed the number of IPv4 addresses which are available for Internet connectivity, NATs are needed.
While the authors agree that "NAT is bad", it must also be understood that shared transition space does not change the fundamental motivations or issues with NAT and so those problems will not be discussed at length here.
Some host or CPE functions incorrectly assume global reachability based on the type of address that is configured, potentially causing issues when deployed in a NAT444 scenario. Whether an operator uses this proposed Shared Transition Space or some other GUA space (e.g. through squatting or reuse), the net effect on hosts and/or CPE making such assumptions about reachability is identical. Conversely, with an identified Shared Transition Space hosts that make bad assumptions can be modified to treat the identified block as having restricted reachability semantics. This would not be possible (or at least not nearly as easy) with the other solutions.
Although 6to4 can break in CGN scenarios using the Shared Transition Space, recent guidance suggests that it should be turned off by default. [I-D.ietf-v6ops-6to4-advisory] [I-D.ietf-v6ops-6to4-to-historic] Further, broken 6to4 can potentially be "repaired" in some instances or managed by the network operator. Indeed, common getaddrinfo() implementations that follow [RFC3493] rules should prefer native transports, mitigating effects from incorrect 6to4 instantiation behind a firewall that obstructs its function.
Since the volume of impacted endpoints will be very low, operators can likely manage the disabling of 6to4 when needed. More fundamentally, broken 6to4 should not be an issue if service providers deploy native IPv6 connectivity.
The value of a Shared Transition Space may be diminished if misused by end-sites as generic Private addresses. Thus, the reservation must be clearly designated for use by SPs that are providing infrastructure as described herein.
This is not a technical issue. As with any technology, the opportunity exists for a misuse. This however should not shroud the strong benefits of the shared address space option. Many technologies in use today can be used correctly or misused. This does not prevent the community from introducing those technologies since the good far outweighs the bad.
This argument is simply incorrect. Post IPv4-exaustion, any SP that wishes to continue providing IPv4 connectivity will necessarily deploy network architectures and technologies that require such an address space. Thus, in absense of a designated Shared Transition Space, operators will use GUA space in essentially the same ways described in this memo, with or without IETF or RIR acknowledgement.
While customer growth for some ISPs has slowed, for many service providers new services are growing at a faster rate than has been anticipated. Wireline voice customers for example require two-way communication paths to allow them to function properly. IP enabled televisions is another example of devices that support video and voice services and require IP addresses. In many cases the protocols that allow these devices to work have embedded IP addresses that do not work with NAT. The only way to maintain these services, which in many cases are considered lifeline, is to provide them with an IP address that is unique within the service provider network.
Likewise, growth continues to exist in some geographical regions. While some areas have slower growth, as a result of significant penetration of Internet access, there are still many areas with unmet needs, growing populations, or both.
With the IANA inventory essentially exhausted [NRO-IANA-exhaust] it is only a matter of time before each of the RIRs are unable to satisfy requests for IPv4 addresses. [GIH-When] In fact, the APNIC has already allocated all but their final /8 of inventory [APNIC-final-slash8] and is no longer making allocations larger than a /22 prefix. Each of the other RIRs is on a trajectory toward exhaustion in the near future.
While some SPs have existing inventory that will outlast the RIR inventories, this is not universally true. In fact, the distribution of IPv4 number resources amongst operators is highly variable (based on size, history, etc) and in the worst cases is already becoming problematic.
While true that this shared transition space will remove a block of global unicast IPv4 addresses from the free pool, it must also be noted that the use of the same "shared space" repeatedly across multiple networks will very likely increase the available pool of unique IPv4 addresses through operational efficiency. For example, if just two operators use their own GUA /10, the Internet community effectively loses a /9 of unique space while if both operators use the same "shared" /10, the Internet community loses that single /10. This benefit becomes more significant as more operators use the Shared Transition Space.
Even if the Shared Transition Space fails to alleviate near-term demand on RIR inventories, for whatever reason, the reservation of a Shared Transition Space will enable continued deployment of IPv4 connectivity by SP networks beyond that horizon - a clear benefit.
Although previous requests for Shared Transition Space asked for a full /8, it has been determined by many operators that a /10 will in fact be sufficient. A /10 provides for roughly 4 million hosts and although many of the largest SPs have subscriber counts in the tens of millions, none will be placing all of their subscribers behind a single CGN. In the event that a /10 does not provide enough addresses for an operators entire CGN deployment, it could be re-used multiple times in distinct "NAT zones" or regions.
It remains to be seen whether the reservation of a Shared Transition Space will delay the impending exhaustion of RIRs' IPv4 inventory. Certainly, the availability of this Shared Transition Space will satisfy a number of demands that would otherwise become requests for GUA resources. However, whether this translates to an actual reduction in requests is up to the RIRs and requesting organizations. Regardless of the allocation of shared transition space, RIR IPv4 exhaustion may happen at roughly the same time. However, shared transition space does provide the opportunity for more efficient use of the remaining RIR IPv4 addresses.
Although IPv6 is the strategic long term answer for IPv4 address exhaustion, it does not immediately solve IPv4 connectivity requirements. There is an entire eco-system which exists on the Internet today and is not IPv6 ready at this time [I-D.arkko-ipv6-only-experience]. IPv4 flow continuity will be required for at least several years.
Many businesses have long procurement and fulfilment cycles which will need to be used to upgrade networks to support IPv6. Also, the consumer (home) space is years away from being all IPv6 capable. Many homes are filled with IPv4 only consumer electronics, computers, TVs, accessories and other systems.
There are still a number of products that are either not IPv6 compliant, or for which the necessary criteria for being "IPv6 compliant" is unclear or undefined. Some examples include security products, a large number of software applications, and there are still production systems (both inside companies and as products) being rolled out that are not IPv6 aware.
The whole Internet needs to get to IPv6 more or less at the same time in order to avoid significant deployment of transition technologies. This proposal may help delay some transition technology deployment while IPv6 deployments move ahead. More IPv6 should mean less transition technology.
Proposals for additional Private space date back at least to [I-D.hain-1918bis] in April 2004. Some of these proposals and surrounding discussion may have considered similar use-cases as described herein. However, they were fundamentally intended to increase the size of the [RFC1918] pool, whereas a defining characteristic of Shared Transition Space is that it is distinctly not part of the Private [RFC1918] address pool.
Rather, the Shared Transition Space is reserved for more narrow deployment scenarios, specifically for use by SPs to meet the needs of ongoing IPv4 connectivity during the period of IPv6 transition. This key feature emerged in more recent proposals such as [I-D.shirasaki-isp-shared-addr] in June 2008 where a proposal to set aside "ISP Shared Space" was made. During discussion of these more recent proposals, many of the salient points where commented upon, including challenges with RFC1918 in the ISP NAT Zone, Avoidance of IP Address Conflicts, and challenges with 240/4.
This effort was followed up by [I-D.weil-opsawg-provider-address-space] in July 2010 which was re-worked in November 2010 as [I-D.weil-shared-transition-space-request]. These latter efforts continued to point out the operators' need for Shared Transition Space, with full acknowledgement that challenges may arise with NAT444 as per [I-D.donley-nat444-impacts] and that such space does not reduce the need for IPv6 deployment.
Most recently, following exhaution of the IANA's /8 pool [NRO-IANA-exhaust], this proposal has been discussed by various RIR policy development participants. As described herein, the body of ARIN policy development participants has reached consensus and recommended a Shared Address Space policy for adoption [ARIN-2011-5].
This history shows that operators and other industry contributors have consistently identified the need for a Shared Transition Space assignment, based on pragmatic operational needs. The previous work has also described the awareness of the challenges of this space, but points to this option as the most manageable and workable solution for IPv6 transition space.
The following is a brief history of the proposal for Shared Address Space within ARIN, ultimately resulting in the recommendation of ARIN Draft Policy 2011-5 [ARIN-2011-5].
In January 2011, a policy was proposed to the ARIN policy development community called ARIN-prop-127: Shared Transition Space for IPv4 Address Extension [ARIN-prop-127]. This policy proposal would reserve an IPv4 /10 prefix by ARIN, to be shared by any Service Providers who wish to use it with no further registration actions required.
After generating much discussion (over 100 posts) on the ARIN Public Policy Mailing List (PPML), the ARIN Advisory Council (AC) accepted the proposal as Draft Policy 2011-5 [ARIN-AC-28Jan2011], formally announced on PPML 3 February 2011 [ARIN-2011-5-AC].
On 14 February 2011, ARIN staff made the following statement with regard to 2011-5: "In keeping with the spirit of RFC 2860 with respect to the assignment of specialized address blocks, ARIN Staff will consult with the IANA and the IAB regarding implementation of this draft policy." [ARIN-2011-5-Staff]
In the ensuing PPML discussion there was a roughly two to one ratio of those clearly in support of the policy versus those clearly against. ARIN Draft Policy 2011-5 was then discussed at the ARIN XXVII public policy meeting on 12 April 2011. Following the discussion, there was a straw poll of the room. With a total number of people in the meeting room and remote of 116; in favor of it were 30 and against it were 15. [ARIN27.2011-5]
Seeing an obvious need in the service provider community, the AC voted to send the Draft Policy to last call [ARIN-AC-13Apr2011] for final comments 18 April through 2 May 2011. [ARIN-2011-5-LC] Following a strong show of support from the operator community during last call, the AC voted [ARIN-AC-19May2011] to recommend adoption of 2011-5 to the ARIN Board of Trustees with a vote of 10 in favor and 2 abstentions. [ARIN-2011-5-Rec]
Following this recommendation, ARIN staff consulted with the IAB and IANA as committed. The IAB response [IAB-response] stated, in short, that they believed the adoption of [ARIN-2011-5] was in conflict with the provisions in [RFC2860] and requested that the community re-review the operational and technical merits of shared transition space in the IETF. That process is now underway, with this draft an attempt at more fully analyzing said operational and technical merits.
Draft Policy ARIN-2011-5
Shared Transition Space for IPv4 Address Extension
Date: 20 January 2011
Policy statement:
Updates 4.10 of the NRPM:
A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators.
Rationale:
The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet.
Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider.
Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed.
Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. 'squat'). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs.
Timetable for implementation: immediately
The authors would like to thank the following individuals for their contributions:
The authors would also like to thank the following people for their review, comments, and support: Gary Buhrmaster, Chris Donley, Wes George, Chris Metz, and Richard Von Scherr.
Upon notification by the IAB that that an address reservation should be made, ARIN is willing to proceed with the implementation of its Draft Policy 2011-5 which would result in ARIN reserving IPv4 /10 block for shared transition. The IANA is to record the allocation of the IPv4 address block for this purpose. Alternatively, the IAB may direct the IANA to request return of sufficient address space from ARIN's available IPv4 number resource pool to allow the IANA to perform this reservation directly.
This memo makes reference to a number of deployment scenarios that have unique security considerations, and the reader is advised to investigate these independently.
While this memo does not introduce any specific technical issues that may be subject to detailed security considerations, it does reccommend the reservation of a new IPv4 address space that might have unique properties when deployed. As such, all implementors of this Shared Transition Space are encouraged to consider carefully the best practices associated with the use of this space, including considerations relating to filtering, routing, etc.