Re: Temporary IPv6 addresses vs. netgroups

[Ignatios Souvatzis <ignatios%cs.uni-bonn.de@localhost>]

Hi,

On Sat, Jan 26, 2013 at 09:40:43PM +1100, Darren Reed wrote:

> The problem at hand is that the multitude of addresses available
> on a host now means that applications need to either make educated
> guesses (for example, putting 169.254 at the bottom of the list to
> choose) or allow users to manually configure which address they
> want to use with a particular application. For large applications,
> this isn't unreasonable but for utilities such as mount, well we
> need a better way for them to work.

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

First, some thoughts about decision lines for different cases.

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

this should normally sorted out via automatic source-address selection;

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.

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

easy - you only ever will get connections to addresses that can reply. If
not, yell at^W^Wtell your network administrator (or maybe the peer one's).

c) auto- or manually- assigned vs. temporary addresses, incoming
connections.  Obviously, you can normally not advertize services
at temporary addresses, so your services should bind to well-known
ones, whatever method is used. Only excuse would be when you use
some (probably link-local) advertizing system, like with NMB on 
Appletalk, or with SLP / Zeroconf on IP.

d) outgoing connections: here we have a problem. Some connections want to
use temporary addresses for privacy reasons; some connectiosn want to use
well-known addresses for sort-of-authentication reasons. I think that you
can often get away with using some match-length offset to decide; (e.g. 
within own department, use assigned addresses); else you'd have to decide
by application type, or by explicit configuration.

Yes, i've needed one or other type of configuration in real life.

d) is what triggered this discussion. I've seen mishandling of c) and d)
on some OSes.

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. In this case, a flag
"avoid temporary addresses for this connection" should be enough (if
the kernel knows about temporaries).

Regards,
        -is