[arin-ppml] 2008-5: Dedicated IPv4 block to facilitate IPv6 deployment - Last Call

[Owen DeLong]

If we reserve it, then, we can create policy at any point for how
best to use it.  If we fail to reserve it, then, that ship has sailed.

This is a good policy.  A /10 is not too much space when you
consider that it might be decades worth of new IPv6 only entrants
into the marketplace that need support from this space. Indeed,
I think a /8 is the more appropriate size.

Stacy, you're assuming that this space is needed for existing
organizations that will be deploying transitional technologies.
I'm assuming that this space is for new organizations that arrive
after IPv4 free pool exhaustion and need transitional technologies
just to talk to the portion of the internet that hasn't yet gained
any form of IPv6 capability.

Looking at the potential number of those organizations makes
me think there's a much larger demand than looking at it from
your stated perspective.

Owen

On Oct 23, 2008, at 4:45 PM, Stacy Hughes wrote:

> Hello All,
> I continue to disagree with this proposal with regard to the size of  
> block needed.  I acknowledge the desire for filtering for this  
> purpose, and I think that's great, but /10 is too big.  With my LIR/ 
> ISP hat on, who among us does not have a /24, or /28 to spare for  
> this purpose?  The way I see it, this proposal is germane to  
> organizations that don't already have v4 space.   I think this  
> proposal is accounting for all possible organizations, the  
> overwhelming majority of which will already have some spare v4 for  
> this purpose.
>
> Further, in AC deliberations, it was pointed out that there is no  
> mechanism to acquire any space for this purpose, if the Board  
> ratifies it or not.  The experimental policy does not provide  
> justification for v4/v6 transition.
> http://www.arin.net/policy/nrpm.html#eleven
>
> I acknowledge we're running out of time, and by the same token the  
> need for anything we can do to encourage v6 adoption.
>
> We may have gotten the cart before the horse on this one.  First, we  
> must have the mechanism to acquire the space for v4/v6 transition,  
> then we must assess the constituent base for this policy, then  
> reserve the block.
>
> Thank you,
> Stacy
>
>
> On Wed, Oct 22, 2008 at 12:34 PM, Member Services <info at arin.net>  
> wrote:
> Policy Proposal 2008-5
> Dedicated IPv4 block to facilitate IPv6 deployment
>
> On 17 October 2008 the ARIN Advisory Council (AC), acting under the
> provisions of the ARIN Internet Resource Policy Evaluation Process,
> determined that the community supports this proposal and moves it to
> last call.
>
> Feedback is encouraged during this last call period. All comments  
> should
> be provided to the Public Policy Mailing List. This last call will
> expire at 23:59 EDT, 7 November 2008.
>
> The policy proposal text is provided below and is also available at:
> http://www.arin.net/policy/proposals/2008_5.html
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 2008-5
> Dedicated IPv4 block to facilitate IPv6 deployment
>
> Author: Alain Durand
>
> Date: 6 June 2008
>
> Proposal type: New
>
> Policy term: Permanent
>
> Policy statement:
>
> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> deployment. Allocations and assignments from this block must be
> justified by immediate IPv6 deployment requirements. Examples of such
> needs include: IPv4 addresses for key dual stack DNS servers, and  
> NAT-PT
> or NAT464 translators. ARIN staff will use their discretion when
> evaluating justifications.
>
> This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /24. ARIN should use sparse allocation when
> possible within that /10 block.
>
> In order to receive an allocation or assignment under this policy:
>
>   1. the applicant may not have received resources under this policy  
> in
>      the preceding six months;
>   2. previous allocations/assignments under this policy must continue
>      to meet the justification requirements of this policy;
>   3. previous allocations/assignments under this policy must meet the
>      utilization requirements of end user assignments;
>   4. the applicant must demonstrate that no other allocations or
>      assignments will meet this need;
>   5. on subsequent allocation under this policy, ARIN staff may  
> require
>      applicants to renumber out of previously allocated / assigned
>      space under this policy in order to minimize non-contiguous
>      allocations;
>   6. recipient organizations must be members in good standing of ARIN.
>
> Rationale for reserving IPv4 space:
>
> This policy provides predictability on how the end game of IPv4 is  
> going
> to be played after IANA completion. It will facilitate IPv6 deployment
> by ensuring that some small chunks of IPv4 space will remain available
> for a long time to ease the co-existence of IPv4 & IPv6.
>
> Rationale for reserving a contiguous /10
>
> This is a balance between setting aside too much space and not having
> enough to facilitate IPv6 deployment for many years. Out of the  
> last /8,
> that would leave the equivalent of 3 /10 to ARIN either for business  
> as
> usual or for other policies in the spirit of this one.
>
> A /10 represents 4,194,304 IP addresses, If all of them were to be  
> used
> in NAT-PT or NAT464 type devices with a consolidation factor of 100
> users behind each IP address, that would represent about 400 million  
> users.
>
> Most networks today filter IPv4 announcements more specific than /24.
> This policy creates allocations & assignment prefixes as long as /28.
> Allocating out of a contiguous block will mitigate the impact of this
> policy on filter lists.
>
> Rationale for minimum size allocation of /28
>
> This minimum size allocation will put a cap at 250k additional entries
> in the global IPv4 routing table.
>
> Rationale for maximum size allocation of /24 and for the 6 month delay
> between allocations
>
> This maximum allocation size coupled with the requirement of a 6  
> months
> delay between allocations will prevent hoarding and make sure this  
> pool
> will last several years.
>
> Rationale for forced renumbering for further allocation
>
> The minimum allocation size of /28 may create a huge increase in the
> IPv4 routing table size. Forcing renumbering for subsequent  
> allocations
> under this policy will somehow limit the growth of the routing table
> size by enabling the announcement of aggregated space. It is expected
> that the savings in routing table entries will outweigh the pain of
> forced renumbering.
>
> However, renumbering is never an easy task, so it should only be
> considered as last resort. it is expected that sparse allocation
> techniques will prevent the need of force renumbering for a fairly  
> long
> time.
>
> Note: This policy proposal hints that the /10 should come out of the
> last /8 received by ARIN from IANA. However, it does not say so
> explicitly, leaving the final decision up to the ARIN staff.
>
> Timetable for implementation:
>
> As soon as ARIN gets its last /8 allocation from IANA.
>
>
>
>
>
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081023/62e9f629/attachment.htm>