Subject: Re: I-D Action: draft-gont-6man-deprecate-eui64-based-addresses-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Oct 2013 08:59:47 +1300

Unfortunately I feel that this is operationally unacceptable.

There are many (I suppose thousands) of sites that rely on MAC
addresses to manage their assets, and in many cases to trace
malicious users. It's certainly true that in theory, they can do
this by using ND or DHCPv6 logging, as today they use ARP cache
or DHCP logging to trace IPv4 users, and they may have to do this
anyway when some users implement some form of obscure IID generation.
But I just don't see site managers in general (and therefore vendors)
accepting this:

"Nodes MUST NOT employ IPv6 address generation schemes that embed the
 underlying hardware address in the Interface Identifier."

I would suggest that this might fly:

"Nodes SHOULD NOT employ IPv6 address generation schemes that embed the
 underlying hardware address in the Interface Identifier, and such schemes
 MUST NOT be enabled by default in any implementation."

Even that might prove unrealistic.

Incidentally, your case would be strengthened by referring to
draft-ietf-6man-ug, which makes it plain that the case for EUI64
is weaker than was originally thought.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Oct 2013 10:38:55 +1300

On 25/10/2013 09:58, John Day wrote:
> I couldn't agree with you more, Brian.   This is a really bad idea.
> 
>  "Government" should not be trying to protect us from ourselves! (Did I
> hear that on Fox News or was it Rush Limbaugh?)  This is not the proper
> kind of constraints for the IETF to be imposing. Information wants to be
> free!  If some operations manager wants to improve the ability of others
> to trace his traffic and spy on the people in his network, he should be
> allowed to do it.
> 
> As for tracing malicious users, that is a bit like the argument that if
> guns are outlawed only outlaws will have guns. Only in this case, if we
> don't outlaw it only the clueless will use MAC Addresses as endpoint
> ids, the "outlaws" aren't that dumb.  I really doubt they would use
> their own MAC addresses, or even to use the same one for very long.

In some contexts that doesn't matter. For example, at the university
where I currently work, a student can sit at any one of a few thousand
workstations - the security people need a way to track back malicious
traffic to a specific login session. The MAC address is definitely part
of the tracking process, even if the student is long gone.

    Brian

> Take care,
> John Day
> 
> At 8:59 AM +1300 10/25/13, Brian E Carpenter wrote:
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Oct 2013 23:01:28 +0100

> of the tracking process, even if the student is long gone.

But it's part of the tracking at the Ethernet layer, not the IP layer. There is no need at all to include the MAC address in the IP address for accountability purposes. 

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Oct 2013 12:57:47 +1300

> But it's part of the tracking at the Ethernet layer, not the IP layer. There is no need at all to include the MAC address in the IP address for accountability purposes. 

I agree that there will always be a way to do it without; IPv4
is the proof. But that isn't really my main concern; it's that
the suggested MUST NOT is just not realistic, so the resulting RFC
wouldn't be taken seriously outside the IETF.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 25 Oct 2013 01:01:49 +0100

> wouldn't be taken seriously outside the IETF.

With the MUST NOT, I agree.  Fernando's alternative should be attractive enough for vendors to move to over time, without this draft. Microsoft already do something similar, for similar reasons.  I think the carrot is tasty enough to avoid the need for a stick.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2013 21:07:15 -0300

On 10/24/2013 04:59 PM, Brian E Carpenter wrote:
> malicious users. 

Question:

Do you argue that they rely on
1) the MAC address being present in the IID, or,
2) the IPv6 address (and hence the IPv6 -> link layer address mapping)
   being stable?

If "1)", I wonder:
a) why (in the first place :-) )
b) how they manage Windows nodes (which do not employ IEEE-based IIDs)

If you meant "2)" above, please note that we're recommending
stable-privacy, which does produces "stable per network" addresses. For
instance, this scheme was acceptebable to Ron Broersma, that did a
number f presentation on why they needed to disable RFC4941 for
accountability etc.

> It's certainly true that in theory, they can do

You don't need to do this with stable-privacy. For instance, this is
exactly the reason for shich stable-privacy uses a hash rather than
random() at bootstrapping time.

> Even that might prove unrealistic.

Please see above. Besides, note that Microsoft has moved away froom
IEEE-based IDs for *years* now.

> is weaker than was originally thought.

Are you referring to MAC address duplication, or something else?

Thanks!

Cheers,
-- 
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: Thu, 24 Oct 2013 21:20:19 -0300

On 10/24/2013 08:57 PM, Brian E Carpenter wrote:
>> 
>> But it's part of the tracking at the Ethernet layer, not the IP
>> layer. There is no need at all to include the MAC address in the IP
>> address for accountability purposes.
> 
> I agree that there will always be a way to do it without; IPv4 is the
> proof. 

Please see my other port on the topic: do you really need/expect the MAC
address in the IID, or is it just that you expect the address to be stable?

> But that isn't really my main concern; it's that the suggested
> MUST NOT is just not realistic, so the resulting RFC wouldn't be
> taken seriously outside the IETF.

FWIW, I can certainly live with "SHOULD NOT". Your proposed change "...
SHOULD NOT...and MUST NOT enable it by default" sounds perfectly
reasonable to me.

What do other folks think?

Thanks!

Cheers,

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 25 Oct 2013 01:06:54 +0000

Agree with Tim and Brian. The reality is this has been widely used in so many implementations. We all know how difficult for these implementations to be changed. We have similar experience with IPv6 transition - to add IPv6 stack into any one implementations is not difficult. But changing all or most of these implementations takes years.

On another side, I do see Fernando's point eui64-based addresses should be used less and less. My suggestion is: instead of "deprecate" and "MUST NOT", use these softer word "Discourage" and "SHOULD NOT". Although these tough word may give out stronger message, people would choose to ignore the message when they feel it is not operable.

Sheng

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Tim Chown
>Sent: Friday, October 25, 2013 8:02 AM
>To: Brian E Carpenter
>Cc: 6man; John Day
>Subject: Re: I-D Action:
>draft-gont-6man-deprecate-eui64-based-addresses-00.txt
>
>
>>> But it's part of the tracking at the Ethernet layer, not the IP layer. There is
>no need at all to include the MAC address in the IP address for accountability
>purposes.
>>
>With the MUST NOT, I agree.  Fernando's alternative should be attractive
>enough for vendors to move to over time, without this draft. Microsoft
>already do something similar, for similar reasons.  I think the carrot is tasty
>enough to avoid the need for a stick.
>
>Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Oct 2013 14:58:18 +1300

> 2) the IPv6 address (and hence the IPv6 -> link layer address mapping)

I actually think that today, not too many sites have decided how
to handle this for IPv6, but the decisions whether to use SLAAC
or DHCPv6, and whether to allow RFC4941 addresses or insist
on Modified EUI-64, have to be taken as each site rolls out
IPv6. My guess is that large campus-style sites will not
allow RFC4941 because they don't have the logging to allow
a traceback to the user. So they'll either go for stateful
DHCPv6 if they can find working products for all platforms,
or stick to SLAAC/EUI-64. The reason is indeed the stable
mapping, not the fact that it's bit-for-bit mapping of
the MAC address.

The ability to deploy stable-privacy-addresses is years
in the future, but when it comes, it will probably be the best
solution for campus deployments and at that point, Modified EUI-64
could go away.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2013 22:38:08 -0300

Sheng,

On 10/24/2013 10:06 PM, Sheng Jiang wrote:
> Agree with Tim and Brian. The reality is this has been widely used in
> so many implementations. 

Isn't that the case with essentially any spec you update?

What we're trying to do here is what should happen when looking
forward... what devices should be shipping in the future.

> We all know how difficult for these
> implementations to be changed. We have similar experience with IPv6
> transition - to add IPv6 stack into any one implementations is not
> difficult. But changing all or most of these implementations takes
> years.

I don't see that as a problem. Better to get this sort of thing in at
this point in time, than later.

Besides, if there's anything to gain from the whole Snowden "thing", I
guess it is to gain the necessary momentum to apply changes that improve
security/privacy. Clearly, having a device-identifier such as an IEEE
address in the IPv6 IID does not help security/privacy.

> On another side, I do see Fernando's point eui64-based addresses
> should be used less and less. My suggestion is: instead of
> "deprecate" and "MUST NOT", use these softer word "Discourage" and
> "SHOULD NOT". Although these tough word may give out stronger
> message, people would choose to ignore the message when they feel it
> is not operable.

What I'm sensing both on-list and off-list is that folks are fine with
"SHOULD NOT". So it all looks like we'll be updating the I-D accordingly.

Regarding "discourage" vs. "deprecate": Me, I'd have no issues with such
a change although:
1) I'd still like to hear what other folks think about this
2) I guess IETF circles are familiar with what "deprecate" means(*), but
folks would wonder what "discourage" means (i.e., whether it has any
semantics other than the "colloquial" meaning).

(*) based on recent discussions, it seems that people tend to have
different views on the details of what "deprecation" means.

Thanks! (and please keep the feedback coming!)
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 25 Oct 2013 02:21:08 +0000

>forward... what devices should be shipping in the future.

My understanding is that published RFC would take influence on all current implementations, not only future devices. If IETF published a RFC deprecate eui64-based IPv6 addresses, it means all current implementations need to be modified too.

We could compare to oil-based cars. We should encourage use of electronic cars for environment protection. But we cannot enforce people to change their current oil-based car. The right message is one SHOULD buy electronic car when he change a new car. Even so, it should not be "MUST".

Sheng

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2013 23:43:29 -0300

On 10/24/2013 11:21 PM, Sheng Jiang wrote:
>>> Agree with Tim and Brian. The reality is this has been widely
>>> used in so many implementations.
>> 
> My understanding is that published RFC would take influence on all
> current implementations, not only future devices.

Current and future. For obvious reasons, there will always be a delay
between a spec is published and the spec is implemented.

> If IETF published a
> RFC deprecate eui64-based IPv6 addresses, it means all current
> implementations need to be modified too.

It means that if your implementation is meant to comply with the latest
standards, it needs to be updated.

But if your implementation predates the standard... it just predates the
standard.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2013 23:47:22 -0300

Brian,

On 10/24/2013 10:58 PM, Brian E Carpenter wrote:
[...]
> mapping, not the fact that it's bit-for-bit mapping of

That's the point: we're not deprecating the stable mappings. Just
improving them.

> solution for campus deployments and at that point, Modified EUI-64

I guess that varies from product to product. e.g., for some client OSes
this might not take that long.

FWIW, as long as MS Windows is concerned, Modified EUI 64 have been gone
for a while now -- they have mitigated at least address scannin attacks
at least since Vista.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Oct 2013 14:13:26 +0900

> Unfortunately I feel that this is operationally unacceptable.

It's also a major implementation burden. Take Linux as an example, Linux
has an in-kernel implementation of autoconf.
draft-ietf-6man-stable-privacy-addresses cannot, realistically, be
implemented in kernel space because it requires stable storage. Thus, if we
disallow EUI-64 addresses, we:

1. Add an extra barrier to IPv6 adoption because someone has to write a
userspace implementation (or more than one, due to licensing issues), and
OS distributors must include that implementation (which is always a harder
sell than something that's built in).
2. Increase the footprint of embedded devices that use Linux, because now
they need both the kernel implementation (which is extremely unlikely to be
removed due to backward compatibility concerns, no matter what the IETF
says), and the userspace implementation.

In case you think that Linux doesn't matter, bear in mind that a
substantial percentage of mobile devices (and probably the majority of
smartphones/tablets) are Linux-based.

What's the security threat here? Network activity correlation and location
tracking aren't an issue if the host implements RFC4941 temporary
addresses. As for scanning and exploitation, can those be avoided simply by
blocking incoming connections to ff:fe addresses?

Finally: some environments (e.g., enterprises) which already block incoming
scans might appreciate having predictable IPv6 addresses assigned to their
hosts, especially if they already have a database of all the MAC addresses
assigned to their devices. In that case, they can simply generate AAAA
records deterministically without having to run DHCP or dynamic DNS or
anything.

So I don't think this is a worthwhile tradeoff.

---

From: John Day <[email-masked]>
Date: Thu, 24 Oct 2013 16:58:37 -0400

"Government" should not be trying to protect us from ourselves! 
(Did I hear that on Fox News or was it Rush Limbaugh?)  This is not 
the proper kind of constraints for the IETF to be imposing. 
Information wants to be free!  If some operations manager wants to 
improve the ability of others to trace his traffic and spy on the 
people in his network, he should be allowed to do it.

As for tracing malicious users, that is a bit like the argument that 
if guns are outlawed only outlaws will have guns. Only in this case, 
if we don't outlaw it only the clueless will use MAC Addresses as 
endpoint ids, the "outlaws" aren't that dumb.  I really doubt they 
would use their own MAC addresses, or even to use the same one for 
very long.

Take care,
John Day

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2013 04:26:26 -0300

On 10/25/2013 02:13 AM, Lorenzo Colitti wrote:
> implemented in kernel space because it requires stable storage.

I assume that you're referring to stable storage for storing the secret key?

> Thus, if
> we disallow EUI-64 addresses, we:

There's a Linux implementation underway.

> userspace implementation (or more than one, due to licensing issues),
> and OS distributors must include that implementation (which is always a
> harder sell than something that's built in).

I don't follow. This document is not even being published *now* as an
RFC. It could easily take it one-two years before it is published as an RFC.

ANy update that you do to a protocol will take time to be implement.
What's the problem?

> 2. Increase the footprint of embedded devices that use Linux, because
> now they need both the kernel implementation (which is extremely
> unlikely to be removed due to backward compatibility concerns, no matter
> what the IETF says), and the userspace implementation.

If anything, in that case you could say that you have a valid reason to
not follow the advice in this document. (assuming we change the "MUST
NOT" to "SHOULD NOT" as suggested by other folks).

That said, I wonder what you have in mind when you say "embedded Linux",
since for many of such devices this would be a no-brainer. For example,
a CPE or TV contans and runs stuff that is orders of magnitude more
complex, bigger, etc., than this.

> smartphones/tablets) are Linux-based.

Linux does matter. As noted above, a Linux implementation is in the
works (and thiis is no coincidence).

> What's the security threat here?  Network activity correlation and
> location tracking aren't an issue if the host implements RFC4941
> temporary addresses. 

That's incorrect. Please check the I-D we wrote with Alissa and Dave.
(Short answer: even if you do RFC4941, IEEE-based addresses are there.
Hence you can still probe them).

> As for scanning and exploitation, can those be
> avoided simply by blocking incoming connections to ff:fe addresses?

Again, check the I-D we wrote with Alissa and Dave: you can still be
discovered even if you employ a local firewall. e.g., the local router
will respond to "ICMPv6 address unreachable" vs no response).

> Finally: some environments (e.g., enterprises) which already block
> incoming scans might appreciate having predictable IPv6 addresses
> assigned to their hosts, especially if they already have a database of
> all the MAC addresses assigned to their devices. In that case, they can
> simply generate AAAA records deterministically without having to run
> DHCP or dynamic DNS or anything.

And this scheme breaks if you replace a NIC, or if you use Windows, etc.
-- do you consider *this* to be operationally acceptable?

> So I don't think this is a worthwhile tradeoff.

There's really no tradeoff here, because there's no much to gain from
having the MAC address in the IID. The property that you care about is
address stability, rather than using a universaly unique identifier in
the IID.

The security and privacy implications of this have been understood for a
while (that's why Microsoft did sometihng else), and are discussed in
detail in draft-ietf-6man-ipv6-address-generation-privacy.

I'm kind of puzzled that in the light of the whole NSA/Snowden drama
we're still discussing why we should be concerned about having a
globally-unique identifier in the IID.

Such IIDs allow location tracking by any soul (;-) ) that can record an
IPv6 address. (besides the other implications discussed in Alissa's ID)

Thanks,

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Oct 2013 09:52:03 +0200

> "SHOULD NOT". So it all looks like we'll be updating the I-D accordingly.

What would make most sense to me is a recommendation saying that a host
should not generate EUI-64 based addresses *by default*. IMHO it's fine
for e.g. a sysadmin to turn it on on the machines it administers, but
there really is no reason for my mother's PC to have an EUI-64 based
address.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Oct 2013 09:54:01 +0200

Le 2013-10-25 04:21, Sheng Jiang a écrit :
> current implementations, not only future devices. If IETF published a

On all IPv6 OS stacks I know it would be a trivial change. Not an
issue IMHO.

Simon

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Oct 2013 17:26:16 +0900

On Fri, Oct 25, 2013 at 4:26 PM, Fernando Gont <[email-masked]>wrote:

> > Thus, if we disallow EUI-64 addresses, we:
>

> There's a Linux implementation underway.

Userspace or kernel space? What's the license? How many implementations
will be written, and will the kernel implementation be deleted?

> ANy update that you do to a protocol will take time to be implement.

That you just added an extra hoop to jump through to implement IPv6 in a
host OS. Potential implementers already often say that IPv6 is too complex.

> That said, I wonder what you have in mind when you say "embedded Linux", since
> for many of such devices this would be a no-brainer. For example, a CPE
> or TV contans and runs stuff that is orders of magnitude more complex,
> bigger, etc., than this.
>

And all those CPEs and TVs implement IPv6? If not, why not? Perhaps because
it's code they need to verify and turn on (and possibly write) that they
don't see a need for?

> will respond to "ICMPv6 address unreachable" vs no response).

Sure, but you can do this in the network. If you drop the packets before
they reach the local router, or on the local router itself, no unreachables
will be generated, and all the off-network attacks go away (assuming the
hosts use RFC4941 addresses).

> -- do you consider *this* to be operationally acceptable?

Believe it or not, not all enterprises use Windows. :-)

As for this breaking when you replace a NIC: it's not hard to keep the
database up to date. If you rely on said database of all MAC addresses for
something operationally relevant, then it will be kept up to date.

> address stability, rather than using a universaly unique identifier in

There's always a tradeoff between implementation complexity and benefit.

> globally-unique identifier in the IID.

I find a statement that users can protect themselves against national
security agencies by obscuring their IPv6 addresses a bit amusing.

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Fri, 25 Oct 2013 10:42:36 +0200

Hi!

> will be written, and will the kernel implementation be deleted?

I started the implementation and strive to get it accepted into the
upstream kernel. I started with a kernel implementation and currently
am hanging on the exact issue on how to handle the installtion generated
secret. For testing I just used the kernel command line but this is not
acceptable as a general solution.

Maybe a compile time switch would be acceptable for the transition to
this new scheme, I don't know and have to consult the NetworkManager
people how to proceed on this and to get them installed as soon as
possible. Unfortunately I had no time to do so, yet.

Greetings,

  Hannes

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2013 05:55:22 -0300

On 10/25/2013 05:26 AM, Lorenzo Colitti wrote:
> On Fri, Oct 25, 2013 at 4:26 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Userspace or kernel space?

Kernel space

> What's the license? 

Same as the kernel, I'd guess.

> How many implementations

what kernel implementation are you asking whether it'll be deleted?

> host OS. Potential implementers already often say that IPv6 is too complex.

C'mon, Lorenzo. :-) ND itself is way harder to implement than this.
And those who don't want to implement v6 will always find a reason to.

You don't help the current situation if you "buy" their excuses.

Put enough money on the table, and you'll see how v6 turns out to be
easy to implement. :-)

>     That said, I wonder what you have in mind when you say "embedded
>     Linux", since for many of such devices this would be a no-brainer.
>     For example, a CPE or TV contans and runs stuff that is orders of
>     magnitude more complex, bigger, etc., than this.
> 
> And all those CPEs and TVs implement IPv6? If not, why not? Perhaps
> because it's code they need to verify and turn on (and possibly write)
> that they don't see a need for?

Then it's not a footprint problem. Have them implement stable-privacy
rather than the old "embed the mac address", and that's it.

I don't expect the vendor to "see a need", because it's not their
security/privacy that is at stake, and because most folks that buy such
devices don't even know what an IP address is (so implementing this will
not buy them any more customers per-se).

> they reach the local router, or on the local router itself, no
> unreachables will be generated, and all the off-network attacks go away
> (assuming the hosts use RFC4941 addresses).

So.. this assumes:

1) all hosts implement RFC4941, and eneable it by default
2) the resulting addresses cannot include the fffe word
3) you have control of the border router, *and* that you can filter
based on a portion of the IPv6 address
4) you won't need incomming connections to your stable addresses

Do you really consider this a realistic assessment?

> database up to date. If you rely on said database of all MAC addresses
> for something operationally relevant, then it will be kept up to date.

You can do whatever you want, obviously. The question is. should you?

> security agencies by obscuring their IPv6 addresses a bit amusing.

That's not what my statement says. It rather says "why one should be
concerned about the NSA allegdly subverting a standardization process
when, being presented with something that has well-known security and
privacy implications, we prefer to ignore the problem".

You don't need the NSA to track you when you advertise yourself in the
very address that you're using.

The problem with the current scheme is that any idiot could leverage it
to track your location by just looking at your address.

PoC: scan6 tool from <http://www.si6networks.com/tools/ipv6toolkit>
("man scan6" for examples).

Thanks,

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 25 Oct 2013 12:35:24 +0200

Hi Brian,

> a traceback to the user. So they'll either go for stateful

Counter-example:
Here at KIT we have a larger campus site with several thousand
users and more than 500 wireless access points. IPv6 w/ SLAAC is on
in the 802.1x protected network and AFAIK they do some logging
to being able to match IPv6 and MAC address in case of abuse etc.
If interested I could try to get the detailed numbers..

BR,
 Roland

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Oct 2013 19:43:54 +0900

> acceptable as a general solution.

Would a sysctl / file in /proc/net/ipv6/conf/... work?

> possible. Unfortunately I had no time to do so, yet.

NetworkManager is not used on most Linux hosts though, right? It's used on
distros but not on embedded devices.

---

From: George Mitchell <[email-masked]>
Date: Fri, 25 Oct 2013 07:08:41 -0400

> Thanks! (and please keep the feedback coming!)
I've been using IPv6 on my home network since the KAME patches for
FreeBSD came out (mumble) years ago.  It assigned link-local addresses
for the interfaces that were based on the MAC address, but I never found
them to be of any use.  The addresses I put in my local DNS were static
and arbitrary (prefix::1, prefix::2, prefix::3, etc.), as my network was
too small to need automatic configuration.  Obviously I wasn't the user
being targeted by the specification that required the MAC address/EUI to
be part of the address.  Even so, it seemed silly to make the use of the
hardware identifier mandatory.  And my network has functioned with no
difficulty for many years even though I disobeyed the "requirement."
-- George

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Fri, 25 Oct 2013 13:19:05 +0200

> Would a sysctl / file in /proc/net/ipv6/conf/... work?

Yes, I guess so. I thought about a netlink api which should give a bit more
flexibility to protect users from accidentally rewriting their secrets and
thus installing new generated addresses.

Some simple user interface for this api could be implemented in iproute2
and NetworkManager could be just another user of this.

> distros but not on embedded devices.

That's correct.

We must also have those addresses up before NetworkManager starts so
that services can bind() to those IPs while boot-up when receiving
RA information. I already thought about seeding this secret from
the initramfs (or we handle the file with the secret as a firmware and
request it from the kernel in-time).

A kernel parameter could then be used to switch off the "old style"
addresses.

Greetings,

  Hannes

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 25 Oct 2013 20:39:13 +0900

> and NetworkManager could be just another user of this.

Seems a bit complicated, though? You'd have to define the netlink
attribute, extension, teach iproute about it, and so on. Also, the IPv6
stack already extensively uses sysctls for configuration.

> request it from the kernel in-time).

Wouldn't it be natural to do this in the distro startup scripts, though?
That way there'd be no dependency on NetworkManager, and it would be
available before any network interfaces were brought up. At its simplest,
the secret could live in an appropriately-protected file on disk; on first
boot the script would seed it with randomness, and at every boot it would
write it into the sysctl. For booting from initramfs, you could simply use
old-style autoconf addresses.

> A kernel parameter could then be used to switch off the "old style"

/proc/sys/net/ipv6/conf/{eth0,wlan0,...,default}/autoconf_eui64 ?

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Fri, 25 Oct 2013 13:56:50 +0200

Hello!

> stack already extensively uses sysctls for configuration.

I have not yet thought that much about the interface. It well may be that
netlink is too complicated for that job.

> /proc/sys/net/ipv6/conf/{eth0,wlan0,...,default}/autoconf_eui64 ?

This is racy as we can only toggle this from user-space. If we want to
completly abandon eui-64 generated addresses we have to let the kernel know
before that. We enter user-space with LL addresses already installed and may
race with RA announcements.

Also the /proc/sys/net/ipv6/conf/<interface> directories are inherently
racy and people have trouble understanding how the /all/ or /default/
switches overload the interface specific directories.

But it could be a nice addition for testing, yes. But I dislike them as
the main configuration method for that.

Greetings,

  Hannes

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 25 Oct 2013 18:51:47 +0200

> Unfortunately I feel that this is operationally unacceptable.

I agree.

Not only operationally it may prove difficult to upgrade everything from
RFC2464, but all the IPv6-over-foo specs of future deployment may need
to accept it as well.

E.g. will this 48bit prohibition also include prohibiting the 'short'
16bit of 802.15.4?  Or is that less of risk given it's a shorter address
and thus less unique?

(in detail:
it cites [RFC2464] Ethernet, [RFC2467] FDDI, and [RFC2470] Token Ring,
but would one go ammend also other IPv6 over foo documents such as:
RFC2492 ATM,
RFC4944 802.15.4,
RFC5072 PPP using Ethernet hardware IDs,
RFC5692 802.16,
draft-ietf-6lowpan-btle-12,
draft-ietf-6man-6lobac-01,
draft-brandt-6man-lowpanz-02,
IPv6-over-USB unspecified, but using hardware IDs.

and why not the methods of forming IPv6 addresses containing an IPv4 
address which may be related in other ways to other privacy aspects like 
geographical localization.)

Alex

> this by using ND or DHCPv6 logging, as today they use ARP cache or
> DHCP logging to trace IPv4 users, and they may have to do this anyway
> when some users implement some form of obscure IID generation. But I
> just don't see site managers in general (and therefore vendors)
> accepting this:
>
> "Nodes SHOULD NOT employ IPv6 address generation schemes that embed
> the underlying hardware address in the Interface Identifier, and
> such schemes MUST NOT be enabled by default in any implementation."
>
> draft-ietf-6man-ug, which makes it plain that the case for EUI64 is
> weaker than was originally thought.
>
> Brian
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 25 Oct 2013 19:04:08 +0200

Le 25/10/2013 04:21, Sheng Jiang a écrit :
> current implementations, not only future devices. If IETF published
> a RFC deprecate eui64-based IPv6 addresses, it means all current
> We could compare to oil-based cars. We should encourage use of
> electronic cars for environment protection. But we cannot enforce
> people to change their current oil-based car. The right message is
> one SHOULD buy electronic car when he change a new car. Even so, it
> should not be "MUST".

I agree and I'd go even further with the comparison.

The initial thought is to encourage people to change their oil-based
cars.  Then we'd advise to do so just when buying a new car.  And wiser
advice is to think twice before doing it, because it may not be that
helpful as one initially thought (well-to-wheel analysis suggestions may
surprise).

Alex

>
> Sheng
>
>>> We all know how difficult for these implementations to be
>>> changed. We have similar experience with IPv6 transition - to
>>> add IPv6 stack into any one implementations is not difficult.
>>> But changing all or most of these implementations takes years.
>>
>> I don't see that as a problem. Better to get this sort of thing in
>> at this point in time, than later.
>>
>> Besides, if there's anything to gain from the whole Snowden
>> "thing", I guess it is to gain the necessary momentum to apply
>> changes that improve security/privacy. Clearly, having a
>> device-identifier such as an IEEE address in the IPv6 IID does not
>> help security/privacy.
>>
>>
>>> "deprecate" and "MUST NOT", use these softer word "Discourage"
>>> and "SHOULD NOT". Although these tough word may give out stronger
>>> message, people would choose to ignore the message when they feel
>>> it is not operable.
>>
>> What I'm sensing both on-list and off-list is that folks are fine
>> with "SHOULD NOT". So it all looks like we'll be updating the I-D
>> accordingly.
>>
>> Regarding "discourage" vs. "deprecate": Me, I'd have no issues
>> with such a change although: 1) I'd still like to hear what other
>> folks think about this 2) I guess IETF circles are familiar with
>> what "deprecate" means(*), but folks would wonder what
>> "discourage" means (i.e., whether it has any semantics other than
>> the "colloquial" meaning).
>>
>> Thanks! (and please keep the feedback coming!) -- 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, 25 Oct 2013 14:36:15 -0300

> RFC2464, but all the IPv6-over-foo specs of future deployment may need

Huh?

Can you elaborate how this affects deployment?

Are you suggesting that we ignore well-known problems?

Are you suggesting that we stick to a feature that allows simple
location tracking?

Or.. maybe you're fine with people deploying IPv6 NAT and that kind of
middle-box to mitigate this sort of thing?

An old-timer (who preferred to remain anonymous) just sent me this off-list:

"You know, the reaction to this personifies what is wrong with the IETF.

Here is a practice that we have known was a bad idea for 30 years and a)
they made the mistake anyway, and b) they won't fix it. "

> geographical localization.)

Those methods:

* Do not result from SLAAC (hence they are out of the scope of this
document), and/or,

* Are employed by automatic tunneling and have no alternative.

Thanks,

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Fri, 25 Oct 2013 22:06:30 +0200

> That's the point: we're not deprecating the stable mappings. Just

Are these mappings really stable?

Linux based virtualization does often create interfaces, thus installing
a the addresses and then change the mac address to a stable one from
the virtualization managment engine. So a mapping MAC <=> IPv6 address does
not work very well there.

Greetings,

  Hannes

---

From: Tim Chown <[email-masked]>
Date: Fri, 25 Oct 2013 21:06:32 +0100

On 25 Oct 2013, at 02:58, Brian E Carpenter <[email-masked]> wrote:

> a traceback to the user.

This is not true.  There are open source packages that allow you to harvest switch port, MACs, IPs etc, dual-stack.  OK, so the db gets big if RFC4941 refresh is rapid, but it works.

How do you prevent 4941 anyway on campus BYOD, if you allow EUI-64?  What product does that?

The approach has to be expect anything, and monitor/log it.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Oct 2013 13:54:58 +1300

> This is not true.  There are open source packages that allow you to harvest switch port, MACs, IPs etc, dual-stack.  OK, so the db gets big if RFC4941 refresh is rapid, but it works.

If you happen to run such a package. But lots of sites don't, and maybe don't want
to. I don't see why the IETF has the right to dictate here. That's why
I prefer SHOULD NOT.

> How do you prevent 4941 anyway on campus BYOD, if you allow EUI-64?  What product does that?

You probably can't. Actually that's why some campuses have separate
networks for BYOD, where other restrictions apply.

> The approach has to be expect anything, and monitor/log it.

Certainly, on BYOD.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2013 22:10:50 -0300

Hi, Brian,

On 10/25/2013 09:54 PM, Brian E Carpenter wrote:
>>>> Do you argue that they rely on 1) the MAC address being present
>>>> in the IID, or, 2) the IPv6 address (and hence the IPv6 -> link
>>>> layer address mapping) being stable?
>>> or DHCPv6, and whether to allow RFC4941 addresses or insist on
>>> Modified EUI-64, have to be taken as each site rolls out IPv6. My
>>> guess is that large campus-style sites will not allow RFC4941
>>> because they don't have the logging to allow a traceback to the
>>> user.
>> 
>> This is not true.  There are open source packages that allow you to
>> harvest switch port, MACs, IPs etc, dual-stack.  OK, so the db gets
>> big if RFC4941 refresh is rapid, but it works.
> 
> If you happen to run such a package. But lots of sites don't, and
> maybe don't want to. I don't see why the IETF has the right to
> dictate here. That's why I prefer SHOULD NOT.

I'm not sure I follow. What's the implication of having this logging
feature (or not) on this I-D?

You only need such loggig feature if the IPv6/MAC mapping changes. This
I-D is simply about stable addresses... so such discussion is orthogonal.

Am I missing something?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Oct 2013 14:51:54 +1300

> I-D is simply about stable addresses... so such discussion is orthogonal.

It's about operations people (and products) that currently rely on EUI-64.
I don't think anyone's arguing that we can't move away from EUI-64 over time.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Sat, 26 Oct 2013 09:10:36 +0100

> to. I don't see why the IETF has the right to dictate here. That's why

And lots of sites don’t run IPv6, yet alone IPv6 SLAAC/RFC4941. 

But as they deploy IPv6, they have a timely opportunity to review requirements on their management and monitoring platforms, many of which will have poor IPv6 support anyway. Customers should be asking their vendors if/how their products support IPv6 address tracking/accountability.  Even if parts of the campus are managed and relatively locked down (and thus may not use 4941 through it being disabled on the host), the same platform is likely to be used campus-wide, so support for tracking should be sought.

> You probably can’t.

Can savi help here?

> Actually that's why some campuses have separate

Sure, on managed administrative subnets the network and the hosts can be relatively locked down. But if we want to give our students/academics increased privacy their desktops, and the eduroam wireless where the BYODs are, should run 4941.  The recent NSA stuff will only increase the desire of university users to have greater privacy (perceived or real).

> It's about operations people (and products) that currently rely on EUI-64.

What are those products?  Do we have examples of where this reliance lies?

> I don't think anyone's arguing that we can't move away from EUI-64 over time.

Indeed.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Sun, 27 Oct 2013 10:45:38 -0300

> I don't think anyone's arguing that we can't move away from EUI-64 over time.

1) What's the basis for that reliance? (i.e., what for?)

2) What's the usefulness of that, if, e.g. Windows doesn't employ
Modified EUI-64?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Oct 2013 08:22:27 +1300

> 1) What's the basis for that reliance? (i.e., what for?)

Identifying hosts (well, NICs) without needing the ND cache.

> 2) What's the usefulness of that, if, e.g. Windows doesn't employ

None. I'm rather shocked that MS decided to unilaterally dump the
requirement in RFC 4291. (I assume that there's a a 'netsh int ipv6'
command to reinstate EUI-64; if not, it's even more shocking.)

As it happens, draft-ietf-6man-ug-04 removes that requirement, and
that's the right thing to do. But if a site wants to operate
that way, it isn't the IETF's business (or Microsoft's) to stop
them.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 11:32:45 +0100

Le 25/10/2013 19:36, Fernando Gont a écrit :
>> Not only operationally it may prove difficult to upgrade everything
>> from RFC2464, but all the IPv6-over-foo specs of future deployment
>> may need to accept it as well.
>
> Huh?
>

If this spec draft-gont-6man-deprecate-eui64-based-addresses says that
IIDs derived from hardware identifiers are forbidden, and other specs
say that they are mandatory, then there may be a problem.

> Are you suggesting that we ignore well-known problems?

No.

> Are you suggesting that we stick to a feature that allows simple

Location tracking, as well as other similar characteristics, are bad
when looked at from a prism, and are good when looked at from somewhere
else.

> Or.. maybe you're fine with people deploying IPv6 NAT and that kind
> of middle-box to mitigate this sort of thing?

Yes and no.

IPv6 NAT and NPT are there to be used, and are needed.

No, in that they are needed because more than just its indirect privacy
features.  They are needed also because DHCPv6-PD is not deployed by
cellular operators, and also because SLAAC over Ethernet works with
prefixes length smaller or equal 64.

If you make IIDs which are independent of the hardware ID you'd still
need to make cellular operators deploy DHCPv6-PD and make SLAAC/Ethernet
with longer than 64 prefixes.  Otherwise IPv6 NAT and NPT are still needed.

> An old-timer (who preferred to remain anonymous) just sent me this

Ok.

Alex