Re: Temporary IPv6 addresses vs. netgroups

[Darren Reed <darrenr%netbsd.org@localhost>]

Robert Elz wrote:
>    ...
> That's a different issue I think - it may very well be useful to be able
> to define some kind of hierarchy of related sockets, and have default
> options that can be changed for everything below some point in this
> hierarchy.   For that to be useful for source address selection, first
> we need a way to handle that for the simple, just this socket, case.
> Then, if we have such a mechanism for one socket, it, and all the other
> socket options that can be set, could perhaps be set for a whole group
> of (current and future) sockets, using whatever grouping mechanism is
> designed later.

I wonder if focusing on addresses is the correct thing to do.

Should we in fact be focusing on network interfaces instead?

For example, if I'm connected to a LAN then I probably want
to use that network interface in preference to anything else.

And I wonder if a way to achieving that is in the first instance
to use a metric other than 0?

The idea being that the WiFi card drivers would use a metric of
say 53, ethernet 7 and so on (the numbers are just random choice
and chosen to express nothing more than preference for the lower
number.)

Would that mess with kernel routing in a bad way?

Now this doesn't solve the problem for a specific application
and nor does it address the problem where the addresses that
you want to choose between are aliases.

For example...
The idea here is that an application wants to use the VPN Tunnel
to connect to an internal website and the address that is used
is not something that the application cares about rather the
address is a property of the network connection used to transport
that connection. Thus using the network address of the LAN or
WiFi link is not appropriate, regardless of what addresses are
configured on them.

In some cases it may be possible to determine what the outgoing
IP address should be - for example if the network interface only
has one address that matches the address family being used to
make the connection then the choice is an obvious result of the
routing lookup for the destination. That however assumes that
there is a route to the destination network available that
specifies the interface in question.

Actually, going back to the original question at hand (with
mount), perhaps the solution is this simple:

# route add -host nfs.server.ip.addr -ifa my.ip.add.ress ga.te.wa.y

In situations where my.ip.add.ress is the only IP address
on a network interface or the address is assigned with DHCP
then it should be possible to do:

# route add -host nfs.server.ip.addr -ifp bge1 ga.te.wa.y


> One way to avoid that, is for applications where using local addresses makes
> sense (particularly those with long life connections - local addresses guard
> against address renumbering, which doesn't really matter if the connection is
> finished in under a minute) is to initiate the connection from a local address,
> with a very short timer on the SYN reply (20-30 ms).  

How do you define "local address" in this context?
Is it just something from a RFC1918 address space or...?

The point here being that some organisations have large
internal networks where a local address is usable on a
network with a bredth of 10 or more hops.

Darren