[ppml] 2005-1 or its logical successor

Marshall Eubanks tme at multicasttech.com
Fri Oct 28 08:07:58 EDT 2005


Good morning all;

On Fri, 28 Oct 2005 12:21:33 +0100
 Michael.Dillon at btradianz.com wrote:
> > - one-size-fits-all probably isn't useful in the long run.
> 
> Yes.
> 
> > - host-counts are stupid.
> 
> Agreed. The size of v6 allocations is not related
> to the number of hosts. Hostcounts are v4 thinking.
> 
> > - a strict multi-homing requirement is perfectly reasonable.
> 
> Yes. And since this requires an ASN and since there are
> some 12,000 ASNs in the ARIN region this would tend to
> limit the number of end-user PI blocks to the 5,000-10,000
> range which some people desire.
> 
> > - preexisting IPv4 deployment should qualify you for IPv6 assignment.
> 
> Yes. Why do people need IPv6 addresses? To deploy a network.
> How do they prove that they will deploy a network? Show
> that they have already done so using v4 addresses.
> 

I agree. I do not think it should be the only requirement (v6 only deployments
should count too !).
 
> > - the size of the assignment should probably be /48 times the number of
> >   sites you have already deployed.
> 
> More or less. Round this number up to some rational

Agree 

> bit boundary. And I assume that the "already deployed"
> refers to preexisting v4 deployment.
>  

It could be  IPv6 deployment  too. (I keep thinking of the IPv6 only cell phone
providers we keep hearing rumors about.)

> > - 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.
> 
> No, too restrictive. I agree that we need a verifiable
> definition of "site" but I think this can be done in a 
> way that allows multiple sites per city. Two possible ways
> to prove it to ARIN analysts are to provide an IP address
> per site that can be tracerouted to show a unique path
> or ISP bills/contracts that demonstrate one circuit per
> site. I'm sure that there are other ways of proving site
> count such as municipal tax bills, water bills, etc.
> 

I agree with Michael here.

I also don't think that any  restriction to "city" or "metro  area" is well posed, at least
from a network standpoint. In the US, the census defines metro areas, and these change every ten
years. Moreover, this says nothing about network topology. As as example, I have a router in Tysons
Corner, Virginia (unincorporated Fairfax county, Washington DC metro area). If I decide to multihome
with Sprint, and put a router in their facility just down the road, a  completely different location
from the standpoint of network topology, but also unincorporated Fairfax county, Washington DC metro
area, why should that not count as a different location ? Or, conversely, I might put a  router in
Equinix Ashburn (10 miles away, but in a different county). Is that in a different  "city" ? (At
least in the 1990 census, it was not in the Washington DC metro area.) Or maybe I put  a site  in
Columbia, Maryland - same metro area (I think), but in a different state, and a good 50+ miles away.
Is ARIN going to set up some  tool to or hire people to figure  out if all these  sites are actually
in the same area ? Is Newark, N.J., going to count as the same or a different city  from New York
city ? I don't think  that ARIN  should be involved in this, it seems like a good way to waste time
and resources.

> Rather than define "site" we should refer to IPv6 RFCs 
> which talk about how to assign /48s. As long as the count
> is consistent with IPv6 network design practices, it should
> be allowable. If a company has one router per floor of
> their building, then it is one site per floor. If they
> have one router per building on their campus then it is
> one site per building.
> 

I think that this  is at lot more reasonable.

> --Michael Dillon
> 

Regards
Marshall Eubanks

> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml




More information about the ARIN-PPML mailing list