Re: Temporary IPv6 addresses vs. netgroups

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

Robert Elz wrote:
> Date: Fri, 01 Feb 2013 00:44:47 +0100
> From: Darren Reed <darrenr%netbsd.org@localhost>
> Message-ID: 
> <1359675887.4682.140661185289761.2831F179%webmail.messagingengine.com@localhost>
>
> | How do you determine a stable address vs temporary?
>
> If you mean by that, how do I look at an address and determine if it
> is a temporary address or not, the answer is, I can't - which is exactly
> what (part of) the problem is.
>
> Only when the address is created (or assigned) do we know its planned
> use model - whoever (or whatever) creates the address needs to indicate
> whether it is a temporary, or a stable address.
> ...
> It is with IPv6 that we really need an addition (and then, as has happened
> with other stuff originally designed for v6, if that turns out to be
> beneficial to IPv4 as well, that's fine).
>
> For IPv6, a temporary address is one assigned following the procedures
> of RFC4941 - for this purpose the term "temporary address" is a very
> specific thing, and doesn't just mean some random address that I might
> not have forever.
>
> The general assumption is that you will normally only use a temporary 
> address
> for a very limited time - a day would be an upper limit, an hour is not
> at all unreasonable. Then you make a new one and use that instead.
> ...
> | If temporary is DHCP then both of my links are temporary.
>
> It isn't, those are stable address, what you described was just address
> renumbering (or perhaps, mobile IP, in some cases would be quite similar).
>
> ...
>
> For the NFS application that started this, I have to have an address that
> the NFS server will permit, so the only issue is making sure I use 
> that one
> and not some other one (like some temporary address, as the problem that
> inspired this discussion was caused by.)

Not selecting the temporary address seems like a rather trivial
thing and not something that will completely fix the problem
being described.

> | The argument that I'm making here is that I don't see
> | temporary vs stable as being a useful abstraction in the
> | classification of addresses for applications to use as there
> | is no reasonable way to classify an address as such.
>
> Of course there is - to use (4941) temporary addresses we need a process
> running to create, monitor, and release them as appropriate (that can be
> a daemon, a script run from cron, or ...) When it creates a temporary
> address it simply says "this is a temporary address" and from that 
> point on
> everyone knows that. When DHCP (or IPv6 autoconf, or manual ifconfig)
> assign an address, they don't say that, and their address is a stable one.

RFC 4941 looks to me like someone realised that the EID in
IPv6 addresses had privacy implications (because it will
turn up everywhere) and so something was concocted to "fix"
that problem that they had created. Hence why you mention
that web browsers will always want to use temporary addresses
and almost nothing else will. Anyway, I don't want to talk
about the merits of the EID...

... it isn't just web browsers that will leak that piece
of private information to the Internet, it is anything that
connects out through the Internet, be it the web browser,
ftp client or ssh.

This indicates to me that the policy for when a temporary
address should be used is not something that we can depend
on an application to provide. For example, if you're using
a web browser on a coroporate LAN then you most likely don't
want to use a temporary address but if that same web browser
were to browse the Internet, you do want to use a temporary
address (assuming a direct connection is possible.) As I
mentioned above, it isn't just the web browser that needs to
be subject to this policy but rather everything that connects
to a host on the Internet.

Some example policies for when temporary addresses are to be
used might be as follows:

- always use a temporary address;
- never use a temporary address;
- always use a temporary address for anything I reach via the
 default route;
- never use a temporary address for hosts that are on networks
 that I am directly connected to;
- never use a temporary address for connections to the NFS
 server at 1::2.

The bottom three policies are all attributes of the
relationship between the two hosts and could arguably be
represented by a an attribute attached to a specific route
entry for that destination.

Darren