[arin-ppml] IPv6 Allocation Planning

[Ted Mittelstaedt]

On 8/6/2010 12:37 PM, Owen DeLong wrote:
> In thinking about address planning and deployment, I've been doing
> some various math.
>
> It seems to me that we have more than enough addresses to use the
> following methodology without any concern for exhaustion or shortage
> for a very long time. It also seems to me that the advantages in
> terms of human factors and network planning simplicity are large
> enough to be worthy of consideration.
>
> As such, I'd like to get community input on whether they would
> support policy that would allow ARIN to issue ISP allocations on this
> basis:
>
> 1.	Take your number of end-sites attached to each pop. Round up to
> the nearest value of x such that x = 2^n where n % 4 = 0 (in other
> words, round up your POP size to a nibble boundary).
>
> 2.	Take your expected number of POPs, say a Z-year plan (I seek
> community input on the desired value of Z, I'm thinking 5 years).
> Again, round up to a nibble boundary. Let's call this value y.
>
> 3.	Multiply x*y to get the number of /48s (ISP) needed. Convert this
> to a number (n) of bits (2^n=x*y).
>
> 4.	ARIN should approve you for a 48-n prefix or a /32, whichever is
> larger.
>
> Examples:
>
> 3000 end sites per POP 154 POPs
>
> 3000 rounds up to 4096 (12 bits). 154 rounds up to 256 (8 bits).
> Total need: 1,048,076 end sites (20 bits)
>
> 48-20 = 28 -- This provider should receive a /28.
>
> --
>
> 53,000 users per POP 350 POPs
>
> 53000 ->  65536 (16 bits) 350 ->  4096 (12 bits) Total need:
> 268,435,456 /48s (28 bits)
>
> 48-28 = 20 -- This provider should receive a /20.
>
> --
>
> 300 End sites per POP 10 POPs
>
> 300 ->  4096 (12 bits) 10 ->  16 (4 bits)
>
> 48 - 16 = 32 -- This provider should receive a /32.
>
> I think the above examples are a reasonably representative set of
> values for medium, large, and small providers.
>
> I realize that the resulting values result in a tremendous amount of
> extra space being issued as a result of the double rounding, but, I
> believe it is worth while for the likely gains in aggregation.
>
> To put it in perspective, if we took twice as many ISPs in each
> region as there are active ASNs in the entire IPv4 internet today,
> and gave them all /28s, we would barely use up the first /12 in each
> region. We would still have tremendous room to grow within the first
> 11 /12s out of 512 that are contained within 2000::/3.
>
> In my estimation, the average allocation under this scheme would
> likely work out very close to that, but, even if I'm off by a factor
> of 16, we'd still only use most of 176 /12s and we'd have 336 /12s
> untouched in 2000::/3 with the internet being more than double its
> current size.
>
> Please let me know what you think of this idea. If it receives some
> positive feedback, I'll start working on turning it into policy.
>

I would not support something like that.  I do agree that the philosophy
of an IP addressing shortage should not apply for IPv6
allocations and we should be much more generous for initial
IPv6 allocations than for IPv4 allocations.  But, my concern is
that the justifications your proposing are too specific and seem
to fix the idea of an Internet organized around POPs and carriers
and the current idea of what it is today.  Like William I feel the
RIR should merely require a reasonably logical business plan for
any allocation over a /32 and be done with it.  I would suggest
if you want to mod policy to encourage large initial allocations
that you look at section 6.5.1.1 and rewrite that - you could start
by changing 5 years to 10 years, for example.

It has also been my observation that orgs have multiple AS numbers, and
many times will subnet their allocations and advertise them under
multiple routing slots anyway so as to load balance, thus I think
the logic of if orgs all have contiguous allocations organized in a
single subnet that it will slow routing table growth to not be
believable.

My personal belief is that the global BGP table will continue to
grow and the bulk of the growth will be driven by increasing
fragmentation of the IPv4 space.  I have very little faith that
the Internet is going to switch to IPv6 right after IPv4-runout, because
the Internet is large enough now that people will make decisions
on switching to that which is most favorable to -them- and screw
everyone else.

It is like the use of fossil fuels and global warming on a planetary
scale.  We all know that collectively, our use of fossil fuels
is raising the planet's temperature and we are going to have melted
polar icecaps and increased sea levels and all of that as a result of
it, and so we should curtail use of fossil fuels to below the level
where the planet's natural processes can sequester the carbon produced.
However, most of us on an individual basis, every day decide to continue
using fossil fuels because the decision to do this benefits us on an
individual basis.  When I use a quart of gasoline in a lawnmower that
cost me $20 at a garage sale to mow my lawn, I save $480 over the guy
who buys the new $500 electric lawnmower and pays the power company
extra money for the wind power, to mow his lawn.  That's why there's
only 1 of that guy for every 500 of me out there.

After IPv4 runout, for every 1 admin who runs IPv6 and pushes their
customers to use it, there will be 500 who will just go buy more
IPv4 on the "transfer" market, or offer IPv4 NAT solutions, because
this will benefit their individual company.

It is going to take increasing infrastructure costs to drive IPv6.
It will take a huge rise in tech support costs in delivering RFC1918
to customers, or huge rises in the cost of buying IPv4 on the transfer
markets, or huge rises in the costs of new cards for routers because the 
old ones have too little ram, before ISPs will finally start passing 
those costs along to customers, and until that happens we won't see 
change to IPv6.  And those costs won't rise until every last scrap of 
IPv4 is in play, which means hauling a lot of small assignments out of 
the swamp that they have gone into.

Ted

> Thanks,
>
> Owen
>
> _______________________________________________ PPML You are
> receiving this message because you are subscribed to the ARIN Public
> Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your
> mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
> info at arin.net if you experience any issues.