I think that the notion of 'coda server' and whether a machine has
stable interfaces should be decoupled as much as possible.  That said,
I realize that the notion of IP address of a server is pretty well
entrenched.  If a server is supposed to be at a single IP address,
then IMHO it should bind to that single address.  Yes, if other
interfaces appear later, packets addressed to that address on the
server will not go anywhere, but given that this sort of multihoming
seems problematic, that's a feature.  Years ago (1998?) I used to run
a server on a machine with more than one address, but I gave up on
this very quickly and moved it to a 1-address box.

I'm not arguing that one should be able to deal with situations
without routed addresses, where you need to use different addresses
depending on where you are.  This is broken situation, and doesn't
meet the IP model.  But being on a different network than where the
server address belongs should work, e.g. (using net 10 to avoid real
addresses in the example, but obviously having real routed addresses
is the way to go).

client 10.2.0.2 ----  10.2.0.1 server 10.1.0.1

and client sends packets to 10.1.0.1, should be fine.  I haven't tried
this lately, but IIRC the server used to answer from 10.2.0.1, which
doesn't work.  Binding to just 10.1.0.1 should solve this.

If you want a server on a roving laptop, I guess you need mobile IP...

<uninformed-comment-without-reading-the-source>
While we are at it, the data structure for IP address in packets
should be changed to be a variable-length sockaddr or something, so
coda can work over IPv6.

Right now, you can run coda over IPsec to get some reasonable
security, or over NAT.  But you can't do both.  With v6, you don't
need NAT, so you can use IPsec.  This problem is currently preventing
someone I know from using coda.
</>

        Greg Troxel <gdt_at_ir.bbn.com>