[arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations)

[Owen DeLong]

I support this proposal as written.

Owen

On Jul 1, 2011, at 12:22 PM, ARIN wrote:

> 
> ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations)
> 
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
> 
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
> 
> The AC invites everyone to comment on the proposal on the PPML,
> particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF considerations)
> 
> Proposal Originator: William Herrin
> 
> Proposal Version: 1
> 
> Date: 6/30/2011
> 
> Proposal type: new
> 
> Policy term:
> 
> This policy shall remain in effect until publication of an RFC that
> implements the expectations for the /10 address block this policy
> describes. Upon RFC publication, ARIN shall cede the /10 to IANA
> for use with the RFC and then strike this policy from the NRPM.
> 
> Policy statement:
> 
> 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.
> 
> ARIN shall advise the IETF of the /10 reserved and shall request that
> the IETF determine issues associated with using the /10 as described,
> set appropriate constraints on the use of the block and publish an RFC
> documenting the block's recommended use. ARIN shall make manpower and
> other resources available to the IETF as necessary to facilitate such
> activity.
> 
> ARIN constituents are strongly discouraged from using the reserved /10
> until an RFC is published as there are expected to be technical
> issues where software makes assumptions about NAT based on the IP
> address assigned to the machine.
> 
> Rationale:
> 
> This policy proposal is substantively identical to ARIN draft policy 2011-5
> which achieved consensus and was recommended to the Board of Trustees for
> adoption in May 2011. The Internet Architecture Board was asked to comment
> on the draft policy and expressed concern that the IETF may be the
> appropriate vehicle for assigning addresses to a new use case rather
> than to a registrant.
> 
> In order to act on such a proposal, the IETF will require addresses from
> an RIR. An insufficient supply of such addresses remains available to
> them from IANA. As the ARIN community wishes the IETF to create a
> shared ISP space, it must enact policy which provides the necessary
> addresses.
> 
> As modified from proposal 2011-5, this proposal allocates the needed
> block of addresses and then asks the IETF to develop the appropriate
> technical rules of use.
> 
> Because the world marches on and Internet Service Providers have an
> immediate and pressing need to begin their NAT444 and similar deployments,
> ARIN region users are discouraged but not prohibited from using the
> reserved /10 while the IETF works through the process.
> 
> Note that this policy anticipates successful completion of the IETF process
> and publication of an RFC. It intentionally includes no provision for revoking
> the reservation should discussion within the IETF stall. Any such revocation
> will require discussion within the ARIN policy community of the IETF's
> findings followed by new policy proposals.
> 
> The first paragraph of this proposal was copied verbatim from draft 2011-5
> in the hopes of maintaining the consensus that draft achieved.  The
> remainder of this rationale is also copied verbatim from draft 2011-5:
> 
> 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: immediate
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.