IPv6 PI allocation

[Jun-ichiro itojun Hagino 2.0]

> > 	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.
(snip)
> I'd also like to see a good alternative to pi6 space.  But we don't have one.

	hmm.  i have an RFC on it (RFC3178, Oct 2001), which uses two
	provider-aggregatable prefixes from two separate ISPs for multi-homing.
	with IPv6, it is a common practice for router(s) announcing multiple
	prefixes, right?
	i hoped that RFC3178 would stop PI allocations, but at that time people
	just did not get it.  i was lucky enough that the document made it
	to informational RFC level.

	i know shim6 and all the stuff.  RFC3178 have been a good solution
	for me and Hal Synder, who got 2 different prefixes for his home in MDT
	timezone - having tunnel from IIJ NYC NOC and SJC NOC (he end up being
	co-author for RFC3178).

	i'm asking openssh people to come up with disconnect/reconnect support.
	it will end the holy battle of MIP6 (which requires you to deploy RH2
	all over the place), because ssh with disconnect/reconnect support
	would be a perfect session layer for everyone.  if people want IP-layer
	mobility, they can just use ssh connection + tun* (BSD tunnelling
	interrface), with those you can tunnel packets over ssh connection.
	i hope to see it to become real.

	(i'm cc'ing openbsd people in JP timezone just in case they do not
	subscribe ipv6-ops)

itojun