Subject: (ngtrans) "Bump-in-the API" idea

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jun 1999 22:26:26 -0700 (PDT)

I've implemented an idea similar to Bump-in-the-stack.
The difference being that is doesn't intercept packets but that
it implements API calls from unmodified IPv4 applications
(socket, bind, connect, ..., gethostbyname, gethostbyaddr, inet_ntoa, 
inet_addr).

In Solaris I've build this as a shared object which is used by
	setenv LD_PRELOAD /usr/lib/ipv6map.so
	<run your favorite unmodified applications>
[LD_PRELOAD is a mechanism to tell the run time linker to load
an object before loading the applications and the shared libraries
which makes the preloaded objects symbols take precedence over
other symbols e.g. in the libraries. Without having to relink the application
binaries.]

This works when the OS (and protocol stack) supports IPv6
but there are some applications which are not modified.
Due to its imperfections it shouldn't be an excuse to not
port an application but instead a tool for those wishing to
deploy IPv6-only nodes but there are a few applications which haven't been
ported.

This have similar drawbacks to BIS except that IPsec should just work 
(assuming the host has normal IPv6 IPsec and IKE support).
This is possible since the "intercept" occurs at the API and not at
the IP packet level.

The ability to intercept inet_addr() and inet_ntoa() means that
unmodified applications can parse literal IPv6 address as well
as print literal IPv6 addresses in log files.

One implementation difference compared to BIS is that the address mapper
is per process, which makes the implementation simple (about 1500 lines
of code total.)

Could other OS implementations take advantage of something like this?
(Does the ability to intercept calls to standard library functions
exist in other OSs?)

Does it make sense to promote this or is the risk, that the ISVs and other
app developpers will use it as an excuse to not port, to great?

   Erik

---

From: Peter Tattam <[email-masked]>
Date: Tue, 22 Jun 1999 15:57:24 +1000 (EST)

That is exactly what I have done in Trumpet Winsock 4.1 beta, but for the
Winsock API.  I use the address range 240.0.0.0 to do the translation as the
existing ranges 10.0.0.0 or 192.168.0.0 may be in use by the client.

My code intercepts the dns code to deliver a mapped IPv4 address for Ipv6
domaind names. The rest of the socket API (connect, bind, getpeername,
getsockname, accept) are all modified to decipher whether the socket is a
mapped one and translate to & from IPv6 internal addresses as needs be.  See
the readme in our stack for more details.  There were quite a few gotchas so
I'd like to compare notes with yours.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Jun 1999 00:24:04 -0700 (PDT)

> existing ranges 10.0.0.0 or 192.168.0.0 may be in use by the client.

I agree and I was thinking about ClassE.
However, my current code uses 0.0.0.1 through 0.255.255.255, although that
is easily changed. (I think net zero is reserved by the IANA but I haven't
checked.)

> I'd like to compare notes with yours.

Seems like to main difference is that I trap inet_addr() and inet_ntoa()
for literal addresses.

Do you want to compare notes via email or in the bar in Oslo?

  Erik

---

From: Kazuaki Tsuchiya <[email-masked]>
Date: Tue, 22 Jun 1999 22:45:00 +0900

Dear Erik,

> I've implemented an idea similar to Bump-in-the-stack.

That sounds great!

> deploy IPv6-only nodes but there are a few applications which
> haven't been ported.
> 

That's exactly what I was trying to tell you. 

In the especially initial
stage, there will unfortunately
remain many applications which haven't been ported into IPv6. 

Then BIS
will be surely helpful. Because that allows IPv6
communication by IPv4 applications which haven't been ported
into IPv6.

That is, even if a complete set of IPv6 applications are not
provided, user can start to transit into IPv6. 

Thanks.

-- Kazuaki Tsuchiya, Hitachi, Ltd.

-------------------------------------------------------
Kazuaki Tsuchiya (mailto:[email-masked])
  Hitachi,Ltd. Enterprise Server Division
  Phone: +81-462-32-2121(ext.2458) Fax: +81-462-35-8324