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

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 20 October 2002 03:03 pm, you wrote:
> > 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.  :-)

Thanks :-)

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

Well, because there is no http code yet; we might have to distinguish in the 
http case, too. After all, how would you tell an IPv4-only peer that it can 
not connect to this IPv6-only peer (and even if the 6-peer runs dual stack, 
it may not be addressable from IPv4).

> 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.

Right.

> 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. 

Faster, maybe; but I would not want to rely on dyn. DNS addressing for 
security reasons (a peer may control a dyn DNS server and trick you into 
sending lots of traffic to dyn DNS peers by playing ping-pong with its own IP 
and then switching the dyn DNS server to the attacked host). But I guess 
security considerations are not your point here -- the question is, what if.

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

Well, as I said, we may want to write a tcp-udp addressing abstraction layer 
to facilitate code-sharing between the 4 &6 (and if feasible dyn dns) 
versions; but that is more code-factoring; we could still use a naming & 
numbering scheme that captures both dimensions of the protocol (addressing 
and encapsulation).

> 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.

I think we're not that far apart in terms of what we want to do here. I think 
if we write another little layer underneith the tcp/udp/http transports that 
abstracts the "address family" and make the address familiy to use a 
parameter to the transport encapsulation code, that would work well. This 
should be pretty much what you propose, right? My major difference would be, 
that I would hide that additional address family parameter from the core by 
defining it implicitly using the transport protocol number / transport name 
to distinguish the two.

> 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.

I'm not to worried about breaking compatibility, you are right, we are in a 
big flux anyway. But why would we need an additional field here? Is the 
transport type field (with 65335 possibilities!) not big enough? The core 
does not and should not really care about what that value means, it just 
selects which piece of code to run, and it could just select both, 
encapsulation and addressing. Now that we should avoid duplicating any of the 
two pieces of code by clever code factoring is certainly true, but I believe 
it can be done without exposing the "senderAddressType" (protocol familiy) to 
the core at all.

> 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.

Well, if you run dual-stack, can you tell if you are (worldwide) IPv4 
addressable? If not, we should not advertise the IPv4 address. Ditto for the 
IPv6. The plan is, that the user can even say "disable IPv4 UDP" and "disable 
inbound IPv4 TCP" (say because the machine is behind a NAT box). 

>  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

This plays on the binary compatibility issue and you essentially say that it 
is not a problem. But what if a user activates the IPv6 stack while not 
really having a global IPv6 address? Say IPv6 in the private network. We 
would not want to send advertisements out to the world for these addresses, 
and thus would want to enable the user to selectively disable this feature.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9sxEv9tNtMeXQLkIRAg8ZAJ4xKPijUlDNoKkL7lMHQF7smjcakgCbB/YX
stv/lyzoiK1rzvdoXsP/1J4=
=IiZy
-----END PGP SIGNATURE-----