[ppml] 2005-1 or its logical successor

Christopher Morrow christopher.morrow at gmail.com
Tue Nov 1 10:58:47 EST 2005


some below, and jumping in to bill's actual message since I missed the
original. Keep in mind that I personally think that the 'classfulness'
being imposed on ipv6 seems bad... It's convenient, but it's just
wasteful.

On 11/1/05, Glenn Wiltse <iggy at merit.edu> wrote:
>     I'm not at all sure there should be a requirment that the "sites" be
> one per metro area... or that there be any such restriction per metro
> area. I supose it depends on how you actualy define 'metro'. Perhaps
> something better that could be just as easily verified, is that each
> site must have a unique street address, etc... Perhaps you might think
> /48 per street address is a bit much, I guess that would depend on how
> large the building was/is. Maybe a /52 per street address could work.
>

I think the 'metro area' part was more an effort to say: "It's ok to
have 1 assignment of $size to each place you want to light a
connection, but we don't really want to support folks just asking for
PI 'because'." So making a metro, or location dependent proposition
seemed reasonable. (for folks with disparate locations and no backside
network connecting them all together)

>    Either way, I think the one site per metro area is too restrictive,
> perticularly in the sense that it would pretty much eliminate any direct
> assignments to originzations that may entirely located in a small
> geographic area.
>
>
> Glenn Wiltse
>
> On Fri, 28 Oct 2005, Bill Woodcock wrote:
>
> >
> > So Chris Morrow and Mike Hughes and Thomas Narten and I were talking more
> > about this over dinner, and I think the consensus out of that conversation
> > was this:
> >
> > - an IPv6 direct-assignment policy should be based directly on the ipv4
> >  direct-assignment policy, as closely as possible.
> >
> > - one-size-fits-all probably isn't useful in the long run.
> >
> > - host-counts are stupid.
> >

the reasoning behind this (forgive me if someone else already said
this) is: "Multihoming is a business decision, not a size decision".
Basically, there are lots of new regulations coming around that will
'require' mutlihoming (provider redundancy sorts of things for end
sites) that have nothing to do with the size of the organization under
the thumb of the regulation.

You may legittimately have a single front-end e-commerce site that
supports millions of dollars of revenue, operating off say a very
small number if host addresses (www.google.com comes to mind
actually). Forcing the multihoming to have some arbitrary number of
ips in use seems counter productive. It's not the metric of interest
for this problem.

Also, there should be much more work done on other methods of
multihoming. Methods that make it simpler, and less globally intensive
for everyone in the long term. So, there may be flavors of multihoming
in the future that require PI and flavors that do not (and provide the
flexibility to switch providers at will with little penalty to the end
site).

My major issue with the 2005-1 proposal was it's 100k host count
requirement, it just seemed like the wrong way to measure for this.

> > - a strict multi-homing requirement is perfectly reasonable.
> >
> > - preexisting IPv4 deployment should qualify you for IPv6 assignment.
> >
> > - the size of the assignment should probably be /48 times the number of
> >  sites you have already deployed.
> >
> > - in order to avoid creative interpretation of "sites," no more than one
> >  site per metro area should be counted.  That's arbitrary, but it's an
> >  objectively-verifiable quantity, which is what's needed for the ARIN
> >  analyst staff.
> >
> > Thoughts?
> >
> >                                -Bill
> >
> > _______________________________________________
> > PPML mailing list
> > PPML at arin.net
> > http://lists.arin.net/mailman/listinfo/ppml
> >
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>



More information about the ARIN-PPML mailing list