On Mon, Jul 18, 2005 at 08:07:18AM -0400, Greg Troxel wrote:
> iWat <iwatth_at_gmail.com> writes:
> 
> > Hi, I'm a student from Kasetsart Universirt, Thailand. I and my
> > friends are going to work on Coda, hacking it to support IPv6. We do
> > not sure how long will it takes, and we are very new with Coda, but
> > we'll try our best...
> > 
> > There is one question I want to get its answer ...
> > - Is there any working project to make Coda runs on IPv6 ?
> 
> I believe that RPC2 now works with v6.

Yes it does, actually most of the simple daemons seem to work fine over
an IPv6 network. (clog/cpasswd/auth2, updateclnt/updatefetch/updatesrv)
I think that even volutil works.

However the Coda client and server do not. For one the higher level
protocol for volume location queries responds with a single ipv4 address
for the server location, but internally they track their peer based on
a single IPv4 address.

> I believe that Coda encodes IP addresses within the protocol.  It may
> be appropriate at some point to change the protocol to use an AF
> indicator followed by an address.  This raises issues of backwards
> compatibility.

Actually what would be better is to send the unresolved hostname of the
server (and a port number) and have the client perform name resolution.
That way we also avoid getting those useless 127.0.0.1 or private
(internal) network addresses for Coda servers.

Tracking clients should probably be done based on the VenusUUID, which
is sent when a client binds to a volume with the ViceNewConnectFS call.
Any connections that haven't called this should be considered
temporary (cmon/volutil) and can be recycled after a timeout, the ones
that are bound to a volume have a callback connection which is used to
check whether the client is still alive. This might also allow the
client to move between different IP addresses (wired->wireless, or
802.11->gprs) with minimal disruption of service. At the moment such a
change will trigger a full disconnection.

A client can probably get away with a locally unique identifier for
servers (pointer to the srvent structure?) Most places where we need a
connection we simply follow a set of pointers anyways (replicated volume
-> vsg -> mgrp -> srvent -> conn, or volume replica -> srvent -> conn) I
think there are only one or two places where we really need to look for
the server by ip-address, one is in the code that handles incoming
callback connections, but those should really be identified on something
like the VenusUUID.

> > I don't want the duplication of works, or if there is, so we can share
> > information to achive this project ...
> 
> Jan will speak up I'm sure.

Nothing committed yet. I had an email from Rod Van Meter the other day
who did the initial IPv6 code for RPC2 who wanted to know if there is
anything in this area that could possibly be an interesting project for
a couple of students. Haven't heard anything back, but even so some
duplication might be useful especially since there is nothing at the
moment and there might be a lot of interesting little snags that
different people solve in different ways.

Jan