[ppml] Policy Proposal: IPv4 Soft Landing

Fri May 11 17:05:37 EDT 2007

I like very much this proposal and will support it.

I see only a couple of issues that could easily be resolved in a new
revision.

1) I think "plans" is not enough for the ARIN staff to verify, and is an
easy path for people to actually "make up" the plans. I will suggest that
those plans need to be checked later on and space reclaimed if they aren't
being followed. There may be other choices of course.

2) One possibility (will also work for 1) is to actually verify the plans
and the IPv6 deployment with a 3rd party audit, same as suggested for IPv4
utilization. Otherwise ARIN staff may have problems to verify everything.

Moreover, who is going to pay the 3rd party audit ? I see to choices, the
requester itself, or ARIN. I think both have advantages and disadvantages,
but I will say that if this is paid by ARIN (which in principle is what I
would choose), there is much more control on the audit process.

Actually one more possible policy proposal could be to run the audit to all
the existing members and use the results in order to reclaim unused space. I
will say that in this case the audit should be paid by ARIN for all the
members that actually pass it correctly, but by the members itself for those
that need to return some space.

Regards,
Jordi

> De: Member Services <info at arin.net>
> Responder a: <ppml-bounces at arin.net>
> Fecha: Fri, 11 May 2007 04:14:31 -0400
> Para: <ppml at arin.net>
> Asunto: [ppml] Policy Proposal: IPv4 Soft Landing
> 
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
> 
> The AC will review this proposal and may decide to:
> 
> 1. Accept the proposal as a formal policy proposal as it is presented;
> 
> 2. Work with the author to:
>        a) clarify the language or intent of the proposal;
>        b) divide the proposal into two (2) or more proposals; or
>        c) combine the proposal with other proposals; or,
> 
> 3. Not accept the proposal as a formal policy proposal.
> 
> The AC will review this proposal at their next regularly scheduled
> meeting. If their meeting is within ten days, then the review may be
> extended to the subsequent meeting. If the AC accepts the proposal, then
> it will be posted as a formal policy proposal to PPML and it will be
> presented at a Public Policy Meeting. If the AC does not accept the
> proposal, then the AC will explain that decision; and at that time the
> author may elect to use the petition process to advance their proposal.
> If the author elects not to petition or the petition fails, then the
> proposal will be closed.
> 
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/index.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal Name: IPv4 Soft Landing
> 
> Author: David Conrad
> 
> Proposal Version: 1.0
> 
> Submission Date: 2007-05-02
> 
> Proposal type: New
> 
> Policy term: Permanent
> 
> Policy statement:
> 
> 30 days after specified thresholds in the amount of address space
> remaining in the IANA IPv4 free pool are crossed, the requirements
> necessary for ISPs to obtain additional IPv4 address space are made
> more stringent and requesters must demonstrate efforts both to utilize
> scarce IPv4 address space more efficiently, set up IPv6 infrastructure
> services, and eventually offer production IPv6 connectivity.
> 
> The proposed thresholds and the requirements to justify an allocation
> of new IPv4 address space from ARIN are:
> 
> Phase        0
> Threshold     N/A
> Requirements
> 
> Requesters must demonstrate:
> 
> * No requirements to document IPv6 infrastructure services or IPv6
>    connectivity services.
> 
> * 80% utilization in all customer assignments as reflected in
>    SWIP/rwhois reassignments
> 
> * Downstream immediate requirement: 25%
> 
> * Downstream requirement after 1 year: 50%
> 
> Phase      1
> Threshold    40 /8s
> Requirements:
> 
> Requesters must demonstrate:
> 
> * Documented plans for availability of production IPv6 infrastructure
>    services within 6 months
> 
> * Documented plans for availability of production IPv6 service within
>    1 year
> 
> * 85% utilization in all customer assignments as reflected in
>    SWIP/rwhois reassignments
> 
> * Downstream immediate requirement: 33%
> 
> * Downstream requirement after 1 year: 66%
> 
> Phase      2
> Threshold    30 /8s
> Requirements:
> 
> Requesters must demonstrate:
> 
> * Documented availability of production IPv6 infrastructure services
> 
> * Documented plans for availability of production IPv6 service within
>    6 months
> 
> * 90% utilization in all customer assignments as reflected in
>    SWIP/rwhois reassignments
> 
> * Current 3rd-party auditors report of IPv4 address space utilization
> 
> * Downstream immediate requirement: 50%
> 
> * Downstream requirement after 1 year: 75%
> 
> Phase      3
> Threshold    20 /8s
> Requirements:
> 
> Requesters must demonstrate:
> 
> * Documented availability of production IPv6 infrastructure services
> 
> * Documented availability of production IPv6 connectivity service
> 
> * A migration plan for all internal infrastructure to either IPv6 or
>    private addressing
> 
> * 92% utilization in all customer assignments as reflected in
>    SWIP/rwhois reassignments
> 
> * Current 3rd-party auditors report of IPv4 address space utilization
> 
> * Downstream immediate requirement: 60%
> 
> * Downstream requirement after 1 year: 80%
> 
> Phase      4
> Threshold    15 /8s
> Requirements:
> 
> Requesters must demonstrate:
> 
> * Documented availability of production IPv6 connectivity services
> 
> * Initiation of migration of internal infrastructure to either IPv6 or
>    private addressing
> 
> * 94% utilization in all customer assignments as reflected in
>    SWIP/rwhois reassignments
> 
> * Current 3rd-party auditors report of IPv4 address space utilization
> 
> * Downstream immediate requirement: 70%
> 
> * Downstream requirement after 1 year: 85%
> 
> Internal infrastructure can be used in justification for IPv4 address
> space only in special circumstances
> 
> Phase      5
> Threshold    10 /8s
> Requirements:
> 
> Requesters must demonstrate:
> 
> * Documented availability of production IPv6 connectivity services
> 
> * Recycling of 25% of (non-private) IPv4 address space formerly used
>    for internal infrastructure
> 
> * 96% utilization in all customer assignments as reflected in
>    SWIP/rwhois reassignments
> 
> * Current 3rd-party auditors report of IPv4 address space utilization
> 
> * Downstream immediate requirement: 75%
> 
> * Downstream requirement after 1 year: 90%
> 
> Internal infrastructure can no longer be used in justification for
> IPv4 address space
> 
> Phase      6
> Threshold    5 /8s
> Requirements:
> 
> Requesters must demonstrate:
> 
> * Documented availability of production IPv6 connectivity services
> 
> * Recycling of 75% of IPv4 address space formerly used for internal
>    infrastructure
> 
> * 98% utilization in all customer assignments as reflected in
>    SWIP/rwhois reassignments
> 
> * Current 3rd-party auditors report of IPv4 address space utilization
> 
> * Downstream immediate requirement: 80%
> 
> * Downstream requirement after 1 year: 95%
> 
> Internal infrastructure can no longer be used in justification for
> IPv4 address space
> 
> Note that for the purposes of this proposal, the following definitions
> apply:
> 
> * Downstream: entities to which the ISP may assign address space.
> 
> * IPv6 infrastructure services: services such as DNS, WWW, FTP,
>    etc. accessible via IPv6.
> 
> * IPv6 connectivity: IP connectivity service provided over IPv6
>    transport, either natively or via an IPv6 tunnel.
> 
> * Internal infrastructure: routers, switches, servers, etc., that are
>    not normally visible or directly accessed by the ISP customers.
> 
> Phase 0 reflects current allocation requirements.  Subsequent phases
> of this policy are to be implemented 30 days after IANA allocates
> address space from the IPv4 free pool that reduces that free pool to a
> number of /8s that are at or below the threshold specified.  If
> multiple thresholds should be crossed within a 30 day period, the
> requirements from the last threshold crossed will be applied to
> requesters for additional address space.
> 
> Rationale:
> 
> The rationale for this proposal is threefold:
> 
> * to prolong the availability of IPv4 addresses to requesters who can
>    provide sufficient justification;
> 
> * to encourage the deployment of IPv6 as an alternative to IPv4 by
>    making the requirements to justify IPv4 allocations increasingly
>    stringent over time;
> 
> * to promote the more efficient use of increasingly scarce IPv4
>    resources.
> 
> As the lack of significant deployment of IPv6 can attest, the cost of
> deploying IPv6 currently outweighs the benefits that protocol would
> appear to provide.  This proposal aims to encourage the deployment of
> IPv6 by making the allocation of IPv4 both more difficult and
> contingent on the ISP demonstrating both support for IPv6 as well as
> more efficient use of the IPv4 address space they administer.  The
> goal of these measures is to rebalance the IPv6 deployment
> cost/benefit ratio thereby encouraging greater uptake of IPv6 before
> the IPv4 free pool is exhausted.
> 
> The "IPv4 Soft Landing" policy aims to provide for a smoother
> transition away from IPv4 towards IPv6 by imposing increasingly strict
> requirements for new address allocations as the amount of address
> space available in the IANA unallocated IPv4 address pool decreases.
> These increased requirements include both more stringent reassignment
> and utilization percentages as well as requiring documented IPv6
> infrastructure services and connectivity provision and the reuse of
> IPv4 address space used for internal infrastructure.
> 
> The increased stringency in the allocation requirements is intended
> both to increase the efficiency of utilization of the IPv4 address
> space and to reduce the likelihood of a "run" on the remaining free
> pool of IPv4 address space.  ARIN staff would be expected to use the
> same mechanisms in use today to verify utilization of customer
> requirements.
> 
> The requirements for demonstration of IPv6 infrastructure services and
> connectivity are intended to motivate ISPs to provide those services
> before the only address space they can offer their customers is IPv6,
> thereby breaking the "chicken-and-egg" problem limiting significant
> IPv6 deployment.  Verification of these requirements can be done by
> ARIN staff by using IPv6 transport to connect to published services of
> the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping
> to identified addresses internal to the ISP.
> 
> The requirement to provide a current third-party auditors report of
> utilization is intended to deter fraudulent justification data used to
> support IPv4 allocations in the absence of actual need.
> 
> The requirements to migrate internal infrastructure to either IPv6 or
> private (e.g., RFC 1918) addressing are intended to improve the
> efficiency of utilization of IPv4 address space, reserving the scarce
> IPv4 resources for purposes for which IPv6 or private addresses are
> not suitable.  These requirements acknowledge that pragmatically, the
> use of IPv4 is absolutely essential only for servers in client-server
> architectures, machines engaged in peer-to-peer applications, and
> entry points for NAT/ALG devices.  As such, use of IPv4 for purposes
> such as router interface numbering, client-only devices, and devices
> which should not be available from external networks should be
> discouraged.  This policy anticipates ARIN staff will make use of
> auditor reports to verify appropriate use of IPv4 addresses in
> internal infrastructure.
> 
> The time for transition between phases of this policy are not fixed,
> rather they depend on the rate of consumption of IPv4 address space
> from the IANA free pool. Current RIR operational procedure is to
> request 2 /8s from the IANA when their current pool of free IPv4
> address space is depleted.  This procedure should ensure transitions
> between phases will have some lead-time, so organizations can prepare
> for the next phase of IPv4 address allocation.
> 
> Timetable for implementation:
> 
> Immediately upon approval of this policy by the ARIN Board of Trustees.
> 
> 
> 
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.