On Tue, Jun 03, 2003 at 09:47:20AM -0400, Greg Troxel wrote:
>   The only solution right now is to bind the server explicitly to a single
>   ip-address on your multi-homed machine. There should be a server_ip
>   options in server.conf for that.
> 
> This would be a good thing to add.

Nice, because it has been there for a while now ;)

#
# When a server is confused about it's identity the server will complain.
# (i.e. gethostbyname(hostname()) == 127.x.x.x). Use this option to force
# the ip-address through which clients will be able to reach this machine.
#
# The actual cause seems to be a very common setup when the machine has no
# default interfaces configured and /etc/hosts contains a line similar to
# 127.0.0.1 (or .2)     myhostname.mydomain
#
# Removing that line from /etc/hosts also solves the problem.
#
#ipaddress=

>   In the long term, we might be able to decouple the existing 1:1
>   relationship between a server and it's ip-address. This way a client
>   should be less surprised about receiving the response from 10.0.0.9 as
>   long as gethostbyaddr returned that as one of the usable addresses for
>   our peer.
> 
> This seems like not a good idea, since it relies on dns to bind
> together multiple addresses into an entity.  We should either use (and
> _authenticate_) some higher-level address or name, or just say a
> server has a single address.
> 
> Thinking ahead, one of Coda's current glaring deficiencies is that
> lack of IPv6 support.  One should be able to talk to a server over v4
> or v6, changing as one's connectivity changes.  For this, we need some

On one hand you are saying that a server probably should have a single
address, but when we introduce IPv6 the server will have at least 2
already (v4 & v6), and as far as I can tell IPv6 also has these various
link-local/site-local/etc. addresses.

So basically we need to be able to pass a set of alternative addresses
to reach a server down into RPC2, which is exactly what most of the
stuff in the the IPv6 patch for RPC2 is doing.

And we need to rely on something somewhere. I'm not going to maintain
the authorative list of all Codaservers and their alternate addresses.
getaddrinfo() should do fine.

> probably makes sense to have the server always reply over the same
> address that the rpc was sent to.  This is the practice with NTP, and
> probably a good idea.

This already works fine if the multiple interfaces are hooked into
different networks. We only have a problem when a host has all
interfaces hooked up to the same network. This is typically a (failed)
attempt at load balancing or channel bonding without actually doing so.

In fact the Linux kernel tries to be helpful and sends arp responses out
of any interface that happens to ask for a local address. So if you send
an arp request to that machine for 10.0.0.2, it will send out 2 arp
responses with both hardware addresses. This is easy to observe from any
NetBSD or FreeBSD machine on the network who will log messages to the
console about the 'arp collisions'.

>   To get this kind of multi-homing setup working entirely correctly
>   requires opening a separate socket for each interface and doing some
>   of the routing in RPC2. It also becomes increasingly more difficult when
>   you consider network topology changes, interfaces disappearing and
>   re-appearing or simply route changes which typically happen when mobile
>   clients are moving around.
> 
> This is less worrisome on clients.  For callbacks/probes to
> invalidate/check leases, the server has to know it is the same client.
> But the penalty for becoming a different client is probably just
> breaking all the leases.

But if both interfaces talk to the same network, should the Coda server
be responsible for load balancing between the two interfaces? If the
kernel routing can't decide the right interface to use, how could we.

I think that binding to specific interfaces introduces too much
complexity and doesn't really help except the few cases where the
network routing is IMHO broken.

> server_ipv4 192.168.0.1
> server_ipv6 3ffe:39:0:1::1

IPv6 support is pretty much ready and jumping in it's own branch in
RPC2. My laptop has a post-6.0 Coda tree where auth2, clog, cunlog, au,
rpc2portmap, updateclnt, and updatesrv are working nicely and
successfully bind to both IPv4 and IPv6. Venus and codasrv will take
some more work, because they currently track their peers based on the
IPv4-address.

Jan