Subject: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Apr 2012 14:28:32 -0700

All,

This is a consensus call on adopting:

    Title     : A method for Generating Stable Privacy-Enhanced Addresses with
                IPv6 Stateless Address Autoconfiguration (SLAAC)
    Author(s) : Fernando Gont
    Filename  : draft-gont-6man-stable-privacy-addresses-01
    Pages     : 15
    Date      : 2012-12-31

    http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses-01

as a 6MAN working group document.  Please state your opinion, positive
or negative, on the mailing list or to the chairs.  This consensus call
will end on April 26, 2012.

Regards,
Ole Troan & Bob Hinden

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 12 Apr 2012 17:04:39 -0500

Maybe I missed it in the I-D, but this mechanism appears most useful for mobile devices, which roam among different networks. The stable Interface ID is only stable as long as the portable device stays connected to one access point, which presumably would not be very long.

With that in mind, I'd be in favor of pursuing this.

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Thursday, April 12, 2012 5:29 PM
To: IPv6 WG Mailing List
Cc: 6man Chairs
Subject: Consensus call on adopting: <draft-gont-6man-stable-privacy-addresses-01>

All,

Regards,
Ole Troan & Bob Hinden
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Karl Auer <[email-masked]>
Date: Fri, 13 Apr 2012 10:14:28 +1000

On Thu, 2012-04-12 at 14:28 -0700, Bob Hinden wrote:
> or negative, on the mailing list or to the chairs.

Positive.

That said, I have some comments. My apologies if I have missed some
discussion where these were covered already:

1: I'm unsure about this bit:

    IPv6 implementations conforming to this specification
    MUST generate interface identifiers using the algorithm
    specified in this section.

While this does not explicitly *say* that other interface identifiers
MUST NOT be used, that interpretation seems to be possible. A hint that
stable addresses may be used alongside privacy addresses, is found in
the sentence:

    On the other hand, in scenarios in which "Privacy Extensions"
    are employed, implementation of the mechanism described in this
    document would [...]

Section five does mention replacing IEEE-based interface IDs, but I
think it needs to be stronger, one way or the other. The document should
make clear which other mechanisms it excludes, if any - for example,
that a host using this mechanism SHOULD NOT (MUST NOT?) also generate
interface IDs based on IEEE identifiers but MAY also use privacy
extensions. See also point 4 below.

2: What exactly is a "serial number"? Do all machines, even
small/embedded etc machines, have a serial number? Seems to me that the
algorithm should use a default value, such as zero, for the "serial
number" if none is available OR should fail to generate a secret key
(and thus fail to generate interface IDs later). My preference would be
for the first of these - i.e., a default.

3: Related to the previous point, if it is possible to fail to generate
a secret key, there needs to be a defined value for "secret key" that
indicates an invalid secret key - perhaps zero. If the secret key has
this value, the host MUST NOT autoconfigure a stable address.

4: Assuming point 1 above has relevance, and a host using this algorithm
MUST NOT also use IEEE-based interface IDs, then a host which fails to
generate a stable address for any reason MUST NOT fall back to the use
of IEEE-based interface IDs. Why? Because that would expose the host to
precisely the disadvantages that the stable addresses were supposed to
prevent.

5: Duplicate address detection is not mentioned explicitly, but probably
should be - what happens if a host does DAD and determines that its
stable address is already in use?

6: The interface IDs generated are 64 bits long. I think it should be
stated explicitly that this algorithm MUST NOT be used where the prefix
is not 64 bits long.

7: Add "An implementation SHOULD provide the means for the user to
enable and disable the use of stable addresses."
 
8: This may be a bit out of scope, but it occurs to me that being able
to specify a static interface identifier and have it used in any
(64-bit) prefix would also be useful in some contexts. That is, have an
address which is stable, but explicitly specified.
 
Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Apr 2012 08:14:13 +0100

> will end on April 26, 2012.

Yes to adoption. Karl Auer's points all need discussion, and I think
we also need to consider the impact on 3484bis.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Apr 2012 10:09:55 +0200

A question for the draft author:

At one point you write that the intent is to replace EUI-64-based
addresses (Section 5).  But that doesn't seem to jibe with what you
write in the intro about RFC-4941.  I am concerned that adopting this
mechanism will make matters worse if this mechanism is being used as an
alternative to CGAs, as opposed to EUI-64s..

Eliot

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Apr 2012 11:37:39 +0100

> we also need to consider the impact on 3484bis.

Yes, let's adopt.

Personally I think a different name for these types of addresses would be more appropriate, to avoid confusion with RFC4941 Privacy Extensions.  If I understand it correctly, essentially what you are defining is randomised stable-per-prefix public interface identifiers, but that's not a catchy term :)

On 3484bis, if stable privacy addresses are alternative public (not temporary) identifiers for hosts then is there anything more to say?  What impact are you considering Brian, other than would exist if two other public addresses existed on an interface?

Note that RFC4941 temporary addresses can also be stable, in that they do not change if the host stays on the same network; the specification only says identifiers SHOULD be regenerated at some defined interval.  

Finally, it would be interesting to know what algorithm Windows uses to generate its identifiers; they are randomised, public and stable.  I had thought they were based on the prefix, but Fernando's tests suggest not. 

Tim

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Apr 2012 14:31:22 +0200

hI, Eliot,

On 04/13/2012 10:09 AM, Eliot Lear wrote:
> addresses (Section 5).  

Exactly.

> But that doesn't seem to jibe with what you
> write in the intro about RFC-4941.  

Could you please cite the "conflicting" text?

> I am concerned that adopting this

I don't follow. Could you clarify your concern?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Apr 2012 15:29:40 +0200

Hi, Karl,

Thanks so much for your feedback! Please find my comments inline...

["Subject" changed so that this discussion doesn't mix up with the poll]

On 04/13/2012 02:14 AM, Karl Auer wrote:
> MUST NOT be used, that interpretation seems to be possible.

Good point. Maybe we could replace that para with:

"IPv6 implementations conforming to this specification MUST generate
interface identifiers using the algorithm specified in this section in
replacement of Modified EUI-64 format identifiers."
?

> A hint that

Please let me know if the suggested change (above) is okay, or whether
you think it would be better to include an additional note with
something along the lines of "That is, they MUST NOT employ Modified
EUI-64 format identifiers, but MAY still implement RFC 4941 in addition
to the algorithm specified in this document".

> 2: What exactly is a "serial number"? 

Some number that varies from one machine to another, which is not
expected to be known by an attacker.

> Do all machines, even
> small/embedded etc machines, have a serial number? 

Now that you mention it, I think I should tweak the corresponding text,
making inclusion of such serial number a "MAY".

> Seems to me that the

Agreed. Either that, or simply not include the serial number if it's not
available.

> a secret key, 

It shouldn't be possible. The idea is that the secret key is set to a
random number (by default).

> precisely the disadvantages that the stable addresses were supposed to

Agreed. But this would be implied when we say "... MUST use this
algorithm in replacement of Modified EUI-64 format identifiers"?

> stable address is already in use?

Address configuration fails.

Note: I didn't discuss DAD because to some extent *what* you do is not
discussed in the traditional-SLAAC specs.

That said, if deemed appropriate, one could include one additional byte,
"DAD" in the hash function, which is initialized to 0, and that is
incremented by 1 if the host wants to try a different address if/when
DAD fails.

If we do that, the implementations should probably cache the resulting
address, such that it is stable. (otherwise the resulting address might
change if the same node was brought up while the node with the
conflicting address is off).

> stated explicitly that this algorithm MUST NOT be used where the prefix

Actually, this algorithm could still be used with longer prefixes (i.e.,
fewer bits for the IID). So I'm not sure whether we should include this
requirement. e.g., if we were to eventually allow non-/64 autoconfigured
addresses, this algorithm could be use without any changes (while the
traditional MAC-based identifiers couldn't).

(Note: Just me thinking out loud).

> enable and disable the use of stable addresses."

May be s/stable addresses/this specification/?

That said, I think we should probably note what nodes are supposed to be
done with this specification as a whole. Me, I'd argue that "nodes
SHOULD employ generate IIDs with this algorithm in replacement of
Modified-EUI 64 format identifiers" -- since we clearly want to move
away from MAC-based IIDs.

(Note that this is a different issue from item #1 above: Item #1 above
is about what you should do if you implement this spec, while the point
that I'm making in the previous paragraph is that you SHOULD implement
this spec).

Thoughts?

> address which is stable, but explicitly specified.

The problem is that as soon as you use a static identifier, you can be
tracked. -- Yes, you may argue that if your identifiers is "::1", then
it's very likely that many other systems will be using the same
identifier, and hence it would not be of much help to an attacker for
tracking purposes.... but I'd say that's walking a fine line.

Additionally, I'd argue that in order to have such thing, then
1) You'd need to manually configure your address each time you move from
one network to another (as with manual configuration requires you to set
the whole address, rather than just the IID bits), or,

2) You should be using e.g. Windows algorithm for generating the IIDs,
which is sub-optimal, since they mitigate only host-scanning attacks and
not host-stacking attacks.

That said, I wonder what the use might be. e.g., would the user be
expected to remember all the bits from the IID, and then say "ok, the
prefix we're using on this net is [blah..blah], so the resulting IPv6
address of the host with known IID is blah-blah"? -- If that's the
expected use case, then I'd argue that you should be doing mDNS, LLNR,
or DNS dynamic updates....

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Apr 2012 14:45:51 +0200

Hi, Tim,

On 04/13/2012 12:37 PM, Tim Chown wrote:
> Extensions.  If I understand it correctly, essentially what you are
> defining is randomised stable-per-prefix public interface
> identifiers, 

Exactly.

> On 3484bis, if stable privacy addresses are alternative public (not
> temporary) identifiers for hosts then is there anything more to say?

Not that I can think of.

> Note that RFC4941 temporary addresses can also be stable, in that
> they do not change if the host stays on the same network; the
> specification only says identifiers SHOULD be regenerated at some
> defined interval.

Two things:

* If you do RFC 4941 but do not change the addresses over time (e.g. as
Windows does for their stable addresses), then you can be tracked
exactly in the same way as with MAC-based addresses. Such addreseses
mitigate only host-scanning attacks (i.e., they are unpredictable), but
since there's a constant identifier used across networks, tracking is
still possible. -- So at the time you implement RFC 4941 without
regenerating the addresses over time, they are not *privacy* extensions
anymore :-)

* IMO, it is a bit of a strech to say "RFC4941 temporary addresses can
also be stable", implying that stability is allowed. That would be the
case if "identifiers MAY be generated at some defined interval". But if
it's a SHOULD, and you go against it, you're not fully-compliant with
the specification. ("SHOULD" just means that there are specific cases in
which you're allowed to not follow the recommendation).

> Finally, it would be interesting to know what algorithm Windows uses
> to generate its identifiers; they are randomised, public and stable.
> I had thought they were based on the prefix, but Fernando's tests
> suggest not.

Dave Thaler commented on this one during the 6man wg meeting at IETF 83:
They do RFC4941, without changing the addresses over time. Hence, the
identifiers are constant across networks.

This means that they mitigate host scanning attacks, but as noted in
draft-gont-6man-stable-privacy-addresses-01 they are still subject to
host-tracking.

Thanks!

Best regards,

---

From: Karl Auer <[email-masked]>
Date: Sat, 14 Apr 2012 10:36:14 +1000

> replacement of Modified EUI-64 format identifiers."

While that is good, it would be clearer if it was expanded out to make
the desired points separately:

   It is intended that the use of Modified-IEEE interface identifiers
   be replaced wherever possible by the use of interface identifiers
   generated as described in this specification.

   When generating interface identifiers, IPv6 implementations
   conforming to this specification MUST use the algorithm specified
   in this section.

   [I'm not sure this is necessary - it seems to be saying that
   "conforming implementations have to conform"]

   IPv6 implementations conforming to this specification MUST NOT use
   Modified-IEEE format interface identifiers [see 4291 Appendix A] for
   any purpose EXCEPT THAT link local addresses MAY be generated using
   Modified-IEEE format interface identifiers.

   [remove everything from EXCEPT THAT onwards if that isn't what you
   intended]

   If for any reason the generation of an interface identifier
   according to this specification fails, IPv6 implementations
   conforming to this specification MUST NOT fall back to
   using Modified-IEEE format interface identifiers.

   Interface identifiers other than Modified-IEEE interface identifiers
   MAY be used in addition to interface identifiers generated according
   to this specification.

> random number (by default).

I still think you need a special value for "invalid secret key", so that
any systems do not have any way to obtain random numbers can refuse to
autoconfigure if the key is not set.

> Address configuration fails.

That should be in the spec.

> conflicting address is off).

This may not be possible on systems with no onboard storage, and makes
things much more complicated. I suggest that if DAD fails, then
autoconfiguration should just fail (at least as regards stable
addresses).

> traditional MAC-based identifiers couldn't).

I like the 64-bit limitation. Either way it should be made explicit.

> May be s/stable addresses/this specification/?

Fine.

> that I'm making in the previous paragraph is that you SHOULD implement

I don't think a spec can mandate it's own use unless it obsoletes or
updates a spec that mandates something. Your spec would have to update
4291, for example, replacing the whole modified-IEEE thing with your
mechanism. That's a BIG step.

> the whole address, rather than just the IID bits), or,

No - you could just have a flag that says "the key is the interface
identifier I want to use - verbatim". Then that IID gets appended to
whatever prefix happens along. Obviously this does NOT have the same
anti-tracking qualities etc, but I can see it being useful. It's
basically a variation on static addresses that allows portability
between networks without having to reconfigure the host. Just as with
other forms of static addressing, it is absolutely the administrator's
problem to avoid conflicts.

Regards, K.

---

From: Washam Fan <[email-masked]>
Date: Sat, 14 Apr 2012 14:24:44 +0800

Hi,

> things much more complicated.

+1. And the storage or filesystem could have been damaged.

> I suggest that if DAD fails, then
So what is the next step if the autoconfiguration fails? static
configure? If yes. Will the next reboot try autoconfiguration again?
If yes, you may have non-stable addresses within the same network. If
no, when you move to another network you should explicitly revoke the
static configuration and enable autoconfiguration again.

I think the author should clarify this DAD failure issue in the next version.

THanks,
washam

---

From: Karl Auer <[email-masked]>
Date: Sat, 14 Apr 2012 16:48:40 +1000

> static configuration and enable autoconfiguration again.

If autoconfiguration fails, then it fails. There is no automated
fallback; the host stays address-less (or at least
stable-address-less :-) until the situation is resolved by external
action.

How the conflict should be resolved is out of the scope of the draft.

> I think the author should clarify this DAD failure issue in the next

Yes in any case. But I don't think it has to be more complicated than
"if Duplicate Address Detection (DAD) detects an address conflict, the
host MUST NOT use the address." Maybe also add "A host MAY continue to
attempt DAD in the hope that the address conflict is resolved; in this
case additional DAD attempts should be infrequent." The latter allows an
unattended host to recover without assistance.

Regards, K.

---

From: Tim Chown <[email-masked]>
Date: Sat, 14 Apr 2012 11:30:23 +0100

> problem to avoid conflicts.

I while ago I put this one forward, which is an alternative to Fernando's suggestion that you have to set the whole address:

http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-00

This was based on existing implementations, in Solaris and Linux (as a demonstrator), with the potential for simpler renumbering in mind. It's probably the complete antithesis of what Fernando is trying to achieve, but is aimed at the type of (server) systems that would probably be DNS-advertised anyway. 

Tim

---

From: Fernando Gont <[email-masked]>
Date: Sat, 14 Apr 2012 14:05:07 +0200

>    generated as described in this specification.

Shouldn't it be specified with RFC 2119 language?

>From my pov, it means that all the algorithm is mandatory (nothing to
add or take out).

>    [remove everything from EXCEPT THAT onwards if that isn't what you

Yep. I think it would be better to have all IIDs generated with the
algorithm.

>    MAY be used in addition to interface identifiers generated according

Ok, I will add this.

> autoconfigure if the key is not set.

I'd like other to weigh in on this one. -- I don't think there's a need
for a "invalid secret key". The secret key is supposed to be
generated/selected at installation time. If for some reason such
secret_key cannot be randomly generated, the the OS can prompt the user
for one.

> That should be in the spec.

As noted, IIRC this is not clearly defined for traditional SLAAC,
either. So, should we be different in this respect?

> autoconfiguration should just fail (at least as regards stable

This is kind of the way DAD works with traditional SLAAC. However, I'm
not sure whether this is the right approach (to have address
configuration fail as a result of that), or whether it would be better
to have some "backup plan" (even if the address is not stored in on
non-volatile storage). For instance, the IIDs that you generate with
this scheme are not globally unique, and then, probabilistically
speaking, there could be collisions.

> I like the 64-bit limitation. Either way it should be made explicit.

Is this made explicit in any RFC for traditional SLAAC addresses?

> mechanism. That's a BIG step.

Well, that shouldn't be a big deal, and it would be a big advance. If we
were to pursue that path, it should be a "SHOULD", such that in specific
scenarios or circumstances nodes can still used the MAC-based addresses.

> identifier I want to use - verbatim". 

Sorry, what you put in the key would be used for setting the IID??

> Then that IID gets appended to
> anti-tracking qualities etc, but I can see it being useful. 

What's the use case you have in mind?

Thanks!

Best regards,

---

From: Karl Auer <[email-masked]>
Date: Sat, 14 Apr 2012 23:02:14 +1000

> Shouldn't it be specified with RFC 2119 language?

The first para just described intent. The others used 2119 language.

> Yep. I think it would be better to have all IIDs generated with the

It may be better, but it is a change to a massively widely-implemented
mechanism. I suggest therefore

   "IPv6 implementations conforming to this specification MUST NOT
    use Modified-IEEE format interface identifiers [see 4291 Appendix
    A] for any purpose EXCEPT THAT link local addresses MAY (but SHOULD
    NOT) be generated using Modified-IEEE format interface identifiers.

> Sorry, what you put in the key would be used for setting the IID??

Yep - if I set the flag and put "::53" in the key, then the address
generated will be prefix::53. But this is just an off-topic idea and not
essential to your draft.

> What's the use case you have in mind?

Don't have one :-)

Regards, K.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 14 Apr 2012 15:20:20 +0200

Hi, Karl,

Please find my comments in-line....

> The first para just described intent. The others used 2119 language.

The point is that without RFC2119-language, we'd not be recommending
nodes whether to use draft-gont-6man-stable-privacy-addresses, and they
might continue using the MAC-based addresses when they should probably
be doing otherwise.

> mechanism. 

Well, yes. But certainly implementations that predate this document
would not need to comply with it (i.e., a product doesn't need to comply
with *future* specifications).

I personally think it would be important to move away from the MAC-based
addresses, not only for their negative security implications
(host-tracking and host-scanning), but also because right now we're
missing the opportunity to take advantage of the IPv6 increased address
space to provide improved security when compared to IPv4.

> I suggest therefore

I don't think that you can have a MAY and SHOULD NOT for the same thing
as noted above: they conflict with each other. Besides, I think that
link-local addresses should be generated with the same algorithm, since
there are ways in which they can leak out, and hence could be
potentially used for host-tracking.

> generated will be prefix::53. 

I think this would be asking for trouble. Somebody might manually set
the secret_key to a secret they use for something else, then mistakenly
set the flag, and then the secret_key leaks out.....

> But this is just an off-topic idea and not
> essential to your draft.

Agreed.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 14 Apr 2012 16:09:33 +0200

On 04/14/2012 12:30 PM, Tim Chown wrote:
> I while ago I put this one forward, which is an alternative to
> Fernando's suggestion that you have to set the whole address:
> 
>  This was based on existing implementations, in Solaris and Linux (as
> a demonstrator), with the potential for simpler renumbering in mind.

Does this really help renumbering? e.g., if you have ACLs, they are
based on the whole IPv6 address, rather than on the IID...

> It's probably the complete antithesis of what Fernando is trying to
> achieve, but is aimed at the type of (server) systems that would
> probably be DNS-advertised anyway.

Note that having an address advertised in the DNS does not necessarily
means that predictable addresses are not useful to an attacker.

For example, let's assume that you know that a network link hosts 100
different servers, each with a different domain.

If their addresses are not predictable, and the attacker wants to find
all of them, he may have to rely on a "dictionary" attack. However, if
the addresses *are* predictable, he could just sweep the interested part
of the address space.

Note: I still don't understand the use case for this technology, or how
the IIDs would be selected (but since they seem to be
manually-generated, I'd expect them to be "low-byte", such as ::1, ::2,
etc.).

Thanks!

Best regards,

---

From: Tim Chown <[email-masked]>
Date: Sat, 14 Apr 2012 15:48:10 +0100

> based on the whole IPv6 address, rather than on the IID...

It helps reduce the need to store full literals in any configuration, so if the host is renumbered, it can have a new "manually configured" address in the new prefix automatically without touching wherever that might otherwise be configured on the host.

Some platforms allow macros, like the IOS ipv6 general-prefix notation iirc.  You can then replace the new prefix and not touch the rest of the configuration.

We did such renumbering tests as long ago as 2004/05, and these tools were certainly useful back then (it's very dated now, but see http://www.6net.org/publications/deliverables/D3.6.2.pdf for example)

> manually-generated, I'd expect them to be "low-byte", such as ::1, ::2,

They can be whatever you want them to be. Based on our IPv6 mail logs, an awful lot of MXs use <prefix>::25 for example. But if you want a stable identifier across renumbering events, or without configuring a full literal, the tokenised identifier concept is quite nice.

I don't know if Sun has any IPR claim on it though.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Apr 2012 15:56:31 +0100

> based on the whole IPv6 address, rather than on the IID...

This is linked to the whole question of why people assign static
addresses and how that interacts with renumbering. By getting rid
of the MAC address (so that the server address doesn't depend on
the network interface hardware) you are part way to static addresses,
and one can imagine a prefix-renumbering mechanism that could handle
this. Of course here we want an IID that is not only stable but is
also well-known; servers don't get address privacy ;-).

Fully static addresses are a pain in renumbering, but that
discussion belongs in 6RENUM (draft-carpenter-6renum-static-problem).

   Brian

    Bian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 14 Apr 2012 17:48:16 +0200

> the network interface hardware) you are part way to static addresses,

At some point I played with the idea of including the interface-index
(rather than the MAC address in F() (in the algorithm in
draft-gont-6man-stable-privacy-addresses), which would still make the
resulting IIDs vary across networks as the host moves, but remain
constant in the presence of hardware changes.

> also well-known; servers don't get address privacy ;-).

Well, they *could* -- please see above.

Thanks!

Best regards,

---

From: Fred Baker <[email-masked]>
Date: Sat, 14 Apr 2012 13:08:06 -0700

Speaking for myself, I don't understand the fixation on MAC addresses. Yes, Ethernet and other IEEE standards are widely used. They are not used on serial links (we seem to mostly use /127 prefixes for that), they are not used on the air side of 3G etc, and so on. And as a matter of fact, for all the discussion of Modified EUI-64 aaddresses in RFC 4291, a host or router sending a packet to another host or router that is directly connected at L3 doesn't extract his peer's MAC address from his IPv6 EID. The point of using a MAC address to generate an EID was to make it likely that the EID was unique within the subnet, not to derive it back again. Once it's an EID, it doesn't matter how it was derived. So from my perspective, the entirety of Appendix A and section 2.5.1 could be replaced with "The EID is intended to be a 64 bit number unique within the subnet. One way to generate such a number is from another number such as is specified by EUI-64, EUI-48, E.164, or E.212, an IPv4 address, or a serial number specific to the hardware in question."

The point of this document is that *another* way to generate it is using a random number generator (privacy addresses), but in such a case there may be certain stability requirements for operational reasons.

May I suggest that the right way to address this is to use much of fernando's technical commentary to substantiate the stability requirements and the need to change it when the prefix is changed (for reasons including a change of LAN, but also including renumbering events) and write a short document updating RFC 4291 to remove the fixation on one of many possible EID types.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 14 Apr 2012 22:32:39 +0200

Hi, Fred,

On 04/14/2012 10:08 PM, Fred Baker wrote:
> Speaking for myself, I don't understand the fixation on MAC
> addresses. 

What do you mean, exactly?

> Yes, Ethernet and other IEEE standards are widely used.
> They are not used on serial links (we seem to mostly use /127
> prefixes for that), they are not used on the air side of 3G etc, and
> so on. And as a matter of fact, for all the discussion of Modified
> EUI-64 aaddresses in RFC 4291, a host or router sending a packet to
> another host or router that is directly connected at L3 doesn't
> extract his peer's MAC address from his IPv6 EID. The point of using
> a MAC address to generate an EID was to make it likely that the EID
> was unique within the subnet, not to derive it back again.

I think this wasn't assumed by anyone (i.e. we all agree on this).

> Once it's
> an EID, it doesn't matter how it was derived. So from my perspective,
> the entirety of Appendix A and section 2.5.1 could be replaced with
> "The EID is intended to be a 64 bit number unique within the subnet.
> One way to generate such a number is from another number such as is
> specified by EUI-64, EUI-48, E.164, or E.212, an IPv 4 address, or a
> serial number specific to the hardware in question."

This still leads to addresses that allow host tracking. -- PLease see
Section 7 of my I-D.

> The point of this document is that *another* way to generate it is
> using a random number generator (privacy addresses), but in such a
> case there may be certain stability requirements for operational
> reasons.

In order to get stable addresses within a subnet, that change across
networks, you need a scheme such as the one proposed. So I don't follow
how the minor mod that you're referring to would address this.

> May I suggest that the right way to address this is to use much of
> fernando's technical commentary to substantiate the stability
> requirements and the need to change it when the prefix is changed

You not only need the ID to change as you move to a different network,
but you also want the ID to be the same when you move back to the same
network.

So I don't follow why you think the path we're following is not the
right path.

For instance, my document aims to do exactly what you are describing.

> (for reasons including a change of LAN, but also including
> renumbering events) and write a short document updating RFC 4291 to
> remove the fixation on one of many possible EID types. 

So you'd include requirements, but don't specifiy how to comply with
them? -- I don't really follow.

And also don't follow why one should start with other I-D, when the
current one has been discussed, presented, and reviewed by quite a few
relevant people, which agreed with the proposal.

Thanks,

---

From: Christian Huitema <[email-masked]>
Date: Sat, 14 Apr 2012 23:20:01 +0000

I agree with Fred that we only need to specify "please somehow get a suitable 64 bit number."  There are a couple of requirements that have to be met -- or at least considered:

1) Uniqueness: the number must be unique within the scope of the subnet.
2) Non traceability: the number should be different for different subnet, so hosts cannot be readily traced as they move to different locations.
3) Privacy: the number should vary over time, to make it harder for Internet services to correlate sessions started by the same host.
4) Stability: the number should remain stable over time, so administrators can more easily manage which host is using what network service.

Of course, stability and privacy are contradictory, so there must be a way for arbitraging that. That's the big issue to be dealt with by the specification of privacy addresses, i.e. whatever successor we write for RFC 3484. The arbitration will be resolving about how often host generate addresses, how many addresses they generate, and under what circumstances do they use one or the other. Let's assume for now that we just want to generate addresses once per subnet.

In principle, there are two ways to meet the unique per subnet requirement: use a number that is guaranteed to be unique by design; or use a large random number that is unlikely to collide with an existing allocation. The problem of course is that random numbers will sometime collide. It may be a low probability event, but it will eventually happen. In fact, even the "unique by design" numbers like EUI64 can collide occasionally, if some management error occurred. That's why we do DAD. So, we have another requirement in the address allocation:

5) Retry: host must be able to detect potential collisions and retry, i.e. generate a different random number.

Fernando's algorithm has several advantages. It uses a hash of a pre-allocated random number, and thus mitigates the issue of weak random number generators in some hosts. It incorporates the subnet prefix, and thus meets the "non-traceability" requirement. But Fernando's algorithm has no provision for "retry", and thus misses a key requirement. So, instead of Fernando's specification, I suggest that we define the algorithm's input as:

   RID = F(Prefix, Modified_EUI64,  Network_ID, secret_key, salt) 

Where prefix , Modified_EUI64, network ID and secret key are defined as per Fernando's proposal, and "salt" is a long integer, typically set to the number of retries used to generate the 64 bit ID.

Of course, if we can support retries, we can also support privacy addresses -- the private address can be generated with just a gratuitous retry, a modified salt. In fact, with that formulation, we can be very close to the format defined in SEND (RFC 3972) -- just replace the "secret key" by the public key of the host. So we have a chance of unifying CGA, privacy addresses, and stable random addresses.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Sat, 14 Apr 2012 16:29:30 -0700

> Of course, stability and privacy are contradictory, so there must be a way for arbitraging that. That's the big issue to be dealt with by the specification of privacy addresses, i.e. whatever succe…

That pp mixes two things:

https://tools.ietf.org/html/rfc3484
3484 Default Address Selection for Internet Protocol version 6 (IPv6).
     R. Draves. February 2003. (Format: TXT=55076 bytes) (Status: PROPOSED
     STANDARD)

https://tools.ietf.org/html/rfc4941
4941 Privacy Extensions for Stateless Address Autoconfiguration in
     IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format:
     TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)

I agree that the arbitrage is largely about the rate of address generation. I should think that's a local matter; two otherwise-identical laptops sitting beside each other on a LAN could be different - one changing its address once a week, and the other changing its address for every TCP session. Apart from the impact of DAD, I don't see much harm in letting them do so.

> In principle, there are two ways to meet the unique per subnet requirement: use a number that is guaranteed to be unique by design; or use a large random number that is unlikely to collide with an existing allocation.

That's for global uniqueness. If all that is required is uniqueness in a subnet, something akin to that makes sense for the first guess, but after that it's all about DAD.

> Fernando's algorithm has several advantages. It uses a hash of a pre-allocated random number,

As I read it, section three item one calls for the use of the EUI-64 in use on the interface, which presumes that the interface is an IEEE 802 LAN. There are other interface types. I'd like to see that widened to a number *such*as* one of the set I specified.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 Apr 2012 00:07:22 +0000

> As I read it, section three item one calls for the use of the EUI-64 in use on the interface, which presumes that the 
> interface is an IEEE 802 LAN. There are other interface types. I'd like to see that widened to a number *such*as*
> one of the set I specified.

You don't really need the EUI64 for the proposal to work. We could just as well completely omit the field, and simply use the EUI64 as an optional seed for the random number. But there are two advantages:

* Using some form of interface ID allows the host to keep just one random seed for all interfaces, which is nice.
* using EUI64 in a context like SEND makes spoofing a little bit harder.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Sat, 14 Apr 2012 18:59:36 -0700

> * using EUI64 in a context like SEND makes spoofing a little bit harder.

I have no problem with the EUI-64 if one exists. I'm pointing out that not all interfaces have one. They might have an E.164 or E.212 number, or other things.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Apr 2012 04:16:13 +0200

On 04/15/2012 01:20 AM, Christian Huitema wrote:
> I agree with Fred that we only need to specify "please somehow get a
> suitable 64 bit number."  There are a couple of requirements that
> have to be met -- or at least considered:
> 
> 1) Uniqueness: the number must be unique within the scope of the
> subnet. 2) Non traceability: the number should be different for
> different subnet, so hosts cannot be readily traced as they move to
> different locations. 3) Privacy: the number should vary over time, to
> make it harder for Internet services to correlate sessions started by
> the same host. 4) Stability: the number should remain stable over
> time, so administrators can more easily manage which host is using
> what network service.

If this is about a fixup for RFC4291 (kind of orthogonal to
draft-gont-6man-stable-privacy-addresses), then I'd argue that the only
requirement to be specified is that of uniqueness. If anything,
different algorithms would make trade-offs among aspects #1-4.

> Of course, stability and privacy are contradictory, so there must be
> a way for arbitraging that. That's the big issue to be dealt with by
> the specification of privacy addresses, i.e. whatever successor we
> write for RFC 3484. The arbitration will be resolving about how often
> host generate addresses, how many addresses they generate, 

I think that the issue of how many addresses you generate is depending
of the addrsel policy. Gnerating addresses is "step 1". Address
selection (step #2) deals with selecting from the addresses generated in
the pervious step.

> In principle, there are two ways to meet the unique per subnet
> requirement: use a number that is guaranteed to be unique by design;
> or use a large random number that is unlikely to collide with an
> existing allocation. 

While in theory this is correct, in practice it isn't: Think about
virtual machines: most implementations use a fixed OUI, and randmize the
Ethernet address from there. Which means that you could have the SLAAC
addresses of two different VMs collide, even if they are supposedley
being generated with globally-unique identifiers.

> The problem of course is that random numbers
> will sometime collide. It may be a low probability event, but it will
> eventually happen. In fact, even the "unique by design" numbers like
> EUI64 can collide occasionally, if some management error occurred.
> That's why we do DAD. So, we have another requirement in the address
> allocation:
> 

The question here is whether this is something that should be dealt with
in each specific algorithm (e.g.,
draft-gont-6man-stable-privacy-addresses-01), or this is something that
should be algorithm-agnostic.

For example, the specification for the generation of tradicional MAC
addresses does not deal with this issue in detail -- and in practice,
implementations do not try a different address when DAD fails.

As noted to Karl in this thread, I'd probably deal with the potential
address collisions (i.e., DAD failures) within the algorithm, Just add a
one-byte or two-byte counter to the hash, that e.g. is initialized to 0,
and incremented each time DAD fails.

> Fernando's algorithm has several advantages. It uses a hash of a
> pre-allocated random number, and thus mitigates the issue of weak
> random number generators in some hosts. It incorporates the subnet
> prefix, and thus meets the "non-traceability" requirement. But
> Fernando's algorithm has no provision for "retry", and thus misses a
> key requirement. 

This could be trivially added as noted above (for instance, I asked
others to weigh in :-) ).

There's also the issue fo whether even in the presence of Ethernet, one
should include the Modified-EUI-64 as a paramenter to the hash function,
or whether one should rather use the interface index: in that case, we'd
gain an additiona benefit -- even for Ethernet, you could replace the
NIC, and the resulting address wouldn't change.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Apr 2012 04:23:32 +0200

On 04/15/2012 01:29 AM, Fred Baker wrote:
> As I read it, section three item one calls for the use of the EUI-64
> in use on the interface, which presumes that the interface is an IEEE
> 802 LAN. There are other interface types. I'd like to see that
> widened to a number *such*as* one of the set I specified.

Agreed. This should, at the very least, be fixed in the way you indicate.

That said, a more general question would be: should we include the
(numeric) interface index rather than e.g. a hardware-specific I-D?

By replacing the "Modified-EUI-64" with the interfaece index, we'd get a
cool feature: you can change the NIC, and that doesn't affect the
resulting IPv6 address.

Thanks!

---

From: Fred Baker <[email-masked]>
Date: Sat, 14 Apr 2012 20:54:53 -0700

On Apr 14, 2012, at 7:23 PM, Fernando Gont wrote:

> That said, a more general question would be: should we include the (numeric) interface index rather than e.g. a hardware-specific I-D?

Hmmm. I would tend to think that's a small positive integer, which isn't all that unique. Are you thinking of something different than I am?

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 Apr 2012 06:19:14 +0000

> Hmmm. I would tend to think that's a small positive integer, which isn't all that unique. Are you thinking of something 

If the only purpose is to make sure that two interfaces on the same host have different ID, then a small integer is sufficient.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Apr 2012 04:27:59 +0200

On 04/15/2012 02:07 AM, Christian Huitema wrote:
> You don't really need the EUI64 for the proposal to work. We could
> just as well completely omit the field, and simply use the EUI64 as
> an optional seed for the random number. But there are two
> advantages:

You need to be able to differentiate the interfaces, or else two NICs
connected to the same subnet would produce the same IPIv6 address.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Apr 2012 16:28:52 +0200

Hi, Fred,

On 04/15/2012 05:54 AM, Fred Baker wrote:
> Hmmm. I would tend to think that's a small positive integer, which
> isn't all that unique. 

Exactly.

> Are you thinking of something different than I am?

I don't think so.

If you concern is security, bear in mind that the security of the
mechanism relies on the cryptographic strength of F(), and the
secret_key (and not on the "data" that is hashed. -- That said, the
current I-D recommends to include the machine's serial number in the
hash (as recommended by Steve Bellovin) as part of the data to be hashed
(and this value is expected to be unknown at least to a remote attacker).

If your concern is that two hosts might end up computing the same IID,
then note that the recommendation is for the secret_key to be set to a
random value, *and* as noted in the previous paragraph, we also
recommend to include the machine's serial number as part of the data to
be hashed (and this number is expected to vary from one node to another).

This approach would lead to addresses that do not vary if you change the
NIC (as we'd not be using the MAC address), and one might argue that is
even more 2general" since, as you correctly noted, not all interfaced
have IEEE addresses.

IN any case, this is just an idea. I personally think that would be
really cool. But I'd like you and others to comment.

Thanks!

Best regards,

---

From: Tina TSOU <[email-masked]>
Date: Sun, 15 Apr 2012 20:55:49 +0000

This function results in addresses that:

1. R stable within the same subnet
2. Have different Interface-IDs when moving across networks

Sent from my iPad

On Apr 15, 2012, at 7:30 AM, "Fernando Gont" <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Fred,

On 04/15/2012 05:54 AM, Fred Baker wrote:
That said, a more general question would be: should we include the
(numeric) interface index rather than e.g. a hardware-specific
I-D?

Exactly.

I don't think so.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Wed, 18 Apr 2012 11:25:57 +0200

Dear all,

I support this document to be an official working group document.

IPv6 is being considered to be a protocol providing Internet access from
vehicles. When we consider vehicular communications, location privacy
becomes vital. The described mechanism "stable-privacy-addresses" would
help for it.

Cheers.

-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Apr 2012 11:37:57 +0200

Dear Fernando,

My apologies for the delayed response:

> Could you please cite the "conflicting" text?

Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where
you're quoting):
>      As noted in [RFC4941], "anytime a fixed identifier is used in
>       multiple contexts, it becomes possible to correlate seemingly
>       unrelated activity using this identifier".  Therefore, since
>       "privacy addresses" [RFC4941] do not eliminate the use of fixed
>       identifiers for server-like functions, they only *partially*
>       mitigate the correlation of host activities (see Section 7 for
>       some example attacks that are still possible with privacy
>       addresses).  Therefore, it is vital that the privacy

And so on.  In essence you set up an argument against 4941 but that
isn't really your argument for the draft and so I don't really know what

> I don't follow. Could you clarify your concern?

You argue that this is an alternative to EUI-64s.  But in practice I am
concerned that people will not use this as an alternative to EUI-64s,
but instead as an alternative to CGAs, thus improving tracibility (not
generally a good thing).  Please explain what I'm missing (I'm sure it's
a lot).

Eliot

---

From: Fernando Gont <[email-masked]>
Date: Wed, 18 Apr 2012 12:43:44 -0300

Hi, Eliot,

>>> At one point you write that the intent is to replace EUI-64-based

[Correcting myself]

The intent is to have draft-gont-6man-stable-privacy-addresses used
instead of the IIDs that embed IEEE identifiers.

> it's doing there.  

It's not an argument against RFc4941, but rather an argument that even
with RFC4941, you still need to do something about the IEEE-based IIDs.
At the Paris IETF, some folks argued that if you have RFC 4941 in place,
you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of
draft-gont-6man-stable-privacy-addresses (which should be an Appendix,
rather than a section in the main body of the document) illustrates that
that's not the case: even if you're employing RFC4941, you're still
subject to host-scanning attacks and host tracking.

It is *not* an argument *against* RFC 4941, since it *is* valuable to
have addresses that change over time for outging communications.

>But perhaps that's not as important as this:
> 
> You argue that this is an alternative to EUI-64s.  

Let me correct myself: this is an alternative to IIDs that embed IEEE
identifiers: The modified EUI-64 format is a general format, and it does
not need to embed IEEE identifiers (for instance, RFC4941 produce
Mod-EUI-64 format identifiers, bu clearly do not embed IEEE identifiers).

> But in practice I am
> but instead as an alternative to CGAs, 

Why?

I don't really follow the relationship of
draft-gont-6man-stable-privacy-addresses with CGAs. CGAs are used for
SEND, and are not even mentioned in this I-D.

How do you arrive to the conclusion that people might want to use this
instead of CGAs??

As noted in the I-D tihs mechanism is meant to be a replacement for IIDs
based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal
to CGAs.

Thanks,

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Apr 2012 15:34:41 +0200

> subject to host-scanning attacks and host tracking.

Well, host scanning at least.  Host tracking depends on the implementation.

> based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal

I know what you mean.  That matters less than how other people make use
of the work.  Believe me I know.  I've got my name on RFC-1918, for
crying out loud.

Eliot

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Apr 2012 17:17:41 -0300

> Well, host scanning at least.  Host tracking depends on the implementation.

Not sure what you mean. If you don't do
draft-gont-6man-stable-privacy-addresses, you do either IEEE-derived
IIDs, or the randomized-but-stable-across-networks Windows IIDs. -- And
as long as you have stable-across-networks IIDs, you can be tracked.

> of the work.

We can't produce specs for people that cannot read and understand specs.
draft-gont-6man-stable-privacy-addresses solves a real and existing problem.

To me, "people using draft-gont-6man-stable-privacy-addresses instead of
CGAs" makes as much sense as "people using
draft-gont-6man-stable-privacy-addresses instead of TCP" -- I don't even
know how that might happen, and I've not heard your reasoning of why
that might happen.

Cheers,

---

From: Dominik Elsbroek <[email-masked]>
Date: Fri, 20 Apr 2012 13:38:28 +0200

Personally I support this draft. But would like to see stable privacy
enhanced addresses as a replacement for IEEE-based addresses since
they allow an attacker to infer to the vendor of a NIC. On OUIs of
Apple Inc. they also allow conclusion to the operating system.

Thus an attacker gets more information by an IPv6 address than they
should in my opinion.

Cheers,
Dominik

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 20 Apr 2012 15:09:06 +0200 (CEST)

Dear All,
 	I support to have a semi stable private address. But very much 
against the idea of replacing EUI-64 addresses. The client application 
based on the policy should pick pivate or EUI-64 addresses.
Note: - Nothing stops me to pick MAC addresses from no longer existing 
vendor e.g DEC

I think the proper implementation of RFC 3041 or/and 4941 can solve your 
problem

Best Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Director Network and Multimedia
NIIF/HUNGARNET, HUNGARY
Co-chair of Hungarian IPv6 Forum
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2012 15:36:35 -0300

Hi, Mohacsi,

On 04/20/2012 10:09 AM, Mohacsi Janos wrote:
> against the idea of replacing EUI-64 addresses.

You mean "against replacing addresses embedding IEEE identifiers"?

> The client application

Just curious: Is there a specific use case for IEEE-derived addresses
that cannot be satisfied with draft-gont-6man-stable-privacy-addresses?

> Note: - Nothing stops me to pick MAC addresses from no longer existing

Why would you want to do it?

> I think the proper implementation of RFC 3041 or/and 4941 can solve your

I don't follow. RFC 4941 generates addresses in addition to the stable
ones, so.. how could they possibly fix the scanning problem?

Thanks!

Best regards,

---

From: Mohacsi Janos <[email-masked]>
Date: Sat, 21 Apr 2012 11:10:47 +0200 (CEST)

> You mean "against replacing addresses embedding IEEE identifiers"?

yes.

> that cannot be satisfied with draft-gont-6man-stable-privacy-addresses?

The existing implementations. The most important factor of introduction of 
new standards to interoperate the existing ones. I think this 
should be documented in your  draft. Furthermore there are 
several firewalls and monitoring tools which is generating warning in case 
of IEEE-derived address and MAC mismatch. This has to be investigated and 
documented in the draft.

> ones, so.. how could they possibly fix the scanning problem?

I think the stablity/network supervisor ability to track devices is enough 
justification for stable privacy addresses. Scanning is not so important. 
I know there are several new techniques - I am warning about the possible 
methods for several years in my presentations.
http://www2.garr.it/conf_05_slides/j_mohacsi-IPv6_sec.pdf

Best Regards,
 		Janos Mohacsi

---

From: Fernando Gont <[email-masked]>
Date: Sat, 21 Apr 2012 11:02:24 -0300

On 04/21/2012 06:10 AM, Mohacsi Janos wrote:
> The existing implementations. The most important factor of introduction
> of new standards to interoperate the existing ones. I think this should
> be documented in your  draft. 

Could you please clarify what you're referring to, specifically? --
i.e., this address generation mechanism is backwards-compatible.

> Furthermore there are several firewalls
> and monitoring tools which is generating warning in case of IEEE-derived
> address and MAC mismatch. This has to be investigated and documented in
> the draft.

You mean that updated implementations would automatically generate
addresses differently?

In this case, my take is that *updates* should probably not enable this
mechanism by default, or at the very least have a system toggle to turn
this feature off.

For new devices (i.e., off-the-box rather than software-updated), this
should probably be enabled by default.

> I think the stablity/network supervisor ability to track devices is
> enough justification for stable privacy addresses. 

Agreed. But someone might argue that you can achieve this with IPv6
addresses that embed IEEE-identifiers or
randomized-but-stable-across-networks IIDs... but these fail to address
other problems.

> Scanning is not so
> important. I know there are several new techniques - I am warning about
> the possible methods for several years in my presentations.

Will check your slides -- thanks for the pointer!

Cheers,