[arin-ppml] IPv6 Allocation Planning

[William Herrin]

On Mon, Aug 9, 2010 at 8:23 PM, Joel Jaeggli <joelja at bogus.com> wrote:
> There are quite a few people on this list who've had deployed dual stack
> ipv6 networks for longer than it took us to put a man on the moon.
>
> Jaded rather than inexperienced is the first thing that some to mind.

Hi Joel,

There were plenty of jaded IPv4 gurus in 1993. Those that survived and
were still acknowledged gurus were far wiser and more knowledgeable in
2003.

My point is: there's a lot about IPv6 policy we can't yet predict with
a high confidence. We'll do the best we can and we'll change it when
we learn better, but for now there's still a lot of guesswork
involved.

There are, however, two routing factors related to IPv6 addressing
policy we can evaluate with a high degree of confidence. Because we
can accurately predict them and because the routing table continues to
have scarcity issues when the IPv6 address pool doesn't, I propose
that these predictable routing factors should weigh distinctly more
heavily than the factors whose prediction is less certain.

* We can predict the difference in the minimum number of routes in the
table as a result of a given policy change.

* We can predict the difference in the maximum number of routes in the
table as a result of a given policy change.

Owen's proposal doesn't change the minimum. It's still 1 per ISP.

Owen's proposal hands out more /32's without offering any mitigation
to obstruct them from being disaggregately announced as /32's. Thus is
significantly increases the maximum number of routes possible in the
table.

Arguably the policy could reduce the total number of blocks held by
any given ISP by reducing their likelihood of coming back for more. So
there's the outside possibility that an ISP who would otherwise have
announced two separate blocks will instead hold and announce only one.
But even if we could accurately quantify that (and we can't) the ISP
would still hold at least as many disaggregable /32's.

No change to the one predictable routing factor (minimum).
Significantly worsens the other (maximum). Everything else being
equal, that makes it a bad policy change.


What, then, would a good policy change look like under this evaluation
process? Suppose:

* Allocate or assign addresses only in standard sizes: /48, /40, /32, /28, /24.
* ARIN rounds up to the smallest standard size that the application justifies.
* Allocations from published blocks containing allocations of only
that one standard size.

The minimum routing table impact remains 1 per ISP.

Maximum is limited to 1 per allocation. ISPs may choose to allow
moderate disaggregation of a standard size for the purpose of traffic
engineering. They may not. But that's their choice. Accepting
disaggregates for any allocation is no longer an inevitable confluence
of technology and ARIN policy.

The policy tends towards handing out more addresses (round up) so it
arguably reduces the rate at which ISPs return for more, as with
Owen's idea. Still can't accurately quantify that, but we know for
sure that no ISP will carry a /28 as 16 /32s unless they want to.

No change to the one predictable routing factor (minimum). Distinct
improvement the other (maximum). Everything else being equal, that
makes it a good policy change.


Now, suppose you did both standard sizes AND you also did Owen's
change? Well, look at that, with both changes Owen's proposal doesn't
worsen the maximum routing table impact at all. More addresses are
handed out but they don't disaggregate.

See my point?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004