IPV6, Fedora and apps

[Douglas Phillipson]

Do network applications written for Fedora, or any Linux distro for that 
matter, require any modification to work with IPv6?  or is that a 
"TRANSPARENT" change in the protocol stack under the application layer? 
  Is there a different API for IPv6 for network apps, socket servers, etc?

Thanks

Doug P

[John DeDourek]

Douglas Phillipson wrote:

>  Do network applications written for Fedora, or any Linux distro for
> that 
>  matter, require any modification to work with IPv6?  or is that a 
>  "TRANSPARENT" change in the protocol stack under the application layer? 
>   Is there a different API for IPv6 for network apps, socket servers, etc?
>  
>  Thanks
>  
>  Doug P
>   
I have programmed some simple IPv4 applications in C.  I have not programmed
any IPv6 applications.  But I do work with network protocols.  With that
disclaimer:

There are a significant number of details that need to be accommodated to
handle IPv6.  Just consider, for example, the size of the address is now
16 bytes instead of 4 bytes.  A typical application will read a host name
from somewhere (e.g. a browser extracts this from a URL) and then needs
to do a "get host address by name" call to a library function to get
the IP address before it can use the network access functions.  Now a
C program needs to have allocated sufficient space within it to hold
the 16 byte address.  It is likely that most C programs will at least
in some cases not have been careful enough to automatically increase
the allocation when recompiled for IPv6 access.  Also, IIRC, some of the
function names have changed to prevent bugs due to putting an IPv6
address in an allocation only 4 bytes long.

Conclusion:  an application written in C will need to be carefully examined
and likely modified to support IPv6.  I can't speak for applications implemented
in other languages.

[Jay Cliburn]

On Wed, May 31, 2006 at 07:55:36AM -0700, Douglas Phillipson wrote:
>  Do network applications written for Fedora, or any Linux distro for
> that 
>  matter, require any modification to work with IPv6? 
If the app is written for IPv4 only, it must be modified in order to communicate via IPv6.
 Some apps have been coded for dual-stack IPv4/IPv6, so they'll run either protocol
version.  Ssh comes immediately to mind.

>   Is there a different API for IPv6 for network apps, socket servers,
> etc? 
The API is the same (TCP/IP), but the semantics differ between IPv4 and IPv6 network
programming.

Jay

[Michael H. Warfield]

On Wed, 2006-05-31 at 07:55 -0700, Douglas Phillipson wrote:
>  Do network applications written for Fedora, or any Linux distro for
> that 
>  matter, require any modification to work with IPv6?  or is that a 
>  "TRANSPARENT" change in the protocol stack under the application layer? 
>    Is there a different API for IPv6 for network apps, socket servers, etc? 
	That's a great big "it depends".  Most should not.  But coders (even
ones who should know better) do have a way of dicking it up, all the
time...

	There is the older API which was, essentially, IPv4-Only, and the newer
(but still around for ages) AF Independent API which supports both IPv6
and IPv4 (and others) through address family transparency (the address
family and size are part of the structures that are passed back and
forth as opposed to a simple unsigned 32 bit address).  So, if they use
the network APIs, it depends on which API they coded to.

	If one is coding a new application, here is some general "how to" stuff
for AF Independent coding:

	http://www.kame.net/newsletter/19980604/

	If you DON'T code it AF Independent, then you will eventually have to
fix your bugs when your app doesn't work any longer.

	LOTS of modern applications need no changes at all.

	Many many servers that fork out of xinetd are this way.  All you do is
add "flags = IPv6" to the config file and away you go.  I'm the author
of a whitepaper up at VMWare on doing this for VMWare GSX Server (now
just server).  GSX server and the VMware client were some of the tougher
nuts to adapt and they were fairly trivial (took longer to write the
paper than solve the problem).  Just requires one kludge using xinetd
binds and redirects on the client side and the addition of the said
flags on the server side.

	Servers and clients that handle their own networking and directly
manipulate addresses (say for access control lists) MIGHT need updating
(but most already are) to use the more modern AF Independent API's
rather than the old IPv4-only API's.  I find that there are relatively
few apps on Fedora (or other Linux distros) that are not already IPv6
aware and ready.  Some, such as Squid and Samba, which are deeply
involved in network protocols may be more difficult (AFAIK, Squid has
IPv6 patches available and in CVS while Samba does not).  Most clients,
it's a pretty trivial change.

	Most of the big, open source, servers (Apache 2.x, Sendmail, Bind,
Postgres, Dovecot, TCPWrappers) are all well covered.  Some (Squid,
Samba, mysql) still need work.  Mysql is promising it RSN.  Squid has
patches.  Samba, we're kinda waiting to see what Windows has for SMB on
IPv6, but it shouldn't be a real problem and some patches DO exist for
an older version of Samba.

	Many/most of the clients (Mozilla, Firefox, Thunderbird, Evolution,
ftp, fetchmail, the list goes on an on) are already adapted.  Some, may
still need work.  Most newer applications SHOULD be written with the
newer API and then they will just work out of the box.  There SHOULD be
no excuse for a modern application to be coded IPv4 only.

	There is definitely a problem with proprietary vendors, however.  They
are typically ignoring IPv6 (which is crazy - there is no such thing as
an IPv4-only network any more, AFAICT, and I have LOOKED) and not coding
to the state of the art (still coding to the older API's and acting as
if IPv6 didn't exist) and their code can't be readily fixed by us
commoners.  A good example is the VMware Client.  They know what they
have to do to fix it (cause I've told them).  I can't fix it, because
it's closed source.  All they have to do is correctly call
"gethostbyname()" for the server's host name and use one of the
structures returned in the call to "connect()".  But they're still
coding back in the stone age where all addresses were a 32 bit unsigned
int.  Oracle just recently added IPv6 support (I think to Oracle 10, but
I haven't tested it to verify this, so I could be wrong).

	If you're worried about some arbitrary proprietary package that was
coded for Linux and is closed source and the vendor has not specified
that they are IPv6 compatible, then the answer to your question is
probably going to be that they need to modify their product or you will
have to "shim it" using some of the tools I used with VMware.  There are
some "bump in the wire" tricks which you can play but we don't have a
"bump in the API" where IPv4-Only applications will transparently see
IPv6 peers as IPv4 (we have it the other way around were IPv6 clients on
and IPv6 network can still see IPv4 networks but not vice versa for IPv6
only servers).

	So, the answer is, properly coded applications should require no
changes (depending on the extent to which they want to tinker with
addresses).  Older applications using older APIs or ones which have not
been upgraded to address independent functions, may require work.  But
this is no different on Linux than Unix than Mac than Windows and it's
been know about for years.

	You can find a lot more information about apps which are IPv6 ready and
some that aren't up at the DeepSpace6 web site (which is on both IPv4
and IPv6) here:

	http://www.deepspace6.net/docs/ipv6_status_page_apps.html

	There are very few "red faces" any more.

	Even still, that list isn't complete and is somewhat out of date.  It
still shows Miredo (Teredo IPv6 over UDP for Linux) as version 0.1.0 and
it's now at 0.8.5 (0.9.1 for development).  So the situation is even
better than whats shown there.

>  Thanks 
>  Doug P 
	Regards,
	Mike
-- 
Michael H. Warfield (AI4NB) | [phone] |  mhw(a)WittsEnd.com
   /\/\|=mhw=|\/\/          | [phone] |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!