[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] Re: IPv6 for GNUnet

From: Christian Grothoff
Subject: [GNUnet-developers] Re: IPv6 for GNUnet
Date: Tue, 15 Oct 2002 20:48:14 -0500
User-agent: KMail/1.4.1

Hash: SHA1

On Tuesday 15 October 2002 08:20 pm, you wrote:
> Hey Christian!  Sorry for the slow reply; I've been on travel a lot lately
> and also I've been ill.

Sorry to hear the latter. I'm cc-ing this to gnunet-developers, assuming you 
don't mind.

> 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.
> Yes, and I hashed out some thoughts, although I never got to the point of
> looking at the code.

Well, it's all in CVS, nothing should stop you :-)

> 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.
> Conceptually, this makes sense, as IPv6 is merely an upgrade of the
> Internet Protocol, rather than a separate protocol.  Functionally, it makes
> sense because the IPv4 and IPv6 stacks are one and the same on many POSIX
> systems.  For example, on Linux, the binding semantics of UDP and TCP
> prohibit a server from binding to the same port with an IPv4 socket and an
> IPv6 socket.  Instead, servers listen *only* to the IPv6 socket, and both
> IPv4 and IPv6 inbound connections are received on the IPv6 socket.

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. *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). This should get you around the 
limitiation of binding to the same port with IPv4 and IPv6. 

> Would you have a problem with integrating the IPv6 support into IPv4?  From
> past experience, I don't think the code itself would be that intrusive,
> although I might have to abstract out the socket operations a bit,
> depending on the organization or your code.

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'. So a refactoring of 
the current {udp|tcp}/ipv4 code to call on a 'socket API' that will then 
translate the calls to ipv4 or ipv4&6 or ipv6 (depending on which 'module' 
was compiled) would probably be just fine with me. After all, it was Prof. 
Comer who said that every important problem in CS can be solved by adding a 
level of indirection... 

So if I try to interpret what you said, the result would look something like 

udp_generic_library.c => calls 'abstract' socket API
udp_ipv4.c => uses udp_generic_library with ipv4 socket API impl
udp_ipv6.c => uses udp_generic_library with ipv6 socket API impl
udp_ipv46.c => uses provides shared-socket implementation for running IPv4&6
                              on the same socket; looks to GNUnet-core as 2
                              shared libraries / 2 transports [which then
                              share code/state/threads]

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

> > I've personally never used IPv6
> You will eventually.  :-)

Well, once I escape from the US, probably :-)

> > but it sure would be cool (and probably also a first in the sense
> > that there are not many p2p systems supporting IPv6 out there, not to
> > mention *both* :-).
> Actually, until I put IPv6 into INN, the most popular IPv6 protocol was
> IRC.  Seems DCC or CTCP (whatever they use for file transfers) is much
> handier with IPv6 addresses rather than dynamic IPv4 addresses.
> Thanks for the offer of help.  Hopefully I'll be able to get something
> working before Halloween, since I'll be on travel pretty much straight
> through January.  It shouldn't be too much work, I expect.  -Nathan

Well, I can't tell. But I'll look forward for patches :-)

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


reply via email to

[Prev in Thread] Current Thread [Next in Thread]