[ppml] Motivating migration to IPv6

[Brian Dickson]

Craig Finseth wrote:
> This is one of the more intelligent proposals that I have seen on this
> list lately...
>
>    I'm sure the following idea has to have occured to better minds than mine,
>    but I _cannot_ see what the downside to it is --
>   
Scalability is the downside.

Consider:
We have had serious scalability problems on current IPv4 hardware due to
the deaggregation and proliferation of IPv4 routes.
That is notwithstanding the very limited amount of IPv4 space.

Any proposal which duplicates (or worse!) the allocation of IPv6
*quantities* of prefixes, e.g. on the basis of IPv4 prefixes, only dumps
this problem, wholesale, into an otherwise pristine IPv6 DFZ.

I have been, and continue to be, a proponent of a DFZ which as an
absolute minimum number of IPv6 prefixes per ASN. Sizes of PI blocks
don't matter, its the *number* of PI blocks that matter. A /64 takes the
same number of router slots as a /48 or a /32 or a /96 - that is to say,
one router slot per prefix.

I am all in favour of giving out exactly one IPv6 block (of PI space)
per ASN, sized appropriately (e.g. sufficient for 10-20 year needs at
least).

It's difficult to make a case that 2^64 of address space (as in, a /64),
let alone much larger blocks, *per ASN*, wouldn't be enough, given that
we have fewer than 2^34 people on the planet.

So, as a favour to us all, *please* don't propose any solutions which
require handing out more than *one* PI block to any organization. Two,
if they need PI space that won't be part of the DFZ (e.g. as an
alternative to ULA-{C|G} allocations).

Thank you in advance for considering the DFZ as a whole, as opposed to
merely the needs of individual participants of the DFZ. (The DFZ, by
definition, has to exist in its entirety on *someone's* hardware, and
ideally should be able to fit on most folk's biggest pieces of hardware.)

Brian Dickson