On 04/29/2013 12:39 PM, Ray Hunter wrote:
Christian Huitema wrote:
The "problem" here is that don't have all the names/IDs we'd like. For example,
using the MAC address as the Interface_ID would do for this
purpose... but the the IPv6 address is tied to the MAC address, and would
change upon replacement of the NIC (which is generally undesirable)...
Undesirable by whom? For a laptop, for example, the most likely cause of a MAC
address change is that the user/owner used an administrative command to change
it, probably in an attempt at getting privacy. Keeping the same IID would
defeat the purpose.
On the other hand, if I am managing a big server, I would like to retain the
same IPv6 addresses to avoid disrupting service. But then, if I want a fixed
address, I would probably ensure that by configuring a fixed address, not by
relying on a side effect of automatic address configuration.
-- Christian Huitema
Right. But a bad side effect of manually configuring fixed addresses is
that you derail all of the good work around renumbering.
It might prove operationally useful to be able to configure a static
IID, but still continue to use of a variable network prefix (derived
from RA).
I only peripherally followed the early discussion about this topic (only
so many hours in the day). I confess that I never "got" the need for
this, but lots of people seemed enthusiastic about it, so I put it in
the category of things to figure out later. :)
Now that there is non-trivial pushback on the draft becoming an RFC I
have taken another look, and I still don't get it. Let's assume that
there are 2 broad categories that cover a statistically significant
percentage of the possible use cases, home and business. I don't see any
scenario where the home user would be benefited from stable privacy
addresses beyond what 4941 already provides.
For business users, I do see a case where they would want to make sure
that the same system always used the same address for accessing internal
resources (auditing, accountability, etc.). The traditional answer to
that has been to turn 4941 off, but that loses the benefits of 4941 when
accessing outside resources. (OTOH, if the outside resources are web
sites they already have much more sophisticated ways to track you
besides IP address, but let's assume that 4941 is still valuable for
sake of argument).
Assuming my use case analysis is correct (and I would not be surprised
if it were not), it seems to me that we could accomplish both goals for
the business case by adding a DHCPv6 option that says, "for any traffic
on networks with these prefixes, use your 'real' address if you have
4941 enabled."
Does that sound like a reasonable option?
Doug
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
