Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension

[ARIN]

Draft Policy ARIN-2011-5
Shared Transition Space for IPv4 Address Extension

On 28 January 2011 the ARIN Advisory Council (AC) selected "Shared
Transition Space for IPv4 Address Extension" as a  draft policy for
adoption discussion on the PPML and at the Public Policy Meeting in San
Juan, Puerto Rico in April.

The draft was developed by the AC from policy proposal "ARIN-prop-127.
Shared Transition Space for IPv4 Address Extension". Per the Policy
Development Process the AC submitted text to ARIN for a staff and legal
assessment prior to its selection as a draft policy. Below the draft
policy is the ARIN staff and legal assessment, followed by the text that
was submitted by the AC.

Draft Policy ARIN-2011-5 is below and can be found at:
https://www.arin.net/policy/proposals/2011_5.html

You are encouraged to discuss Draft Policy 2011-5 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


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


#####


STAFF ASSESSMENT

Proposal:  “Shared Transition Space for IPv4 Address Extension”
Policy Version (Date):  20 January 2011
Date of Assessment:  26 January 2011

1. Proposal Summary (Staff Understanding)
This proposal asks ARIN to reserve and register a single, contiguous /10
in ARIN's Whois in a fashion similar to blocks reserved by RFCs  (like
RFC1918 or RFC3068).  The block is never to be assigned directly to any
organization and is to be shared by anyone who wishes to use it, with no
further registration actions required by ARIN.  Staff understands that
this space is not to be routed on the public Internet and that there
will be multiple people using the same address space much like is done
with RFC 1918 space today.

2. Comments

  A. ARIN Staff Comments

   • This proposal would have ARIN acting as the registrant for this
single IP block and maintaining it without us (or the public) knowing
who is actually using it or how they are using it.  This will likely
generate a great deal of abuse and spam complaints to ARIN.
   • It is unclear whether ARIN would need to set up nameservers for
this block to provide rDNS.

  B. ARIN General Counsel

No legal comments

3. Resource Impact

This policy would have minimal resource impact from an implementation
aspect.  It is estimated that implementation would occur within 3 months
after ratification by the ARIN Board of Trustees.
The following would be needed in order to implement:

   • Updated guidelines
   • Staff training


4. Proposal Text

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.