Re: [GNUnet-developers] Re: IPv6 for GNUnet

[Nathan Lutchansky]

On Tue, Oct 15, 2002 at 08:48:14PM -0500, Christian Grothoff wrote:
> On Tuesday 15 October 2002 08:20 pm, you wrote:
> > On Wed, Oct 02, 2002 at 07:28:06PM -0500, Christian Grothoff wrote:
> > > You said you were interested in trying to write an IPv6 transport service
> > > for GNUnet once the API gets stable.
> >
> > I'm quite certain that IPv6 should not be implemented as a separate
> > transport, but as an extension of the UDP/IP transport that is currently
> > IPv4 only.
> 
> It's a different transport because it has a different address (at least as 
> far 
> as the GNUnet core is concerned). And because clients that only support IPv4 
> will not be able to connect to an IPv6-only peer.

This is true.  There is certainly a distinct "IPv6 Internet", although it
mostly only exists as tunnels over IPv4.  As far as connectivity goes, IPv6
is separate, but as far as the sockets API, they are very similar and
closely linked.

> *But* this does not mean that you can not write a single module that uses
> a single IPv6 socket and that offers to the GNUnet core the 
> implementation of *two* transports (in one module/library, sharing the
> same unix socket).

Right.  This will be the path I take to follow the GNUnet transport API.

> > Would you have a problem with integrating the IPv6 support into IPv4?
> 
> How do you plan on of doing the 'integration'. I can see that code 
> duplication 
> is bad, but I also would like to be sure that if someone only has IPv4 that 
> there is not a single line of IPv6 code that is 'loaded'.

Yes, I am familiar with the issues involved creating IPv6 code that retains 
IPv4 compatibility on systems without IPv6 support in the socket library.  
I've always been very careful about that.

> And of course, the same for tcp. Am I anywhere near reality?

Too much abstraction.  :-)  I haven't looked at the code yet, but the 
IPv6-enabling process usually goes something like this:

  - Convert socket code and program data structures to use struct sockaddr 
    rather than struct sockaddr_in or even struct in_addr + port tuples.
  - Convert DNS calls to use getaddrinfo/getnameinfo, if available.  
    Probably won't be a big issue for GNUnet.
  - Change listen/accept code to explicitly handle all the various weird 
    IPv4, IPv6, and combined-stack approaches to binding.
  - Add IPv6-specific code to any functions that pretty-print the socket
    endpoint address.
  - Add IPv6-specific code to address-based access control system.

Note that there's really only three specific places IPv6-specific code gets 
added.  As a result, even though these patches are pretty large, only 
small parts of the code are wrapped in "#ifdef HAVE_IPV6".

So there should be only four places to touch the existing IP transport:

  - Change all endpoint handling to use struct sockaddr.  (The big item, 
    which does not depend on IPv6 support from the OS at all.)
  - Opening and binding the sockets.
  - Packets to be sent must be sent out the appropriate (IPv4 or IPv6) 
    socket, if we're on an OS that uses one socket for each protocol.
  - Converting struct sockaddrs to GNUnet transport identifiers.

Does this sound like a reasonable approach?  It's more like generalizing
the socket code than it is adding explicit IPv6 support.  -Nathan

-- 
Help reduce spam!  PGP-sign your email.

pgpX1QzZTdaMX.pgp
Description: PGP signature