Re: Modified IPv6 to unmodified IPv4

[itojun@itojun.org (Jun-ichiro itojun Hagino)]

> > Will code like that ever exist?  The changes to the sockets API (e.g. 
> > getnameinfo() and getaddrinfo()) has made it so that modern apps aren't 
> > any more v4-aware than they're v6-aware; they've become 
> > version-agnostic, not separately aware of v4 and v6, unless they have a 
> > specific reason to know.
> 
> Correct. I think the tricks that have to be played are below the
> socket interface. (Although there is the residual problem of applications
> that ignore RFC 1958, RFC 2101 and RFC 2775 by storing IP addresses for
> future reference, but that is probably insoluble.)

	for the new deployment of applications, there are middleware (so to
	speak) from freebit corporation, which allows the following:
	- application be IPv6-only
	- middleware deals with all the troubles of IPv6-over-IPv4 and stuff
	- OS kernel can be IPv4-only, if OS kernel is IPv6-only then the
	  middleware will do nothing

	this may help us for the new applications.


	about NAT and stuff, I think NAT-PT is the necessary evil.  it was too
	early to deprecate NAT-PT.  my assumption was below:
	- IPv6 to IPv6 is without NAT
	- IPv6 to IPv4 is somehow connected, with NAT-PT
	- IPv4 to IPv6 is - well, it is a bit difficult but maybe NAT-PT
	  with wacky DNS mapping
	- IPv4 to IPv4 is with or without NAT (today's situation)
	the point is to keep IPv4 to IPv4 just like today, keep IPv6 to IPv6
	to follow end-to-end principle, and end nodes must not be modified.

	note that there are commercial products available for NAT-PT, so you
	can deploy it today.  if you talk about new technology development
	today, it won't hit the market before 2010.

itojun