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

From: Tim Hartrick <[email-masked]>
Date: Wed, 23 Jun 1999 17:23:44 -0700 (PDT)

Erik,

> 
> 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?)
>

Not sure really.  I am pretty sure that I have run across one or more
dynamic loading systems that could be tricked into doing this even if they
don't support it directly.
 
> 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?
> 

We implemented something like this in the past.  That is, an API level BIS
implementation.  Ours was very simple and didn't have any sort of automated
mapping capabilities.  The mappings had to be hand coded or you had to use
IPv4 compatible IPv6 addresses.

Your implementation sounds particularly appealing because the address
mapping doesn't require system level participation.  The mapping happens from
within each applications instance of the resolver library.  Slick and it
doesn't have any impact on applications that don't want the service.

My personal feeling is that folks that are going to deploy IPv6 within the
next couple of years or going to need a full tool chest of ways to handle
coexistence of IPv4 and IPv6.  I have always thought that this type of API
level translation mechanism is just another quality tool to add to the tool
chest.  It goes hand in hand with things like SIIT and NAT-PT.  The translation
is just happening a three and a half layers up the stack.  Cool.

Tim Hartrick
Mentat Inc.