[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