[ppml] Principles for IPv6 PI allocations to end sites

[Bill Darte]

So....deriving a 'pain index' that establishes a threshold for PI?

Number of hosts to renumber,
Number of Firewalls and other embedded address devices,
Number of available ISPs to choose from(level of competitive opportunity), 
Multihoming Experience with BGP, 
AS Number etc.,

What factors would contribute to an objective mechanism of establishing
pain....

Or is all else dwarfed by numbers of hosts?

I am not in favor of 'arbitrary' boundaries.  100,000 hosts = PI, 99,000 not
enough pain = No PI?  Reasonable? Justifiable?

Still say that the problem is not with address policy, but with routing
technology/technique.

Why are other parts of the world experiencing growth of IPv6?

Less pain?, Willingness to accept PA?, Smarter geeks?, what?

Bill Darte
ARIN AC

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Edward Lewis
> Sent: Wednesday, February 08, 2006 10:43 PM
> To: Thomas Narten
> Cc: ppml at arin.net
> Subject: Re: [ppml] Principles for IPv6 PI allocations to end sites
> 
> 
> I haven't been able to read the 2005-1 thread, so this message is 
> quite welcome.
> 
> At 17:00 -0500 2/8/06, Thomas Narten wrote:
> >Here are some thoughts I have w.r.t. this topic. Generally, I'm in 
> >favor of coming up with a policy for granting PI space to large end 
> >sites. However, I am also very concerned that we do not open the 
> >floodgates and create a situation a few years down the road that we 
> >wish we weren't in.
> >
> >Some principles I keep in my mind as I evaluate various proposals.
> >
> >IPv6 space is a public resource, and we need to avoid having 
> a policy 
> >adopted today turn into an "early adopter bonus program". 
> That is, if 
> >5-10 years from now we have two classes of entities:
> 
> Are we truly concerned about "early adopters" when we have a hard 
> time getting IPv6 rolling at all?  (That's my snicker-eliciting 
> comment.)
> 
> "Early adoption" is already past tense in (at least) the APNIC 
> region.  I understand the point here, perhaps the label "early 
> adopter" is a misnomer though.
> 
> >Corallary: I don't buy the argument that "we can always change the 
> >policy later,
> 
> I have to disagree with this.  Coming up with a perfect policy is 
> difficult.  We can have a "perfect" design of a technical system, but 
> in a subjective environment such as address allocation policy I think 
> we ought to strive for a perfect policy but realize that it's a dream.
> 
> >Multihoming: we don't have a "magic bullet" multihoming solution on
> ...
> >One question that arises is fairness. Since we can't give PI space to
> ...
> >prefix in the DFZ. Hence, I tend to lean towards giving PI 
> space only 
> >to the largest end sites, i.e., those that will provide 
> benefit to the 
> >largest communities.
> 
> I think the above is the crux of the problem.
> 
> I'll agree that we ought to forget about a technical solution to 
> multihoming coming any time soon (snicker - one more broken promise 
> by IPv6).  Fairness is what this is all about - but I don't think the 
> size of the benefiting community is the metric.  (For example, if a 
> site is in the US but plans to market to China and will have it's web 
> site in the Chinese language, does that mean it caters to the 
> "largest" community.)
> 
> >There may be other metrics that we should consider; in any case, I do
> 
> I would think that the metric ought to be tied to the level of pain 
> of reacting to an event that would have driven a would-be PI user to 
> PI.  I.e., if the reason to want PI space to be to avoid having to 
> renumber out of a failed ISP's address range into another, then 
> priority ought to go to PI-wannabes with the largest address need. 
> (Or that have the largest number of firewalls which need to have 
> addresses configured, etc.)
> 
> >I believe we need to allocate PI space out of specific 
> prefix, so that
> 
> How would this differ from todays (IPv4's) swamp space?  I suppose 
> that it would only be within one RIR (but across LIRs to manage), but 
> it would be as painful to routing as the IPv4 swamp.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-=-=-
> Edward Lewis                                                
> +1-571-434-5468
> NeuStar
> 
> Nothin' more exciting than going to the printer to watch the 
> toner drain... _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>