Re: V6 still not supported

[Philip Homburg <pch-nanog-2 () u-1 phicoh com>]

> A host in the Internet that wants to talk to a host in China would require an 
> update to parse new DNS double-A (realm, address) records to encapsulate the p
> acket IP-in-IP, outer src= 240.0.0.1 outer dest=240.0.0.2. The router that ser
> ves the shaft at level 1 attracts 240.0.0.0/8 within realm 1 and routes up the
> elevator for more specific (host) routes within that prefix. The router that 
> serves the shaft at level 2 attracts 240.0.0.2/32 inside the shaft; upon the s
> aid packet it would swap the inner and outer destination and the packet would 
> reach the Chinese address with classical routing within realm 2. 
>
> Routers serving the shaft need an update, but then, only those do. Obviously t
> he host in China can only reply if its stack is updated to understand the form
> at. But all the other hosts and routers in China can be classical IPv4 as we k
> now them long as their traffic stays in China. To migrate to IPv6 what you can
> do is map the elevator shaft prefix in, say, 400::/3 (sadly cannot use F00/3 
> that would map 240 neatly but is already assigned). 
>
> The current internet would own 400:1::/32, China would own 400:2::/32, etc... 
> You encode the double-A of the host in the prefix, reserve a well known suffix
> for IPv4 mapped double-A, and you have an IPv6 address that can be mapped bot
> h ways statelessly. When migrating to v6, each IPv4 node that owns a public IP
> v4 address in one realm gets a full IPv6 /64 for free.
> "

Somehow this sounds a lot like 6to4: packets get routed to special devices
in the network and ISPs have little control over this. Not a popular
architecture.

Or another way to look at it is the resemblance with the ill fated 
'Provider-Based Global Unicast Addresses' (RFC 1884, Section 2.4.7). This
was not very popular either.