Re: Temporary IPv6 addresses vs. netgroups

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

    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.

  | For example, I use DHCP to assign IP addresses on almost everything
  | now, including devices that are NFS/CIFS/SMB clients. The only place
  | where I have a static address is a server.

All of those would be stable in this sense, DHCP servers go to a lot of
trouble to ensure that they can give you the same address over and over
again.

But if you keep thinking of this in an IPv4 context, the need for anything
new will (most probably) never become apparent - the current API has been
around, and working mostly OK, with IPv4 for a long time.

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.

This is not feasible with IPv4, there aren't enough available addresses.
But with 2^64 IIDs on every subnet in IPv6, there are plenty of available
numbers to use...    Of course, the use of (almost universal) NAT makes
the problem moot for IPv4, end systems don't need to hide their identity,
the NAT translation does that for us (which is the one useful feature of
NAT - pity that it can't be turned off when it isn't wanted...)

  | 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).

  | How then should my browser then connect to the Internet?
  | What about ssh, etc?

Well, the browser is supposed to use temporary addreses, so if your DHCP
addresses were temporary, that would be good ...   And ssh is an example of
an application where (for the client anyway) we simply don't care, either
form works just as well (ssh servers don't authorise clients based upon
their address - that's why we don't use rsh any more).

But I suspect you're ignoring the "prefer" part of all of this.
If I have a temporary address, I prefer to use it for my web browsing.
If I don't have one, then a stable address will work just fine, it just
is not as good a choice for the purpose.

If I'm sending e-mail (to a remote MTA, I don't mean local submission)
then I would prefer to use a stable address, so the remote site's greylist
cache will recognise that as I wasn't a spammer 30 minutes ago, I am
probably not a spammer now, and so allow my e-mail through without delays.
If I don't have a stable address, but only a temporary one (and haven't
connected to that destination MTA with it previously), then I simply
have to wait for their greylisting timeout.   This is not ideal, and fails
if their greylist timeout is longer than the lifetime of my temporary
addresses (which is certainly a possibility.)   I really would prefer to
use a stable address...

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.)

  | I'll add that the above scenario is not hypothetical and is currently
  | solved by unplugging the LAN cable with the unfortunate side effect
  | of disrupting any local services that I was using.

Yes, I know that kind of situation, and that's a real issue, and one we
need to (also) be working on.   It is just a completely different problem
than the one we have been talking about.   Not less important, just different.
The kind of solution we are considering won't help for that problem at all.
Nor will a solution for your problem solve the other.  They are just different.

  | 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.

Do note that the difference between a temporary address and a stable one
(for this purpose) isn't its period of validity - the stable address may
easily have a lease time less than the lifetime of a temporary address, but
its planned usage pattern.  For a temporary address, we are planning to use
it for a while, then throw it away and never use it again.   For stable
address, we plan on using, and reusing, the address for as long as it
remains viable.

What's more, NetBSD already has a switch for assigning addresses using
either temporary or stable forms - it is net.inet6.ip6.use_tempaddr
The problem is that it is just one global switch, that applies to
everything, rather than one that can be set per application (or socket).

kre

ps: another address distinction that we might need to be able to make in
the future is between home addresses and care-of addresses.   Some apps
really need to use home addresses, others are just fine using care-of
addresses (and others even really prefer care-of addresses, like for doing
DNS queries, using a home address is just silly.)   So to add to the list
of things the API should support, this is another criterion that the
application might want to set - and combinations, like temporary home address
is best, if not then any care of address will do, and if not, any home address,
and if not that, anything so at least I can communicate, - that would
probably be my preference list for web browsing for example.