Subject: (IPng 7283) Re: Ipv6 Migration

From: [email-masked] (Tim Hartrick)
Date: Fri, 5 Mar 1999 09:47:57 -0800

Chris,

> 
> This is how it would operate.
> 
> 1. Application calls gethostbyname() to look up a host address.
> 
> 2. gethostbyname() invokes DNS and finds an IPv6 address.
> 
> 3. gethostbyname() allocates an IPv4 address from a pool kept for this
> purpose, sets up a mapping between the v4 address and the v6 address
> obtained from DNS, and returns the v4 address to the application.
> 
> 4. Application does its stuff, making sockets calls from time to time.
> 
> 5. Sockets calls recognise the v4 address as being from the pool, and
> communicate via IPv6 to the v6 address to which the v4 address is mapped,
> instead of using v4.
> 
> 6. When an application binds to a v4 address from the pool, subsequent
> sockets calls do a similar v4-v6 translation.
> 
> This doesn't actually require standardization. An individual vendor who
> obtained a block of IPv4 addresses could do it without consulting anyone
> else. But there could be advantages in allocating a single block of IPv4
> addresses for everyone to use in this way.
> 
> The questions are:
> 
>    Will this work?
> 
>    Should it be required behavior for conforming UNIX implementations?
> 

The answer to the first question is certainly yes with the performance and
NAT caveats that Jim and Brian have noted.  We actually implemented a very
simple version of this three years or so ago.  It allowed us to use regular
IPv4 only Netscape, ftp and telnet on MacOS and Windows NT and communicate
using IPv6 to a IPv4 only servers that were using the same mapping technique.
The KAME folks have done a Windows 9[5?|8] "bump in the stack" implementation
which basically does the same thing.

The problem is that this is not free.  It really ends up being NAT in a host
because for applications like ftp which embed addresses in their data stream
you need to look at every piece of data sent by the application so you can
convert the PORT command on the fly to the IPv6 equivalent of your choice.
It is simpler than NAT implemented in a router since you don't need to monkey
with the TCP sequence numbers to fix up the embedded addresses but it is still
a performance hit.  The resolver parts have similar issues both in performance
and NATlyness.

The technique definitely could be used in circumstances where you abolutely
can't get the applications updated.  For example on Windows 9[5|8] it may
be the only game in town.  I am not sure that it is a technique that one would
want to mandate however since it comes at significant cost.  That is at
least my answer to the second question.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------