IPv6 PI allocation

[Nick Hilliard]

Jun-ichiro itojun Hagino 2.0 wrote:
> 	http://www.ripe.net/ripe/meetings/ripe-54/presentations/IPv6_Routing_Table.pdf
> 	on page 13, it says that there re 100 /48 prefixes announced worldwide.
> 	among them, 50 are PI allocations, which means 5% of the total # of
> 	prefixes (it is below 1000).
> 	we have to stop PI allocation, or we need to have totally different
> 	algorithm for routing (mathematician please help me).

itojun-san,

"Worse is better"

The original article on http://naggum.no/worse-is-better.html applies to 
lisp vs C, and I'm sure you've read it before.  But the same principle 
applies here: that as a general engineering principle, correctness can and 
should be sacrificed where the consequences of implementing correctness 
would create proportionally more brokenness.

We do not have an alternative to PI6 assignment at the moment, and other 
than the proposed shim6 - which a large number of people have serious 
problems with (me included) - there are no alternatives on the horizon.

Commercially, people need ipv6 multihoming.  It's not a luxury, but 
something on which peoples' businesses and livelihoods depend. There are 
lots of situations where it is not appropriate for an organisation to 
become a LIR and get their own PA allocation, but where they need 
connectivity from multiple providers.

If we stop PI6 assignments, then we would have a situation where we had a 
functional ipv4 multi-homing solution, but no functional ipv6 multihoming 
solution.  This in itself would kill ipv6 deployment, because ipv4 would 
then have a significant technical advantage over ipv6 for end-users.  Why 
regress to something less functional?

IPv6 has been around since 1996, and since then no good, functional 
multi-homing solution has appeared.  If we're going to try to foster any 
sort of commercial uptake of ipv6, we cannot wait any more:  we need a 
solution now.  In fact, we needed a solution several years ago.

Shim6 does not exist now, and when the protocol finally crystallises, it 
will require updating all ipv6 end-point stacks.  This is a massive 
undertaking, which would take several years from the point where we had 
shim6 implementations which are good enough to deploy in production. 
Realistically, the earliest we could even think about deploying shim6 in 
anger would be 4-5 years from now.  This is no use - ipv4 will be long 
finished by then.

And there are practical implementation issues associated with shim6 which 
lots of people will find unacceptable.  How are you going to provide 
technical support to stupid end-users with a difficult shim6-related 
routing problem?  It's hard enough to support them on ipv4 at the moment. 
  Remember that technical support is a cost centre.  It doesn't make 
anyone money to provide technical support.  We need end-user simplicity, 
not end-user stack complication.

On the issue of prefix counts, yes, pi6 will inpact the routing table. But 
due to the aggregated nature of PA6 allocations, we're going to have a 
much smaller ipv6 DFZ table than the ipv4 DFZ table.  The primary reason 
that we have such a fragmented ipv4 routing table right now is due to 
contraints brought on by a shortage of ipv4 address space.  We don't have 
those constraints in ipv6, and won't need to allocate piles of disjoint 
address blocks to individual LIRs to provide for their 2 year addressing 
requirements.

I'd also like to see a good alternative to pi6 space.  But we don't have one.

Nick