gnunet-developers
[Top][All Lists]
Advanced

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

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


From: Nathan Lutchansky
Subject: Re: [GNUnet-developers] Re: IPv6 for GNUnet
Date: Sun, 20 Oct 2002 16:03:18 -0400
User-agent: Mutt/1.4i

(Adding the list back to the CC line...)

On Tue, Oct 15, 2002 at 11:07:52PM -0500, Christian Grothoff wrote:
> On Tuesday 15 October 2002 09:43 pm, you wrote:
> >   - Convert socket code and program data structures to use struct sockaddr
> >     rather than struct sockaddr_in or even struct in_addr + port tuples.
> 
> Well, be careful here; if we're talking about the wire-format, you can't just 
> change it on the nodes that support IPv6 and expect that the IPv4 nodes will 
> be happy with that. The IPv4 nodes will expect that an address is 4 bytes... 

OK, I've just taken a look into the code.  The transport-specific code is 
pretty small, which appears to be the product of good design.  :-)

> The problem I'm trying to explain here is that from a practical point of
> view, I would like the user to be able to specify 'load udp6 tcp6' or
> 'load udp4' or 'load udp4 tcp6 smtp http' and this should just work with
> the same binaries as long as the platform supports the transport 
> protocol.

I have to disagree with you here.  Why do you make the distinction between 
UDP running on IPv4 vs. UDP running on IPv6?  Similarly, why *don't* you 
make the distinction between HTTP running on IPv4 vs. HTTP running on 
IPv6?

There are two separate variables you're trying to group into a single set
of configuration flags.  We need to be able to specify a) the protocol
directly used to carry the GNUnet messages and b) the format used to
identify the network endpoints.  The protocol is described with the names
already used in the code: TCP, UDP, SMTP, HTTP, etc.  What you're
proposing is to extend the names to also describe the endpoint identifier
format as well.  UDP using IPv6 addresses would be udp4, TCP using IPv4
addresses would be tcp6, etc.

What if in the future it becomes useful to identify your node using a 
domain name instead?  It would be faster for me to reconnect to nodes 
with dynamic IP addresses if they had dynamic DNS to easily locate them 
via their static domain name.  To implement this, would we need yet 
another set of transports, called udpdns and tcpdns, with virtually the 
same code as udp4, udp6, tcp4, and tcp6?

I propose that the protocols be extended to allow use of multiple types of
endpoint identifiers for the UDP and TCP transports.  This would be an
architecturally-sound means of adding IPv6 functionality, as well as other
methods of identifying hosts such as with DNS names or even with Apple's
Rendezvous protocol.

The obvious way of doing this is changing UDP HELO messages to add a
"senderAddressType" field.  Although it would break existing 
implementations, GNUnet is right now at a point of flux where the next 
version will be protocol-incompatible anyway.

On another note, one of the goals of the Grand IPv6 Upgrade is to shield
the user from the protocol as much as possible.  If the user has IPv6
connectivity, why should he/she care about whether GNUnet is using IPv4 or
IPv6?  Similarly, if the user has no IPv6 connectivity, there's no reason
to require him/her to disable it manually.  Forcing the user to manually
select which IP version to use is quite uncommon in most applications, for
the simple reason that it is unnecessary.  Attempting to create an IPv6
socket is a simple test of whether IPv6 is available in the operating
system, and attempting to connect to a remote IPv6 host is a simple test
of whether IPv6 connectivity is available.  In fact, RedHat suddenly
enabled IPv6 support in most of their software in version 7.2, and nobody
noticed the change.  There's no reason binary releases of GNUnet can't
ship with IPv6 support included and enabled by default.  -Nathan

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

Attachment: pgppnsIK53vzI.pgp
Description: PGP signature


reply via email to

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