Re: Temporary IPv6 addresses vs. netgroups

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 28 Jan 2013 09:37:04 +0100
    From:        Ignatios Souvatzis <ignatios%cs.uni-bonn.de@localhost>
    Message-ID:  <20130128083704.GB27535%cs.uni-bonn.de@localhost>

  | Somebody claimed earlier that there are a lot of different address
  | classes, but I think this is mostly not relevant.

It really does depend upon the application, and the use of the application,
and the requirements of the local environment - but for most purposes, and
most uses, I agree with you - a relatively simple solution to the
underlying problem might provide enough of a solution that the relatively
few unhandled cases might be acceptably handled by being able to manually
configure the source address to use, and bind() (or whatever other app
level mechanism or library interface may be implemented to handle that.)

  | a) link-local, new-site-local vs. global addresses, outgoing connections,

  | Use your own address of the same class as the peer address, or more
  | general, use your address that matches most with the peer address.

That isn't always going to be sufficient - usually the peer address is
going to come from the DNS, and the DNS should have only global addresses,
not local (unroutable) ones (though v6 local addresses are much less of
a problem than v4 1924 addresses for this.)

The effect of that is that local addresses don't get used much, which would
mean that they don't bother being configured, and so are used even less.

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).   And probably a fairly
low hop limit.   If that works, then the destination is local, and some app
dependentent method (unless we invent a better general way) can discover
the destination's local address, and we can use that (and the total connection
setup delay is well under 1/10 of a second - for a connection expected to
run for many minutes, or hours, so this startup delay is harmless.)

If there's no reply within the time limit, we assume the dest is not local,
and simply try again using global addresses (whether it is just too far
away and the RTT is greater than we allow, or too many hops, or the dest
cannot get packets back to our local addr doesn't matter - any of those
indicate "not local enough".)

To make that work, the app needs to be able to request a source address that
doesn't match the type of the dest addr, so simply implementing a "match it
up" rule is not adequate.  We need more than that.

  | b) link-local, new-site-local vs. global addresses, incoming  connections:

Yes, easy, for replying to any incoming packets we should always use the
address that the peer sent to, as our source address - this one is not an
issue.

  | c) auto- or manually- assigned vs. temporary addresses, incoming
  | connections.

Most apps here don't care - and any local address that the peer chooses to
send to is acceptable - but for those that do, whatever solution is found
for handling outgoing connections should be adaptable for being a better
filter on incoming connections than either "any" or "this particular addr"
which are our only two options now.

  | d) outgoing connections: here we have a problem.

Agreed, this is the one we need to handle.

  | I think that you can often get away with using some match-length offset
  | to decide; (e.g. within own department, use assigned addresses);

There are two issues here, and it is important not to confuse them, or
we get a mess (even though they're obviously related and need to be considered
together).  One is how the application decides what (type of, or specific)
address it should be using.  The other is how it conveys that decision to
whatever it is that actually picking the specific source address.

If I have it right, the Mouse's suggestion was to make the latter of those
as close to "what we have now" as possible, by having the app always do all
the selection, right down to picking the specific addr (most probably using a
library routine) after which the "communicate" part is simply bind().

I don't think that's the right way, as picking a specific address means
(aside from getting all the available ones to select from, and being able
to know what types they are) we have to have made the outgoing interface
selection first, and that's not something that userland typically does
today, and that isn't a change I think we need to be making to the normal
operating procedures.  Picking the right specific address doesn't work (in
most cases) without knowing which outgoing interface is going to be used,
and while that information could all be exported to userland, and apps
could do what the kernel now does, I don't think that's the right solution.

If I'm right about that, then we need some kind of new sockopt (or similar)
to specify some kind of preference to the kernel.

  | Now, as for deciding what to use for outgoing connections: I think, if
  | source address selection is doing best-match, you'll only ever have 
  | ambiguities with assigned vs. temporary addresses.

If those were the only address types, then sure - and for now, in NetBSD
(if we ignore the local address issue) then that is it.  But for v6 there
are also CGAs, that some applications want (and those can have the 
characteristics of either being stable or temporary).  Even if the
first attempt at a solution for this problem doesn't concern itself with
any of those issues, it would be good to plan the interface in a way that
it can be extended fairly easily if that ever seems like the right thing
to do.

And we certainly need a way to have the kernel know about address types
(as long as it remains the kernel's responsibility to select the source
addr most of the time) so we also need an API in the address setting set
(ie: interface ioctls) that will allow that to be done as well.

Lastly ...

darrenr%NetBSD.org@localhost said:
  | In the original case of using mount, it isn't just one mount call or socket
  | that needs to use a specific IP address/interface but a whole host of them.
  | Thus what's required is a way to influence the networking environment of a
  | command all of its successors. 

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.

kre