[ipv6hackers] Pros and Cons of Address Randomization

[Owen DeLong]

On Dec 12, 2012, at 7:33 PM, Fernando Gont <fgont at si6networks.com> wrote:

> Hi, Owen,
> 
> On 12/12/2012 11:19 PM, Owen DeLong wrote:
>>>>>> 1.	DDNS is probably more useful than having the same address.
>>>>> 
>>>>> Having the same address is useful for many other reasons: logging, etc.
>>>> 
>>>> If you log based on name and your DDNS is bi-directional, what gain is there
>>>> to having the same address? 
>>> 
>>> This changes v4 practice -- which is undesirable. And the tool might not
>>> yet support the DDNS bi-directionality you're referring to.
>> 
>> 128 bits in the address field changes IPv4 practice. This is desirable.
> 
> What's desirable is the larger addresses, not the "changes".
> 

We can agree to disagree. I think not having NAT is a good thing. I think not
having to count hosts to size subnets is a good thing. All of these are changes
from IPv4 practice.

I think having a separate network association LSA in OSPF is a good thing.
This is, again, a change from IPv4 practice.

I think having IPSEC baked into the protocol extension headers instead of
playing stupid games with the payload is a good thing. That is a change
from IPv4 practice.

I think being able to have more than one default route off a subnet is a
good thing. That's a change from IPv4 practice.

I think having multiple addresses on an interface is a good thing. In many
cases, that's a change from IPv4 practice.

>> I don't know of any IPv6 DDNS tools that don't do forward and reverse, so I'm
>> not sure what you mean here.
> 
> You assume the tool would do the reverse mapping before logging, or what?
> 

Hard for the host to activate the address and do any noteworthy logging in
less time than it takes the DHCPv6 server to update the DNS with the
registration (which should get kicked off prior to or very close after
the DHCPOFFER is sent).

> 
> 
>>> However, this proposal might actually *reduce* the number of variants if
>>> nodes replace EUI-64 with this, and MS follows this standardized scheme
>>> (in replacement of the "random - but stable across networks - IIDs" they
>>> are using).
>> 
>> But I don't think they are likely to do so. More likely they will replace
>> RFC-4941. 
> 
> You mean *stable-privacy-addresses are likely to replace RFC4941?

Yes.

> 
> 
>> You might have some luck getting Micr0$0ft to replace their current
>> broken undocumented pointless tactic.
> 
> Still better than mac-derived IIDs…..

I disagree.

> 
> 
> 
>>>>>> 2.	If you care about the same address, just assign one by host ID
>>>>>> 	and move on.
>>>>> 
>>>>> And then again: how do you get a random address based on a host-id? --
>>>>> you still need an algorithm for that.
>>>> 
>>>> That's already specified in DHCPv6.
>>> 
>>> Can you provide a reference?
>> 
>> Admittedly, I just took other peoples word when they said DHCPv6 addresses were
>> supposed to be randomized unless configured otherwise. I haven't been able to
>> find a reference.
> 
> I seem to recall DHCPv6 doing sequential addresses by default, instead…

I think that was a long time ago. I'm pretty sure that ISC DHCPd at least hands
out randomized addresses from within the scope.

>> The closest I came was the DHCPv6 support for IA_TA and IA_NA.
> 
> Of the top of my head, there's no standardized support for randomized
> addresses.
> 

I'm not sure it needs to be standardized. More of a BCP thing if you ask me.
I don't care whether everyone uses a different randomizing algorithm.

However, I'm not actually a big fan of randomized addresses to begin with, so…


>>>> While I fully expect a day when 1TB of RAM may not be enough for most purposes,
>>>> I'm willing to bet IPv6 will run into some other scaling limit besides the
>>>> number of addresses long before we see a day when 1PB is not enough, let
>>>> alone 1XB. Given that 2^64 is more than 18XB…
>>> 
>>> Well, that's not really "setting the bar high": think about IPv6+IPv6
>>> routing tables, etc….
>> 
>> I'm not sure what you mean here. I still don't imagine that you will be able
>> to build hardware to support an IPv6+IPv6 routing table (whatever that is supposed
>> to mean).
> 
> Sorry, I meant IPv4+IPv6.

In which case, I argue that you will be unable to build hardware to hold a
routing table that represents the full IPv6 address space usefully deployed.

> 
> 
>> In reality, bits are virtual and don't really take meaningful amounts of energy
>> or space. I'm not sure time is particularly relevant in this case, either.
>> 
>> I expect IPv6 to reach end of life with at least 50% still sitting in the free pool.
>> 
>> I don't expect any IPv6 subnet to ever reach 2% host density.
>> 
>> That's OK. That's expected. That's a good thing.
> 
> Well, it's not a good thing if we're wasting bits "by design".

But we're not wasting bits. We're wasting addresses. The bits are quite useful.

> 
> 
> 
>>>>> 2) Randomizing the vv6 addresses over the /64 at least makes use of it.
>>>> 
>>>> Not really. The host density of random IPv6 addresses is no greater than the
>>>> host density of EUI-64 addresses.
>>> 
>>> What changes is the distribution -- that's the key point here.
>> 
>> Except that it doesn't change all that significantly unless you have very
>> homogeneous hardware purchasing habits. Given the strong progress towards
>> BYOD and away from HYOD that tends to be accelerating, I don't expect that
>> kind of homogeneity to persist even in organizations where it is currently
>> normal.
> 
> Well, that's "hope" or "guesswork" rather than "fact".

No more so than your conjecture in the opposite direction.

> 
> 
> 
>>>> 	B: Not significantly less susceptible than EUI-64
>>> 
>>> MAC-derived IIDS, stable-priacy IIDS, and RFC4941 all contain modified
>>> EUI-64 format identifiers….
>> 
>> Any 64 bit pattern can be argued to contain modified EUI-64 format
>> identifiers, so I'm not sure how this statement is expected to be
>> in any way contrary to what I said in B above.
> 
> Generation of EUI-64 from Ethernet is specified. (0xfffe word, etc.)

Yes, but you specifically mentioned RFC4941 and stable privacy IIDs as
also containing modified EUI-64, so… If you're going to modify the
EUI-64 that much and still call it modified EUI-64, then, there's
no 64-bit pattern that can't be a modified EUI-64.

Also, your statement only holds true from Ethernet and probably only
up through 100GE. 400GE and TE, I suspect, will have native EUI-64
addresses which will _NOT_ have fffe in the middle.

> 
> 
> 
>>>> 2.	Brute force address scanning attacks are not likely a
>>>> 	common or effective attack vector in IPv6, even with
>>>> 	EUI-64.
>>> 
>>> Are you deeming them as unfeasible, or… something else?
>> 
>> I'm saying that except on networks using common static sequential assignment,
>> brute force scanning over the WAN is certainly infeasible and over the LAN is
>> infeasible unless your scan operates at such a rate that it is likely to
>> represent a significant fraction of LAN traffic and/or a DOS attack.
> 
> We simply disagree. My analysis is in draft-ietf-opsec-ipv6-host-scanning

We don't actually. Your analysis says nothing about brute force scanning
being feasible. It specifically talks about hinted and/or targeted scanning
based on additional data.

>> Note, I am speaking specifically of brute-force scanning, not hinted
>> scanning, multicast ND based scanning, etc.
> 
> Ok. But in v6 you wouldn't do a pure brute-force address-scanning attacks.

Agreed, but, your alleged advantages in your proposal primarily apply to
brute-force. Once I've got hints, I have the same hints about your stable
randomized address in most cases that I have about an EUI-64 address.

>>>> 3.	Hinted address scanning offers a similar attack surface
>>>> 	with any persistent address,
>>> 
>>> The surface is the same, the difficulty in successfully leveraging it is
>>> *not*
>> 
>> I disagree.
>> 
>> If I can get on the LAN, I can do a 24 bit scan through multicast space and
>> find all of your stable privacy addresses.
> 
> Agreed.
> 
> 
> 
>> If I need to scan for EUI-64-based addresses, the challenge is no less than
>> a 24 bit space to scan, even if I assume every target host has the same OUI.
> 
> And 24 bits is feasible.
> 

Agreed, but, my point is that there's no advantage in this case to your randomized
addresses. The problem space/attack surface/density/distribution is identical.

>> If I can't get on the LAN, then, I either need to know the OUIs for all
>> of the devices I care about and do a 24-bit scan for each of them, or,
>> I need to scan the entire 64 bit space.
>> 
>> Admittedly, I don't get the OUI ability to reduce the first 24 bits, but
>> I would argue that in terms of real-world meaning for attack time from
>> a remote location, the difference between scanning a 40 bit address space
>> and a 64 bit address space isn't all that meaningful.
> 
> Even if you didn't know the OUI, you don't need to brute force all those
> bits -- just try the "current" ones from the relevant IEEE registry.

Have you looked in the IEEE registry lately? The vast majority of patterns are
allocated and they're going pretty quickly. That's one of the reasons that
IEEE is talking about EUI-64 being the native MAC format for future versions
of ethernet. That's also why EUI-64 is the native MAC format for firewire, for
example (though admittedly Apple does stupid EUI-64 assignments to their FW
interfaces using modified EUI-48 formats rather than an EUI-64 based OUI).


>>>>     whether EUI-64 the stable
>>>> 	addresses you are proposing. You only get a slight reduction
>>>> 	for systems which move to different networks because,
>>>> 	for the moment, nobody has cracked a way to shortcut the
>>>> 	math to predict likely changes in values based on the
>>>> 	delta between two subnet values. I'm willing to bet
>>>> 	that gets solved within the lifetime of IPv6.
>>> 
>>> This analysis is only meaningful for the privacy aspect, rather than for
>>> the address-scanning aspect.
>> 
>> Not really. If I know your address on subnet A and I can predict the resulting
>> suffix when A becomes B, then, I only need to scan you once. Point is that
>> if someone cracks that, then, your stable addresses become as transparent
>> across networks as EUI-64.
> 
> If someone cracks that, the last of your concerns will be this IPv6
> addressing issue.

I don't necessarily have to crack it. All I have to do is somehow get your
Mac address. However, if I can crack it, then getting your MAC becomes much
easier.

Worst case, I can off-line brute force the hinted 48-bit possibilities through
the algorithm to find the one that yields the right "randomized" 64-bit pattern
and then crank that discovered MAC through the algorithm again with the other
prefix.

> 
> 
>> 
>>>>>> 	2.	What are the costs or drawbacks of address randomization?
>>>>> 
>>>>> None.
>>>>> 
>>>> 
>>>> I call BS here.
>>>> 	A:	Human Factors -- Increased error rate.
>>> 
>>> No worse than ma-derived-kids
>>> 
>> 
>> I disagree. With mac-derived kids, I can look at the mac and the IP address and
>> know pretty quickly that they don't match or that there is some other error.
> 
> But since you cannot assume that v6 addresses will have mac-derived
> IIDs, the test is not really meaningful.

But I can look at an address and tell if it's MAC derived pretty quickly and easily
and if it is, I can apply that test as a form of checksum. I've gotten pretty efficient
at doing so in several environments to the point that it is almost automatic.


>>>> 		2.	Harder to correlate nodes for logging as they move
>>>> 			around the enterprise.
>>> 
>>> You don't really on this kind of thing for v4... or do you?
>> 
>> It's not available in v4, so I have to scrape the mac addresses out of the
>> switch instead. Having said that…
>> 
>>> That said, you might have the same difficulty even if you do dhcpv6, so….
>> 
>> If I do DHCPv6 (and I usually don't, frankly), then I can log the mapping
>> of the DUID for correlation.  With SLAAC, I can correlate using the MAC
>> address. With your proposal and with RFC-4941, it's chaos.
> 
> Chaos is already there because there's no way to enforce a policy or at
> least suggest a policy for address generation.

Suggesting yet another policy only increases the chaos, so, of course that
is what you are doing.

> [...]
>>>> Actually, there are benefits from having a host have the same stable ID across
>>>> multiple networks.
>>> 
>>> f anything, that does *not* require mac-derived IIDs. SO there's no
>>> argument in favor of such IIDs.
>>> 
>> 
>> Sure there is… They provide a convenient consistent stable IID that is well
>> understood, well documented, and has no drawbacks unless you are concerned
>> about privacy, in which case, having a stable ID across multiple networks
>> should be a non-starter.
> 
> I disagree. You cannot be tracked across networks with such IIDs.

I call BS and you know it.

>>>> True, those benefits may well be antithetical to some aspects
>>>> of security and are certainly antithetical to privacy, but, you cannot deny that
>>>> they are benefits from a host administration perspective on some levels.
>>> 
>>> Since you cannot rely in any specifich scheme being used, this argument
>>> is essentially void.
>> 
>> But I can rely on SLAAC being used if I configure the subnet router to instruct
>> hosts to use SLLAC.
> 
> But you cannot rely on any specific IID-generation policy, so….

Sure I can. I can't rely on ALL addresses being MB EUI-64, but I can rely on the host
generating AT LEAST a MAC-based EUI-64 address under the current rules.
I realize that you are trying to break that (thanks for pointing that
out, I didn't feel compelled to oppose your draft before that, I was
just neutral).


>>> Fr instance, when it comes to hosts, most connections will be
>>> "outgoing", and hence you'd have to deal with eg.g RFC4941. At which
>>> point, you need something along the lines of ipv6mon
>>> (http://www.si6networks.com/tools/ipv6mon), or do DHCPv6 and hope all
>>> nodes support it
>> 
>> Actually, I don't. I've got the MAC address and I know the SLAAC address
>> if I know the MAC address, so, all I need to do is track the privacy
>> address entries in the ND table and I have all the correlation I need.
> 
> Where would you do the logging and correlation? -- Because unless you've
> communicated with the corresponding nodes, you won't have such entries
> in the ND cache.

If I'm logging something about your address, then I've obviously had a
conversation with you. If I'm not on your local subnet, then the log
and/or correlation will involve scraping the ND tables off switches.
Hence my preference for DDNS. As I said, RFC4941 on by default is a
bad thing and I'm very disappointed that OS vendors have implemented it.

>> Yes, the world would be a better place if RFC-4941 was something you had
>> to deliberately turn on. Unfortunately, people like you have convinced
>> vendors to go in the opposite direction.
> 
> You're wrong. I never was an advocate of "RFC4941 on by default". OTOH,
> I did try to make this manageable (see draft-gont-6man-managing-slaac-policy)

I didn't say you, I said people like you. Those who think that security is
the number one primary goal of the internet and that operability and
availability should take a back seat.

>>>>>> 	4.	What are the costs and/or drawbacks of non-random addresses?
>>>>> 
>>>>> They allow for IPv6 address scanning attacks.
>>>> 
>>>> Other than on mobile/portable systems, not significantly more so than your
>>>> proposed draft.
>>> 
>>> The patterns arising from the IEEE OUI is clearly removed -- isn't that
>>> a significant difference?
>> 
>> No, it's not. If the address persists across a long time, then, pattern removal
>> becomes a less significant benefit.
> 
> At the point at which that become an issue, you should probably be doing
> something else.

You mean like rotating addresses periodically ala RFC-4941? :P


>>>>>> 
>>>>>> If you don't use DNS, then address randomization is asking for
>>>>>> some serious human factors challenges which will probably reduce effective
>>>>>> availability.  
>>> 
>>> How are mac-derived IIDs any better than the IIDs specified in
>>> *stable-privacy-addresses?
>> 
>> I can more easily sanity check them for obvious typos. True, the last 24 bits
>> are still at risk, but, there are values I will come to expect in the ordinary
>> course for the first 24 bits and values I will consider suspect. The next 16
>> bits are predictably and reliably 0xfffe.
> 
> Errors? What kind of troubleshooting would you be doing?

Among other things, correlating ACL problems.

>>>>>>> I guess Jim's point was that on some occasions, the DNS itself might be
>>>>>>> yet another point of failure. e.g., you don't want to be troubleshooting
>>>>>>> your network, and find that the very first problem is that you don't
>>>>>>> know which address to ssh to because the DNS is not working, either.
>>>>>> 
>>>>>> Fair point, but, seems to me that getting DNS working first isn't
>>>>>> an unreasonable priority.
>>>>> 
>>>>> IN the aforementioned scenarios, you probably care moer about routers
>>>>> forwarding packets than about being able to use fancy names instead of
>>>>> human-unreadable IPv6 addresses -- i.e., talking about priorities…
>>>> 
>>>> I'm not necessarily convinced of that. It depends on which routers and
>>>> who is affected by the DNS not working. If it's a client-side network,
>>>> then likely it doesn't matter whether the routers forward anything or
>>>> not if DNS cannot be resolved. Try this experiment…
>>> [....]
>>>> In my mind, if you have a positive tally, that indicates that your user
>>>> population cannot distinguish between a working network with no DNS and
>>>> a non-working network.
>>> 
>>> If you're just forwarding packets destined to someone else's server,
>>> then failure of *your* DNS does not really affect the users, but just
>>> your troubleshooting.
> [...]
>> If you mean my authoritative servers, then, that's true, but I cannot remember
>> the last time my authoritative servers failed to such an extent that I would
>> need to troubleshoot the network equipment by address. You'd have to be really
>> bad at designing DNS infrastructure for that to be at all likely.
> 
> The same argument could probably be done about anything in life.

No, there are lots of things that are failure prone without bad design necessarily
being a factor. Space flight, for example, comes to mind.

> [...]
>>>> Yes, I have taught people from no knowledge to the point of successfully
>>>> editing zone files with A, AAAA, MX, and PTR records in 30 minutes. If
>>>> you teach them what the records mean at the same time you teach them
>>>> how the records fit in zone files in BIND, it can be done.
>>>> 
>>>> No, I didn't teach them how to troubleshoot DNS in that time. That's
>>>> another 30 minutes. Since nothing really changes for DNS with IPv6
>>>> other than A->AAAA and in-addr.arpa -> ip6.arpa, for people with no
>>>> prior knowledge, it's easier to just teach them in parallel rather than
>>>> bother with teaching one and then the changes for the other.
>>>> It's also faster.
>>> 
>>> Me, I'd be much more concerned about such folks operating the DNS, than
>>> about the human factors in communicating v6 addresses. YMMV, though.
>> 
>> Not sure what you mean by that.
> 
> I would never have a guy that just received a 30' DNS training
> administering a production DNS server.

Nor would I  as a general rule. However, I'll put the guy I trained in 30
minutes up against the guy that spent a week reading the O'Reilly book
cover to cover and didn't understand a word of it.

Training is just that… Training. After training comes experience and then
competence. Usually my 30 minute course is followed by a 2-3 hour hands-on
lab session, but that's not always feasible.


>>>>>> Actually, I don't consider that one poorly thought out, I just don't
>>>>>> consider it particularly related to security. I think arguing that it is
>>>>>> a security tool is poorly thought out and I'm sure BSD is willing to
>>>>>> implement it because they bought that poorly thought out argument
>>>>>> hook line and sinker.
>>>>> 
>>>>> It's fairly simple:
>>>>> 
>>>>> * it mitigates address scanning attacks -- therefore it does have an
>>>>> effect on security.
>>>> 
>>>> Except it doesn't really mitigate address scanning attacks, 
>>> 
>>> mitigate != eliminate
>> 
>> I am well aware of that. I'm arguing that it doesn't even effectively reduce
>> them, which is, IMHO, the requirement for claiming mitigation.
> 
> The math is in draft-ietf-opsec-ipv6-host-scanning. Why do you argue
> that they don't mitigate scanning attacks?

Because to reduce the efficacy of a scanning attack, the host has to no longer
be sitting "there" when the scan arrives. Since you're not budging, you may
(slightly) delay the arrival of the scan, but you're not going to delay it by
all that much and you may accelerate it in some cases.

>>> Please do the math. THe difference is significant.
>> 
>> I suppose that's a matter of perspective.
>> 
>> Host lasts 5 years. IMHO, the difference between 32 years and 6400 years
>> isn't all that meaningful.
> 
> How do you get to that number of "32 years"?
> 

I gave you the math earlier. Basically 1000 pps and 40 bits of space to scan
is approximately 32 years.

>>>> Except it doesn't entirely, but, if it has any value at all, it is in
>>>> its ability to (marginally) improve privacy.
>>>> 
>>>> (Unless I missed the part where your draft requires the host not to
>>>> also have an EUI-64 IID in addition to the random one. 
>>> 
>>> Yes, you did miss Section 3:
>>> 
>>> ---- cut here ---
>>> 3. Algorithm specification
>>> 
>>> 
>>>  IPv6 implementations conforming to this specification MUST generate
>>>  interface identifiers using the algorithm specified in this section
>>>  in replacement of any other algorithms used for generating "stable"
>>>  addresses (such as that specified in [RFC2464]).  The aforementioned
>>>  algorithm MUST be employed for generating the interface identifiers
>>>  for all of the IPv6 addresses configured with SLAAC for a given
>>>  interface, including IPv6 link-local addresses.  Implementations
>>>  conforming to this specification SHOULD provide the means for a
>>>  system administrator to enable or disable the use of this algorithm
>>>  for generating Interface Identifiers.  Implementations conforming to
>>>  this specification MAY employ the algorithm specified in [RFC4941] to
>>>  generate temporary addresses in addition to the addresses generated
>>>  with the algorithm specified in this document.
>>> ---- cut here ----
>> 
>> Then I now oppose the specification as written because preventing the
>> host from accepting inbound connections to the known EUI-64 is an increase
>> in the brain damage beyond even that specified in RFC-4941.
> 
> The brain damage is to assume that you'll find a piece of layer-2 shit
> in a layer-3 address.
> 

We'll have to agree to disagree about that.

First, I wouldn't characterize MAC addresses as shit. They serve a very
important purpose and they have done it very well for many years. They
certainly have a better track record over a longer time as portions of
L3 addresses than anything you are advocating or RFC-4941.

(Think IPX)

> 
> 
>>>> A stageful firewall will do far more to protect you from address scans
>>>> than unnecessary complexity in the addressing.
>>> 
>>> Security is not "this XOR that".
>>> 
>> Sure, but putting a screen door on a bank vault is still stupid.
> 
> Where's the screen door here?
> 

draft-ietf-6man-stable-privacy-addresses

True, it's more like a hinged piece of tissue paper in terms of its security
implications, but, I was trying to be nice.

I agree that it provides some privacy, but, from a security perspective,
you can argue that it's technically an improvement all day. I don't
disagree, I just point out that the amount of improvement is so insignificant
compared to the nuisance factor that it's really not worth doing in most
situations.

>>>>> Additionally, there's no reason why I want my addresses to be
>>>>> predictable. They are already human-unreadable when they employ
>>>>> MAC-derived IIDs. SO if they are going to be human-unreadable, at least
>>>>> let them be random. -- we have a long history of predictable IDs,
>>>>> already (starting from the IPv4 world, of course).
>>>> 
>>>> But you aren't the only person on the planet and there are perfectly
>>>> valid reasons that others may want addresses to be predictable.
>>> 
>>>> From that pov, we should all shove stuff [complete the phrase as
>>> appropriate :-) ] because there's people that love it….
>> 
>> First, I don't accept your premise that MAC derived IIDs are not human-
>> readable. I use them too often to believe that.
> 
> They are not. And they are hard to remember. I usually need to look at
> least twice to copy one v6 address from one place to another.

I can recite many of mine from memory. Perhaps this is because I've been
doing this longer or more often. Perhaps it is because I can also recite
my credit card numbers and passport numbers from memory.

They are quite human readable as far as I am concerned since I read them
all the time and I am a human.

>> Second, until you pointed out section 3, I didn't oppose your draft, I
>> just didn't want to use it in my environment and didn't feel that it
>> offered any advantage.
> 
> The draft doesn't obsolete the mac-derived IIDs. It just gives you the
> option to do something different. If you don't like it, you can still do
> mac-derived IIDs.

No, but it does require that a system implementing your hair-brained scheme
turn off it's MAC-based EUI-64 address which I oppose. At least RFC-4941
doesn't have that problem.

>>> That's not true. The only reason for which RFC4941 addresses vary over
>>> time is that that prevent an external node from correlating activities
>>> of nodes within the same network. -- i.e., be able to tell that this
>>> connection request was issue by the same host that had issued that other
>>> connection request a while ago.
>>> 
>>> Time-variance in RFC4941 has nothing to do with address-scanning.
>> 
>> Simply not true. If you don't rotate the random address, then it's only a
>> little harder to find than a non-random address and you now have an
>> arguably unlimited amount of time to do it
> 
> Can you cite your references?
> 
> I seem to recall RFC 4941 arguing otherwise.

Basic math. If you have an unlimited amount of time to search for something
which is a stationary object, then you will eventually trip over it. This
is axiomatic. I'm not sure what reference I could produce to defend such
a basic axiom.

If, on the other hand, the search target is moving and has the ability to
move without being seen by the seeker (instantaneously changing IPv6
addresses qualifies as non-visible movement for this purpose), the odds
of continued evasion over long periods of time are much higher.

>>>> Yeah… I got that the first 20 times you explained it. In fact, I got it the
>>>> first time I read the title. My point is that stability is inherently
>>>> antithetical to the stated goals and once you add the complexity that comes
>>>> with randomization, you get most of the pain of address instability for
>>>> just as long as you get the benefit of randomization.
>>> 
>>> Talk wth admins an operators that disable temporary addresses, and ask
>>> them what's the property of RFC4941addresses that they don't like.
>> 
>> I have. For most of the ones I've talked to, it's the loss of the convenience
>> of correlating the IP address to the switch port.
> 
> That comes from stability, not from predictability.

No, it comes from the fact that the switch port reports it's neighborship in terms
of MAC addresses and MAC-based EUI-64 addresses happen to look a lot like that, so
it reduces one level of required lookup.

>>>> Yes and no. If the host is only receiving connections on that address and
>>>> never originating them, then, you haven't provided that information to anyone
>>>> that didn't already have it, so…
>>> 
>>> And that proves... what?
>>> 
>>> If I know your mac address, and know a set of possible network to which
>>> you might be attached to, I can still track you even if you implement
>>> RFC4941. So yes, RFC4941 does not eliminate all privacy issues related
>>> with IPv6 addresses.
>> 
>> If you know my mac address, then you can track me no matter what.
> 
> How can you leverage the mac address if I implement
> draft-ietf-6man-stable-privacy-addresses?

Admittedly, I might need to reread the draft, but I thought it used a hashing
algorithm against the EUI-64 and the network number to produce a stable
but randomly distributed address. If that's the case, then I can recompute
the hash pretty readily given the same inputs.

Owen