[ppml] IPv6 initial allocation policy

[Owen DeLong]

If IPv4 space runs out, nothing changes unless IPv4 policy changes.

If IPv4 policy changes, it is unlikely that it would be done without
consideration of effects on IPv6 policy at the time.  In the meantime,
this seemed like the best available yardstick given the limitations
we are faced with:

1.	Host counts have been determined to be a bad metric.
2.	Locations or Sites have been determined an inaccurate metric.
3.	Noone has presented a better metric.

As such, we are faced with two choices:

1.	Copy current IPv4 allocation and assignment policy in it's entirety.
2.	Incorporate it by reference with the understanding that future
	updates will affect both policies.

Of these choices, I believe the latter to be preferable at this time.

Certainly, this is a greater concern with 2006-4 which is completely
tied to possession of existing IPv4 space.

Owen


--On March 13, 2006 1:06:06 PM -0800 Tony Hain <alh-ietf at tndh.net> wrote:

> Owen,
>
> One consideration for 2005-1 is what happens when IPv4 space runs out? A
> related question is what if IPv4 PI space becomes harder to get over
> time?
>
> Fundamentally, why should IPv6 PI space have anything to do with IPv4 PI
> space?
>
> Tony
>
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
>> Owen DeLong
>> Sent: Monday, March 13, 2006 11:29 AM
>> To: Anthony A. Crumb; ppml at arin.net
>> Subject: Re: [ppml] IPv6 initial allocation policy
>>
>> I don't know about a coalition of companies, but, in the ARIN region,
>> there
>> are at least 2 policy proposals under discussion to try and resolve this
>> issue.  Kevin Loch and I have authored 2005-1 which is one of the
>> proposals.
>> Andrew Dul has authored 2006-4 which is the other.  2006-4 is more
>> restrictive
>> and limited to much larger organizations (requires 80% utilization of at
>> least an IPv4 /19 and makes no allowance for sites which do not already
>> have at least a /19 IPv4 direct assignment).
>>
>> I hope you will support 2005-1 as I believe it provides a solution to
>> not only the largest and wealthiest companies, but, also to any company
>> currently eligible for IPv4 PI space.
>>
>> Owen DeLong
>> Policy Author
>> DeLong Consulting
>> owen at delong.com
>> 408-921-6984
>>
>>
>> --On March 13, 2006 10:07:27 AM -0600 "Anthony A. Crumb"
>> <Crumb_Anthony_A at cat.com> wrote:
>>
>> >
>> > My organization has begun working through the definition of an
>> enterprise
>> > IPv6 acquisition, allocation, and deployment strategy. I was charged
>> with
>> > identifying the process required to acquire IPv6 address space from the
>> > three registrars (ARIN, RIPE, and APNIC) from which we currently have
>> > carrier independent IPv4 allocations. Our thoughts are, because we have
>> a
>> > dual carrier connected Internet POP within each of these IPv4
>> allocations
>> > we should request provider independent IPv6 space from each of the
>> > registrars. Imagine my surprise when I found that each registrar has
>> > adopted a policy that does not allow for the assignment of carrier
>> > independent IPv6 address space to end customers. This policy runs
>> counter
>> > to an obligation to our customers, supplier and dealer to provide no
>> less
>> > than two connection paths into and out of our Internet facing network
>> > application environments. Not to mention robbing us of the leverage
>> > needed to be able to shop our very considerable WAN circuit business
>> > between carriers. Is anyone aware of a coalition of companies that is
>> > working together to over turn this policy?
>> >
>> >
>> >
>> > Anthony A. Crumb
>> > Enterprise IP/DNS Management
>> > Global IT Solutions, Caterpillar Inc.
>> > Email: crumbaa at cat.com
>> > Phone:  309-494-7816
>>
>>
>>
>> --
>> If it wasn't crypto-signed, it probably didn't come from me.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060313/697d65f5/attachment.sig>