[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Temporary IPv6 addresses vs. netgroups
Robert Elz wrote:
Date: Fri, 01 Feb 2013 00:44:47 +0100
From: Darren Reed <darrenr%netbsd.org@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
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
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
| 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
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
- 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.
Main Index |
Thread Index |