[ppml] IPv6 assignment - proposal for change to nrpm

[Leo Bicknell]

In a message written on Sun, Oct 21, 2007 at 10:08:25PM -0400, briand at ca.afilias.info wrote:
> With a /32, giving out /48's and doing internal aggregation, a new block
> may be needed in as little as 20k assignments - and under current policies,
> would be a perfectly acceptable basis for requesting an additional block.

I'm wondering how many ISP's in the ARIN region have more than 20k
assignments.  I'd be surprised for sure if the number was more than
500, and suspect it's under 100.

Now, some of those will come back and fit in their reservation.
IIRC ARIN is assigning each /32 out of a reserved /28 for that
network to grow into and still take a single routing slot.  That
reduces the number.

Also, some large networks have justified right out of the gate
something larger than a /32 based on current customer counts.  If
that has been done properly, they will not need to come back.

Thus it would seem to me the risk is small, probably well less than
500 ISP's, and likely under 100 who would need a second prefix in
any reasonable amount of time.  That's hardly table bloat.

> Static assignments and DHCPv6 assignments, for prefixes > /64, are not only
> possible, but fully compatible with the IETF specifications.

However, they do preclude the use of IPv6 autoconfiguration.  Now,
I am not going to debate the merits of that particular protocol;
but I will say as long as it is an IETF standard and in use in the
community I don't support ARIN policies that would make it useless.
It is for that reason I can't support any ARIN policies requiring
an ISP to allocate longer than /64 prefixes.

I fully support things like encouraging people to use /126's on P2P
links and other economies and think it would be nice if we could
find a policy mechanism to encourage that without creating unfair
advantage.

The bottom line is there are 26,000 ASN's in the routing system
today (http://www.cidr-report.org/as2.0/), even if 10% of the
prefixes handed out were too small for their networks and got a
second one, that would be 28,600 prefixes in the routing table.
Compared to the 239,000 today that's a huge win.  Heck, even adjusted
for the 4x size it would be 114,400 IPv4 Route equivilants, cutting
the memory needed for a table in half.

To provide a different perspective.  I think we are giving away
blocks that are too large.  We have reinvented classful networks
with the /48 and the /64.  One day we will wake up and implement
exactly what you suggest, using smaller networks like /120's for
small LAN's.  This is just like we woke up from CIDR and starting
using VLSM.

There's good news though, from an RIR perspective we're only giving
away the equivalent of IPv4 /8's.  Due to CIDR improvements most
companies who got a /8 of IPv4 have never been back for more, they
are still eating from that original allocation.  The same will be
true in IPv6, I suspect almost everyone who has a /32 will fit in
it forever, as long as we wake up and do the right thing with prefix
lists.

But how did we get routing table bloat?  The Class C swamp.  Small
prefixes, not aggregatable.  This is exactly why we don't want ARIN
giving out /64's today, or /80's, or /120's.  That is how we will
get routing table bloat in the future.

But back to your current goal.  Get the IETF to deprecate IPv6
auto-configuration; which will remove the /64 boundary as sacred.
At that point I'd be willing to talk about prefixes longer than a
/64 being required, until then it's premature.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20071021/c1cefff0/attachment.sig>