[ppml] Motivating migration to IPv6

> Date: Tue, 31 Jul 2007 15:29:51 -0400
> From: Brian Dickson <briand at ca.afilias.info>
> Subject: Re: [ppml] Motivating migration to IPv6
>
> 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.

Agreed.
>
> 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.

FALSE ASSUMPTION.

> 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).

What makes you think I made any such proposal? 

NOTHING prevents the RIR from 'reserving' a large block per requestor,
but actually _allocating_ it incrementally.

> 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.)


I'm playing with an idea that would allow _everybody_ to have their own 
"permanent" chunk of IPv6 space (i.e., would _not_ have to renumber if
they changed providers) and which would *NOT* adversely affect the the size 
of the DFZ. In fact it would significantly _shrink_ the routing entries 
required for the DFZ.  As in a _total_ of about 16,000 entries.

It actually accomplishes the 'uncoupling' of routing from address-space
prefixing.