[ppml] /48 vs /32 micro allocations, answer: /48

Howard, W. Lee L.Howard at stanleyassociates.com
Thu Mar 17 09:50:33 EST 2005


> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Paul Vixie
> Sent: Wednesday, March 16, 2005 7:40 PM
> To: ppml at arin.net
> Subject: Re: [ppml] /48 vs /32 micro allocations, answer: /48 
> 
> 
> > In any case there seems to be a strong consensus that /48's 
> are ok for 
> > microallocations.
> 
> not from me.  RIRs should allocate only /32's and /128's, and 

Would it be possible to allocate /128s?  I'd sleep better if we
could allocate off the tail end of the 128 bits, knowing that
every 10-20 years we'd have to add a bit.

> the latter only to critical infrastructure like root name 
> servers.  

Note that "critical infrastructure" is used more broadly in 
current policies, section 4.4 http://www.arin.net/policy/index.html

  ARIN will make micro-allocations to critical infrastructure 
  providers of the Internet, including public exchange points, 
  core DNS service providers (e.g. ICANN-sanctioned root, gTLD, 
  and ccTLD operators) as well as the RIRs and IANA. These 
  allocations will be no longer than a /24 using IPv4 or a /48 
  using IPv6.

So we may need to have a conversation around that definition 
for IPv6.

Of course, there are other questions within the narrow "root
operator" definition.  Does each IPv4 anycast root get its own IPv6
allocations?

> the dominant cost is "routing table slot" and this 
> cost should not be paid unless there is a universal benefit.  
> critical infrastructure is one such benefit.  "enough stuff 
> to warrant a /32" is another such benefit.  where's the 
> unique yet universal benefit of a /48?

Proponents of the current policy argued that a /48 is a nice
round bit boundary, and large enough that an LIR (or RIR in
cases) could say, "Fine, whatever, here's your /48, now go 
away and don't bother me again."

I'm glad to see general use of "routing table slot" as an
economic concern.  large-but-finite = scarce
 
Lee




More information about the ARIN-PPML mailing list