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

[Owen DeLong]

Respectfully, John, as things stand at this moment, I disagree. I believe that
proposal 154 calls for ARIN to designate and set aside the specific /10.
While the board may be intending to do so, it is not clear that draft policy
2011-5 requires that to be done and until the board actually makes such an
announcement, proposal 154 remains non-duplicative and relevant as
a policy proposal.

As such, I would recommend that the AC put 154 on the docket at their
next meeting and consider it in scope until such time as the board actually
takes and announces action that would obviate the need for 154. If that
happens, then, I would support abandoning 154 at that time as it would
then be out of scope.

Owen

On Jul 1, 2011, at 10:18 PM, John Curran wrote:

> All - 
> 
> Policy proposal ARIN-prop-154 does not result in a materially different 
> Internet number resource management policy from the Draft Policy 2011-5 
> (which is already within the ARIN Policy Development Process and is before 
> the Board of Trustees having been recommended for adoption by the ARIN AC.) 
> 
> ARIN-prop-154 does propose a procedure for implementation of the policy
> change and the suggested procedure for implementation will be provided to 
> the ARIN Board of Trustees for their ongoing consideration of Draft Policy 
> 2011-5 (regardless of the disposition of ARIN-prop-154.)
> 
> As the policy proposal in ARIN-prop-154 overlaps significantly with 
> an existing Draft Policy already in the Policy Development Process and 
> recommended for adoption, it is the staff position that ARIN-prop-154 
> is outside the scope of the the ARIN Policy Development Process PDP 
> (per "PART ONE- PRINCIPLE, 2. Scope", noted below) and its abandonment
> will be recommended to the ARIN AC during their initial policy proposal
> evaluation.  The ARIN AC may choose not to abandon the policy proposal
> and continue work on it, recognizing that any ARIN Board of Trustees 
> outcome with respect to the existing recommended Draft Policy 2011-5 
> may obviate their development efforts with respect to ARIN-prop-154.
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
>> From <https://www.arin.net/policy/pdp.html> -
> 
>> 2. Scope
>> ...
>> 	• This version of the ARIN PDP is designed to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption.
> 
> 
> ---
> 
>> ## * ##
>> 
>> 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.
> 
> _______________________________________________
> 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.