[ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments]

william(at)elan.net william at elan.net
Mon Apr 25 21:25:04 EDT 2005

On Mon, 25 Apr 2005, Lea Roberts wrote:

> A large number of folks worked very hard to develop a "coordinated" IPv6
> policy among all the RIRs, which included the /48 recommendation from the

And I'm very grateful to people involved and I'm sure all of us thank
them for all the work done. But despite best efforts as to global RIR
coordination, the uniform policy did not last more then 1 years...

Now, I'm not saying it was bad that we have have worked together, but I
do think that beyond some general standards as to prefix size that do
need overall RIR & IETF coordination (like this /48), the actual details 
of the policies do not necessarily need to be exactly the same for each 
RIR, so if we get consensus for micro-allocations in ARIN region for IP6, 
we should go ahead.

> All of these carried the caveat that they would be revisited after
> "operational experience" was gained.

Do you really believe we now have lot more operational experience with 
IP6 in just last 2 years? And in ARIN region? Be serious!

> There is now beginning to be operational experience that shows very 
> large allocations being justified under the current criteria, which

In other messages you mentioned that these very large allocations are /19
in RIPE region. This does not necessarily means its /48 boundary that is
causing it and it maybe that general allocation policy is too lax or allows
for too large an initial assignment and adjusting such policies could be 
enough without necessity to actually change /48. In any case as this is a 
problem being seen at the RIPE region, they should analyze it first and 
then if they believe changing /48 boundary is best way to reduce requests 
for these large allocations, they can certainly come to all RIRs and we 
should consider it.

> suggests revisting the policy parameters and noting that perhaps the 
> assignment pendulum swung a little too far toward the "there should be 
> no limits" end.  Just because there is a safety valve doesn't argue for 
> reaching that point any sooner that prudent but non-restrictive 
> allocation policy would allow.

Lets talk numbers, shall we?

Lets assume for the moment that absolutely every person/end-user connected
to IP6 Internet global network is going to have a local lan and will thus 
justify /48 (and not just /64). Now taking into account that all assignments
in ip6 are made from /2 (leaving 3/4 space in reserve) we have 2^46 or
slightly over 2.8x10^14 (about 281,000 billion!) of such /48 nets to 
assign to users - for comparison in case you don't know, the number of 
people on earth right now is 6 billion and most doubt the earth could
sustain more then 20 or 30, lets take 30 for now, which is 30*10^9 and
is still 100,000 times larger then number of ip nets that can be assigned!

Now another interesting way to look at it is to compare RIR ISP allocations
in ip4 and in ip6. Again lets assume that every end-user gets /48 in ip6
instead of single ip address as done with ip4. With IP4 current ISPs get
allocated from /22 to /8 from RIRs (in case you don't know last ARIN block
of 73/8 was allocated almost entirely to Comcast), so there is wide variety
of sizes of allocation depending on the size and needs of the ISP. So how
does that compare to IP6? Well /8 to one ISP is 2^24 of ip addresses and
for ip6 2^24 /48 netblocks is allocation size of /24 - true, this is smaller
then /19 that somebody got, but its no longer then far off.

Plus lets now consider that smaller ISPs with IP4 get /20 (/22 with
micro-allocation policy) where as with IP6 they all justify /32. The 
difference between /20 and /8 is 2^12 which is almost exactly the 
difference between /32 and /19 (there its 2^13). So what I see is that 
RIPE might have applied in their allocations the difference as way to
justify that large block rather then deciding it based purely on number
of ip addresses (netblocks) needed. I think this is something that their
policy can fix to bring maximum assigned block to one entity to something
like /24 (i.e. comparable to /8 in ip4).

Also even if RIRs continue to have to allocate /19s to some LIRs/ISPs, is
it really such a big immediate problem? In IP4 space, we have total of
256 /8 with less then 1/2 in use, but lets take it as full 256 /8 nets. 
Now lets assume that everyone who has /8 in ip4 can manage to get /19 ip6
from RIR. That means that /11 would be consumed by such allocations - and
that is out of /2 that we have - it is still just 1/16th of the pool!

Now, I don't know if my math convinced you, but I REALLY don't see those 
numbers as being of immediate concern to change allocation and move away
from /48 boundary.

William Leibzon
Elan Networks
william at elan.net

More information about the ARIN-PPML mailing list