Subject: 6MAN Adoption call on draft-gont-6man-deprecate-eui64-based-addresses-00

From: Ole Troan <[email-masked]>
Date: Tue, 19 Nov 2013 11:07:28 +0100

All,

There was strong support to adopt this draft at the working group meeting in Vancouver.
This is an adoption call to confirm the result of the hum at the meeting.

Please provide a view with reasons as to whether the WG should adopt this or not.

This message starts a one week 6MAN Working Group call on adopting:

	Title           : Deprecating EUI-64 Based IPv6 Addresses
	Author(s)    : F. Gont, A. Cooper, D. Thaler, W. Liu
	Filename    : draft-gont-6man-deprecate-eui64-based-addresses-00
	Pages        : 5
	Date          : 2013-10-22

   http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00

The call ends on November 26th, 2013.

Regards,

Bob Hinden & Ole Trøan

---

From: Simon Perreault <[email-masked]>
Date: Tue, 19 Nov 2013 10:36:17 -0500

Support.

There is no good reason for leaking L2 addresses in L3 by default. We 
need to plug that leak.

Simon

Le 2013-11-19 05:07, Ole Troan a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 19 Nov 2013 11:18:20 -0800 (PST)

I agree that this draft should be adopted. I think it is important to increase device (and their owners'/users') privacy by preventing EUI-64 based IIDs being able to be used as a globally unique Internet identifier.

Regards,
Mark.

----- Original Message -----

> From: Ole Troan <[email-masked]>
> To: 6man WG <[email-masked]>
> Cc: 6man Chairs <[email-masked]>
> Sent: Tuesday, 19 November 2013 9:07 PM
> Subject: 6MAN Adoption call on draft-gont-6man-deprecate-eui64-based-addresses-00
> 
> All,
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2013 11:23:05 -0800

This work is important - we need to move the default away from using an 
EUI-64 as the IIDs.

    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Nov 2013 08:20:38 +1300

OK, as long as it's clear that the infamous MUST NOT
isn't set in stone and is likely to become SHOULD NOT.

Regards
   Brian Carpenter

On 19/11/2013 23:07, Ole Troan wrote:
> ------------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Nov 2013 14:52:11 +0900

I do not support this draft because I believe that MUST NOT a) causes an
implementation burden that is disproportionate to the advantages that the
draft brings, and b) causes currently valid use cases to be a violation of
the spec.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 19 Nov 2013 23:03:00 -0800

> On Nov 19, 2013, at 9:52 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> I do not support this draft because I believe that MUST NOT a) causes an implementation burden that is disproportionate to the advantages that the draft brings, and b) causes currently valid use cases to be a violation of the spec.

I find myself in agreement with Lorenzo.

As a specific example of b), the "MUST NOT" requirement in section 3 precludes the use of important 6LoWPAN header compression modes.  I support adoption of the document as a WG work item if "MUST NOT" is replaced by "SHOULD NOT".   

Additional text describing when it is appropriate to embed a hardware address in an IID may be developed, as necessary, during WG discussion of the document.

- Ralph

> 
> 
>> On Wed, Nov 20, 2013 at 4:20 AM, Brian E Carpenter <[email-masked]> wrote:

---

From: Jahangir Hossain <[email-masked]>
Date: Wed, 20 Nov 2013 13:23:08 +0600

Hi all;

I am quit new on IETF platform but based on my initial understanding match
with simon "this is not to good reason default L2 address in L3 by default"
.

I believe user security issue also should be come first but due this draft
we may also miss the advantage of rapid implementation of EUI-64 Based IPv6
Addresses which match with Lorenzo.

*So considering user security and privacy for future I support this draft .*

Regards  //  Jahangir Hossain
                  Bangladesh

--

---

From: Dan Luedtke <[email-masked]>
Date: Tue, 19 Nov 2013 18:05:53 +0100

I am supporting this because I experience a lot that clients use
EUI64-based addresses as an argument against wide deployment of IPv6.
No good reason for hardware addresses in IPv6 addresses has been
supplied yet.

On Tue, Nov 19, 2013 at 4:36 PM, Simon Perreault
<[email-masked]> wrote:
> Support.
>
> There is no good reason for leaking L2 addresses in L3 by default. We need
> to plug that leak.
>
> Simon
>

-- 
Dan Luedtke
http://www.danrl.de

---

From: Brian Haberman <[email-masked]>
Date: Wed, 20 Nov 2013 08:29:18 -0500

Just to point out a procedural point (and I am not picking on Ralph)...

On 11/20/13 2:03 AM, Ralph Droms wrote:
>> I do not support this draft because I believe that MUST NOT a)
>> causes an implementation burden that is disproportionate to the
>> advantages that the draft brings, and b) causes currently valid use
>> cases to be a violation of the spec.
> 
> As a specific example of b), the "MUST NOT" requirement in section 3
> precludes the use of important 6LoWPAN header compression modes.  I
> support adoption of the document as a WG work item if "MUST NOT" is
> replaced by "SHOULD NOT".
> 

I think this needs to be made clear for all participants.  *If* the
document is adopted, it must reflect the consensus of the WG before it
can be published.  Even though it says "MUST NOT" at this point, the WG
is free to change it to whatever it feels is appropriate.

Don't focus on the current "solution" text when considering your
position on adoption.  Rather, focus on whether you think the problem
being considered is important for the WG.

Regards,
Your friendly, neighborhood AD

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Nov 2013 10:03:56 -0500

> On Nov 20, 2013, at 8:29 AM, Brian Haberman <[email-masked]> wrote:
> 

Brian - point taken and I agree in general.  In this particular case, I feel strongly enough about the issue and the specific example I mentioned to raise it now.

When the chairs assess consensus for adoption, they are free to consider that your response has addressed my objection and that there is rough consensus for adoption,

Ralph (not feeling picked on at all)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 00:10:42 +0900

> is free to change it to whatever it feels is appropriate.

In Ralph's defence - this document has only one purpose, i.e., to deprecate
EUI-64-based IIDs. I don't know if we can respectably say, "we're adopting
this document to deprecate EUI-64-based IID, but we're not really
deprecating them, because they'll still be allowed"... :-)

---

From: Brian Haberman <[email-masked]>
Date: Wed, 20 Nov 2013 10:19:00 -0500

Hi Lorenzo,

> deprecating them, because they'll still be allowed"... :-)

I agree that the title, draft name, and current text may or may not
reflect the consensus of the WG.

The point I was trying to make is that the WG should decide if
EUI-64-based addresses are a problem that it wants to work on.  That
does not mean that this document has to be the basis of that work.

If this document is adopted, its contents will be driven by the
consensus of the WG and not the editors.  I got a few private e-mails
asking for clarification on what it means for the WG to adopt this draft
as it relates to any privacy problems with EUI-64-based IPv6 addresses.

Regards,
Brian

---

From: Scott Brim <[email-masked]>
Date: Wed, 20 Nov 2013 10:54:34 -0500

I thought we got informal consensus on SHOULD NOT a while ago.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 20 Nov 2013 11:09:49 -0500

Scott,

> I thought we got informal consensus on SHOULD NOT a while ago.

I thought so as well, but several of the adoption objections are tied to
the document still saying MUST NOT.

Brian

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 20 Nov 2013 20:30:53 +0100

> isn't set in stone and is likely to become SHOULD NOT.

with this change I would also support this document.

--- Roger J ---

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Nov 2013 20:28:56 +0000

> the document still saying MUST NOT.

Indeed. 

I would support SHOULD NOT.

Tim

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Nov 2013 19:58:16 -0800

Support.

Undecided if "SHOULD NOT" or "MUST NOT" but most inclined to a "SHOULD
NOT".

/as

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 14:21:25 +0900

> the document still saying MUST NOT.

If that's the case, then maybe we can make progress by asking Fernando to
upload a new draft with a one-word change from MUST to SHOULD and repeating
the adoption call on the mailing list?

---

From: David Farmer <[email-masked]>
Date: Thu, 21 Nov 2013 00:26:24 -0600

> Please provide a view with reasons as to whether the WG should adopt this or not.

I think this draft should be adopted by the working group.  I think 
requiring EUI-64 IIDs is no longer appropriate in many situation.

As for the MUST NOT or SHOULD NOT issue, I think we need an even more 
nuanced statement than has been discussed so far.  The primary reason 
for deprecating EUI-64 IIDs is to protect, or at least improve, the 
privacy of Internet users.

However, there are many device, and there will be many many more in the 
future, that there is no user that needs their privacy protected or the 
devices is not even intended to communicate across the public Internet. 
  In these situations ease of management is likely to be a far more 
important factor than privacy issues.  Having an IID based on a EUI-64 
or other identifier burned into the device, and print on its label, is 
likely to be very advantageous.

I'd like to discuss a somewhat related subject;  Given that link local 
addresses by definition are "not intended to communicate across the 
public Internet", I see little value in using any IID privacy schemes 
for link local addressing.  I find the use of privacy addresses for link 
local down right annoying, obfuscating the MAC address for link local 
only adds operational steps with no useful effect.  So, I would suggest 
that the real issue we are discussing is the use of EUI-64 IID with a 
Global Scope IPv6 prefix to form a Global Scope IPv6 address.

So, I believe the intent is not to deprecate EUI-64 IIDs.  The intent is 
to deprecate any requirement to use them when forming a Global Scope 
IPv6 address as is currently in RFC 4291.  Furthermore, we are 
recommending against their use for most devices that communicate across 
the public Internet, and in particular any device that can be associated 
with an individual user, or even a small group of users, when 
communicating across the public Internet.

Rewriting Brian's text, I would suggest something like;

Nodes that are intended to communicate across the public Internet SHOULD 
NOT employ IPv6 address generation schemes that embed the underlying 
hardware address in the Interface Identifier when forming Global Scope 
IPv6 addresses, and such schemes MUST NOT be enabled by default in such 
nodes.  Nodes that are not intended to communicate across the public 
Internet or that can not be associated with an individual user, or even 
a small group of users, MAY employ such schemes if desired.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Nov 2013 06:54:11 -0300

Lorenzo,

On 11/21/2013 02:21 AM, Lorenzo Colitti wrote:
> On Thu, Nov 21, 2013 at 1:09 AM, Brian Haberman
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> If that's the case, then maybe we can make progress by asking Fernando
> to upload a new draft with a one-word change from MUST to SHOULD and
> repeating the adoption call on the mailing list?

As noted by Brian, this document is not casted into stone. WG discussion
will drive any necessary changes to the document such that it reflects
wg consensus.

IMHO, and as noted by Brian, the high order bit is what the default IIDs
should look like (and what they should *not look like). The specific
wording is something to be agreed on by the wg (that's why 6man would
take this as a wg item). FWIW, me, I'm perfectly fine with the change
s/MUST NOT/SHOULD NOT/.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 18:59:24 +0900

On Thu, Nov 21, 2013 at 6:54 PM, Fernando Gont <[email-masked]>wrote:

> WG discussion will drive any necessary changes to the document such that
> it reflects wg consensus.
>

If the WG doesn't adopt it, then there won't be a lot of WG discussion. :-)

All I'm saying is that at the moment various people are objecting to
adoption because of this one issue. If you make that change, the objections
might go away.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Nov 2013 07:01:42 -0300

> I thought we got informal consensus on SHOULD NOT a while ago.

FWIW, this is one of the topics we brought up at the 6man meeting, and
there was some interesting discussion on the topic (e.g., noting that
smilar debate had arised when site-local addresses were deprecated, but
they were nevertheless deprecated).

As noted by Brian, the current contents of the I-Ds are not casted into
stone. And one of the first things the wg should decide after adoption
is this specific topic -- I could write an email summarizing the
arguments in favor of the current text, and the arguments in favor of
s/SHOULD NOT/MUST NOT/ such that the wg can make a decision.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 19:19:41 +0900

On Thu, Nov 21, 2013 at 7:01 PM, Fernando Gont <[email-masked]>wrote:

> I could write an email summarizing the arguments in favor of the current
> text, and the arguments in favor of s/SHOULD NOT/MUST NOT/ such that the
> wg can make a decision.
>

But the WG can only make a decision if the document is adopted as a WG
document?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Nov 2013 07:37:21 -0300

On 11/21/2013 07:19 AM, Lorenzo Colitti wrote:
> On Thu, Nov 21, 2013 at 7:01 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I could write an email summarizing the arguments in favor of the
>     current text, and the arguments in favor of s/SHOULD NOT/MUST NOT/
>     such that the wg can make a decision.
> 

Well, strictly speaking, an individual submission represents the view of
the co-authors, not that of a working group (maybe not even so, but
rather *rough consensus among the co-authors*).

Once a document becomes a wg item, it is meant to represent the view of
the *wg* rather than that of the co-authors or editors.

As noted both on- and off-list a number of times, me, I'm fine with
s/MUST NOT/SHOULD NOT/.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 19:49:54 +0900

> As noted both on- and off-list a number of times, me, I'm fine with

Fair enough. Then we'll just wait until the chairs state whether they see
consensus to adopt this document as is or not.

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Nov 2013 13:26:56 +0100

<nochair>

to give my reasons for the hum against during the meeting.

- privacy (and security) are policy. I think it is unlikely that the IETF is prescient enough to get this right for all cases
- I think draft-ietf-6man-ipv6-address-generation-privacy-00 is enough to explain the privacy considerations to give
  implementors and users enough background to make a qualified choice
- deprecating EUI-64 based interface-identifiers is way too strong, there are many cases where those are unproblematic to use

I do think there is a problem with the IPv6 over Foo documents (e.g. RFC2464) requiring the interface-ids based on EUI-64,
and leading to certification tests requiring implementations supporting it.

I would be much more supportive of a document that updated those documents stating that there are alternative
ways of generating the interface-id, and refer to the generation-privacy document for considerations.
it could have text stating that unless there are link-specific considerations, stable privacy addresses should be the default interface-id for addresses larger than link-local scope.

cheers,
Ole

</nochair>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Nov 2013 09:04:49 -0500

Le 2013-11-21 04:59, Lorenzo Colitti a écrit :
> at the moment various people are objecting to
> adoption because of this one issue [MUST vs SHOULD]

And the chairs will ignore those objections since it has been made clear 
that the WG will be free to decide on that after the doc is adopted. 
MUST vs SHOULD is irrelevant for the adoption call.

So far the only real objection I've seen is from Ole.

Simon

---

From: Ole Troan <[email-masked]>
Date: Thu, 21 Nov 2013 15:09:49 +0100

Simon,

> And the chairs will ignore those objections since it has been made clear that the WG will be free to decide on that after the doc is adopted. MUST vs SHOULD is irrelevant for the adoption call.

not speculating too much on what the chairs would do,
but I see no reason why they couldn't adopt a document under the premise
that certain changes were made prior to posting the revision-00 document.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 21 Nov 2013 23:11:10 +0900

On Thu, Nov 21, 2013 at 11:04 PM, Simon Perreault <
[email-masked]> wrote:

> that the WG will be free to decide on that after the doc is adopted. MUST
> vs SHOULD is irrelevant for the adoption call.
>

That's ridiculous. Of course the WG is free to decide on anything it wants
inside the WG. But that doesn't mean we should adopt a document that says
"we should deprecate the IPv6 header" just because "we can change the
document once we adopt it".

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Nov 2013 09:13:13 -0500

> that certain changes were made prior to posting the revision-00 document.

Of course. I was thinking more along the lines of "adopted under the 
condition that revision-00 contains SHOULD". I wouldn't see the point of 
an intermediate revision before adoption. But that's up to you, of course.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Nov 2013 09:16:16 -0500

Le 2013-11-21 09:11, Lorenzo Colitti a écrit :
> On Thu, Nov 21, 2013 at 11:04 PM, Simon Perreault
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     And the chairs will ignore those objections since it has been made
>     clear that the WG will be free to decide on that after the doc is
>     adopted. MUST vs SHOULD is irrelevant for the adoption call.
>
>
> That's ridiculous. Of course the WG is free to decide on anything it
> wants inside the WG. But that doesn't mean we should adopt a document
> that says "we should deprecate the IPv6 header" just because "we can
> change the document once we adopt it".

You're blowing what I said out of proportion. It's been made clear by 
our beloved AD that MUST vs SHOULD should not affect the adoption call. 
I'm just repeating the obvious.

Simon

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Nov 2013 09:22:28 -0500

On Nov 21, 2013, at 9:16 AM 11/21/13, Simon Perreault <[email-masked]> wrote:

> You're blowing what I said out of proportion. It's been made clear by our beloved AD that MUST vs SHOULD should not affect the adoption call. I'm just repeating the obvious.

I don't think Brian wrote exactly "MUST vs SHOULD should not affect the adoption call".  I think he wrote that s/MUST/SHOULD/ can be discussed by the WG after adoption, and those expressing an opinion on the adoption call should keep that fact in mind.

The chairs can then consider the objecting opinions and decide if those objections are addressed by Brian's observation, and that "rough consensus" can be declared in favor of adoption.

In my personal opinion the effect of s/MUST/SHOULD/ is important enough in its impact on existing standards like 6LoWPAN header compression that I object to publishing the document as a WG work item until the change is made.  The chairs will evaluate that objection as part of their determination of "rough consensus".

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Nov 2013 09:30:18 -0500

> - deprecating EUI-64 based interface-identifiers is way too strong, there are many cases where those are unproblematic to use

Ole - thanks for expressing these reasons.  In my opinion, all of these issues should be explored in conjunction with a simple change from MUST to SHOULD.  It might even be that SHOULD is too strong, and the community would be better served by a statement on the issues and recommendations derived from discussion of the issues.  Certainly, "SHOULD NOT" would need text expanding on situations in which IIDs baed on hardware addresses are not problematic, to explain when those IIDs are OK.

> and leading to certification tests requiring implementations supporting it.

6LoWPAN header compression and its derivatives are also specific examples of deployed IPv6-over-foo standards that must be considered.

> it could have text stating that unless there are link-specific considerations, stable privacy addresses should be the default interface-id for addresses larger than link-local scope.

+1

- Ralph

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Nov 2013 09:43:06 -0500

> In my personal opinion the effect of s/MUST/SHOULD/ is important enough in its impact on existing standards like 6LoWPAN header compression that I object to publishing the document as a WG work ite…

I fully agree. Thanks for writing that. That's what I would have wanted 
to write, but I'm not an eloquent man. Anyway, let's not try to find 
disagreement where there is none.

Simon

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 21 Nov 2013 07:03:48 -0800

> they were nevertheless deprecated).

Just to reinforce this point: there are more than the two options that have been debated in this thread ("Node MUST NOT employ …" and "Nodes SHOULD NOT employ …"). For example, it would be possible to make a different recommendation for new implementations than for existing implementations: "New implementations MUST NOT employ …" and "Existing implementations SHOULD NOT employ …." It seems like this kind of formulation could assuage some (but not all) of the concerns expressed in this thread. Thus to me this consensus call would make sense with the caveat that if the document gets adopted as a WG item, the normative recommendation(s) will be different/weaker than the current "Nodes MUST NOT employ," without pre-judging exactly what the recommendation(s) will be (subject to further WG discussion).

Alissa

---

From: t.petch <[email-masked]>
Date: Thu, 21 Nov 2013 14:18:27 +0000

---- Original Message -----
From: "Lorenzo Colitti" <[email-masked]>
To: "Simon Perreault" <[email-masked]>
Cc: "IETF IPv6 Mailing List" <[email-masked]>
Sent: Thursday, November 21, 2013 2:11 PM
> > And the chairs will ignore those objections since it has been made
clear
> > that the WG will be free to decide on that after the doc is adopted.
MUST
> That's ridiculous. Of course the WG is free to decide on anything it
wants
> document once we adopt it".

That is exactly what a WG often does, adopt a document that fits the
charter, is along the right lines and, the adopters trust, can be
hammered into the shape they want after adoption. Of course, not all
hammers are the same shape so some may be disapppointed.

On that basis, I say - Adopt.

Views on mould or shust come later.

Tom Petch

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Nov 2013 08:10:07 -0300

On 11/21/2013 07:49 AM, Lorenzo Colitti wrote:
> On Thu, Nov 21, 2013 at 7:37 PM, Fernando Gont <[email-masked]
> Fair enough. Then we'll just wait until the chairs state whether they
> see consensus to adopt this document as is or not. 

FWIW, adopting the document does not meant it is going to remain "as
is". i.e., the goal of adoption of for 6man to work on it and for the
document to review 6man's view, rather than just rubber-stamping what we
the co-authors of this document wrote. (i.e., my understanding is that
the call was for adoption of this document such that 6man works on it
(and apply whatever changes the wg thinks are warranted), rather than a
call for "publishing this document as is").

Thanks!

Best regards,

---

From: Tim Chown <[email-masked]>
Date: Thu, 21 Nov 2013 17:54:34 +0000

> Just to reinforce this point: there are more than the two options that have been debated in this thread ("Node MUST NOT employ …" and "Nodes SHOULD NOT employ …"). For example, it would be possible…

The SHOULD vs MUST isn't about existing and new implementations.

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 21 Nov 2013 17:56:12 +0000

On 21 Nov 2013, at 14:43, Simon Perreault <[email-masked]> wrote:

> I fully agree. Thanks for writing that. That's what I would have wanted to write, but I'm not an eloquent man. Anyway, let's not try to find disagreement where there is none.

Yes, well put.

Tim

---

From: Jean-Michel Combes <[email-masked]>
Date: Mon, 25 Nov 2013 18:13:34 +0100

Hi,

I don't support the adoption of this document as WG document in its current
format.

o "Nodes MUST NOT employ IPv6 address generation schemes that embed the
underlying hardware address in the Interface Identifier."
At first, as Ole said, privacy is policy and I don't see why IETF should
dictate its rules to a network admin. If I want to set up an IPv6 node, in
_my_ network, using SLAAC with EUI-64, it is my decision (BTW, maybe based
on my security policy).
IMHO,
- "MUST NOT" should be replaced by "SHOULD NOT"
- Title should be replaced by "Recommendations for generation of IPv6 IIDs"
- Intended status should be replaced by "Informational"

o "Nodes SHOULD implement and employ
[I-D.ietf-6man-stable-privacy-addresses] as the default scheme"
Why should I employ, by default, this method? Why not RFC4941 based one?
Why not CGA? Why not a proprietary one?
IMHO, this sentence should be replaced by "Nodes SHOULD implement and
employ alternative schemes providing a better privacy like
[I-D.ietf-6man-stable-privacy-addresses], [RFC4941] and [RFC3972]."

Best regards,

JMC.

2013/11/21 Ole Troan <[email-masked]>

> - privacy (and security) are policy. I think it is unlikely that the IETF
> is prescient enough to get this right for all cases
> - I think draft-ietf-6man-ipv6-address-generation-privacy-00 is enough to
> explain the privacy considerations to give
> - deprecating EUI-64 based interface-identifiers is way too strong, there
> are many cases where those are unproblematic to use
>
> I do think there is a problem with the IPv6 over Foo documents (e.g.
> RFC2464) requiring the interface-ids based on EUI-64,
> it could have text stating that unless there are link-specific
> considerations, stable privacy addresses should be the default interface-id
> for addresses larger than link-local scope.
>
> cheers,
> Ole
>
> </nochair>
>
>
> > All,
> >

---

From: Cutler James R <[email-masked]>
Date: Mon, 25 Nov 2013 12:22:57 -0500

On Nov 25, 2013, at 12:13 PM, Jean-Michel Combes <[email-masked]> wrote:

> Hi,
> 
> I don't support the adoption of this document as WG document in its current format.
> 
> o "Nodes MUST NOT employ IPv6 address generation schemes that embed the underlying hardware address in the Interface Identifier."
> At first, as Ole said, privacy is policy and I don't see why IETF should dictate its rules to a network admin. If I want to set up an IPv6 node, in _my_ network, using SLAAC with EUI-64, it is my decision (BTW, maybe based on my security policy).
> IMHO,  
> o "Nodes SHOULD implement and employ [I-D.ietf-6man-stable-privacy-addresses] as the default scheme"
> Why should I employ, by default, this method? Why not RFC4941 based one? Why not CGA? Why not a proprietary one?
> IMHO, this sentence should be replaced by "Nodes SHOULD implement and employ alternative schemes providing a better privacy like [I-D.ietf-6man-stable-privacy-addresses], [RFC4941] and [RFC3972]."
> 
> Best regards,
> 
> JMC.
> 

+1

Please keep business policy mandates out of RFCs.  It is always correct to recommend how to implement policies.

James R. Cutler
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Nov 2013 08:35:25 +1300

On 26/11/2013 06:22, Cutler James R wrote:
...
>> - Intended status should be replaced by "Informational"

That isn't possible, since this needs to formally update several
standards-track documents, even to replace a MUST by a SHOULD.

    Brian

---

From: Tina TSOU <[email-masked]>
Date: Wed, 27 Nov 2013 04:07:23 +0000

Dear all,

I support adopting it as a WG document.

The security and privacy implications of interface identifiers that embed hardware addresses have been known for a while, with implementations such as Microsoft deviating from the current RFCs to mitigate these issues. We should update the current RFCs to provide appropriate guidance.

Thank you,
Tina

On Nov 25, 2013, at 1:06 AM, "Ole Troan" <[email-masked]<mailto:[email-masked]>> wrote:

All,

Regards,

Bob Hinden & Ole Trøan

---

From: Greg Daley <[email-masked]>
Date: Wed, 27 Nov 2013 05:22:45 +0000

Dear WG chairs & 6man, 

I think that changing the _default_ behaviour away from EUI-64/MAC should be undertaken since we have a number of privacy preserving schemes which are feasible today without it.

I've noted and support most of the concerns of Jean-Michel, Ole, Ralph and others regarding operational flexibility.

There is a significant advantage in testing a platform with MAC based addressing, and I think that it is useful to retain the capability to use the addresses in some cases (especially for Link-Local, or test scenarios).

I do not think that the current draft revision reflects every case, and if it is adopted the treatment for EUI-64 would likely require:

1/ Discussion of EUI-64/MAC behaviour (were it retained in any flavour, with SHOULD NOT be used by default, MAY be used but SHOULD be configurable).
2/ Be clear that any of the (global) privacy preserving addressing schemes (4941, stable and CGA) are equivalent, but defaulting to one for minimum compliance when EUI-64/MAC not in use.
3/ Consideration for Link-Local addresses, and low powered communication schemes. i.e. does not apply to 6lowpan.

In sensor networks particularly, there may be no specific end-user tied to a device: so why would we preclude use of a functional address format for the sake of privacy?

So my response is that I have no objection to this being adopted as a working-group document, but I'm interested to make sure that the document doesn't go past WG stage without addressing some of the key issues above.

Greg Daley
[email-masked]
+61 401 772 770

From: ipv6 [mailto:[email-masked]] On Behalf Of Jean-Michel Combes
Sent: Tuesday, 26 November 2013 4:14 AM
To: Ole Troan
Cc: 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on draft-gont-6man-deprecate-eui64-based-addresses-00

Hi,

cheers,
Ole

</nochair>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 27 Nov 2013 11:56:46 -0500

I have reviewed the document in question along with the documents it 
updates and the 6man-ug draft. I support the adoption of this document, 
subject to the change from "MUST NOT" to "SHOULD NOT". It is clear that 
some network operators rely on EIU-64-based IPv6 addresses for 
administrative purposes, as a carry-over from IPv4, and do not at 
present wish to modify their procedures.

I would also recommend that the title, Abstract, and similar text in the 
body be changed from "Deprecating EUI-64 Based IPv6 Addresses" to 
"Deprecating Mandatory Use of EUI-64 Based IPv6 Addresses".

Tom Taylor

---

From: Brian Haberman <[email-masked]>
Date: Wed, 27 Nov 2013 12:04:41 -0500

Tom,

On 11/27/13 11:56 AM, Tom Taylor wrote:

> It is clear that

Could you elaborate on the above?  What procedures are they carrying
over from IPv4 WRT EUI-64-based addresses?

Regards,
Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 27 Nov 2013 11:29:38 -0600

> over from IPv4 WRT EUI-64-based addresses?
I think they use EUI's like 1,2, 3, to make IPv6 addresses look like IPv4
addresses.

Regards,

Behcet

---

From: "Leaf Yeh" <[email-masked]>
Date: Thu, 28 Nov 2013 01:41:57 +0800

The draft under discussion sounds like a draft only having one sentence,
while my reading is 
   ' Nodes SHOULD implement and employ 
   [I-D.ietf-6man-stable-privacy-addresses] as the default scheme for
   generating stable IPv6 addresses with SLAAC. '
in the case of end-user's GUA for the sake of privacy.

I am curious why this sentence (or the relevant topic) can't be included in
[I-D.ietf-6man-stable-privacy-addresses].

Best Regards,
Leaf

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Greg Daley
Sent: Wednesday, November 27, 2013 1:23 PM
To: 'Jean-Michel Combes'; Ole Troan
Cc: 6man Chairs; 6man WG
Subject: RE: 6MAN Adoption call on
draft-gont-6man-deprecate-eui64-based-addresses-00

Dear WG chairs & 6man, 

I think that changing the _default_ behaviour away from EUI-64/MAC should be
undertaken since we have a number of privacy preserving schemes which are
feasible today without it.

I've noted and support most of the concerns of Jean-Michel, Ole, Ralph and
others regarding operational flexibility.

There is a significant advantage in testing a platform with MAC based
addressing, and I think that it is useful to retain the capability to use
the addresses in some cases (especially for Link-Local, or test scenarios).

I do not think that the current draft revision reflects every case, and if
it is adopted the treatment for EUI-64 would likely require:

1/ Discussion of EUI-64/MAC behaviour (were it retained in any flavour, with
SHOULD NOT be used by default, MAY be used but SHOULD be configurable).
2/ Be clear that any of the (global) privacy preserving addressing schemes
(4941, stable and CGA) are equivalent, but defaulting to one for minimum
compliance when EUI-64/MAC not in use.
3/ Consideration for Link-Local addresses, and low powered communication
schemes. i.e. does not apply to 6lowpan.

In sensor networks particularly, there may be no specific end-user tied to a
device: so why would we preclude use of a functional address format for the
sake of privacy?

So my response is that I have no objection to this being adopted as a
working-group document, but I'm interested to make sure that the document
doesn't go past WG stage without addressing some of the key issues above.

Greg Daley
[email-masked]
+61 401 772 770

From: ipv6 [mailto:[email-masked]] On Behalf Of Jean-Michel Combes
Sent: Tuesday, 26 November 2013 4:14 AM
To: Ole Troan
Cc: 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on
draft-gont-6man-deprecate-eui64-based-addresses-00

Hi,

o "Nodes SHOULD implement and employ
[I-D.ietf-6man-stable-privacy-addresses] as the default scheme"
Why should I employ, by default, this method? Why not RFC4941 based one? Why
not CGA? Why not a proprietary one?
IMHO, this sentence should be replaced by "Nodes SHOULD implement and employ
alternative schemes providing a better privacy like
[I-D.ietf-6man-stable-privacy-addresses], [RFC4941] and [RFC3972]."
Best regards,
JMC.

2013/11/21 Ole Troan <[email-masked]> <nochair>

- privacy (and security) are policy. I think it is unlikely that the IETF is
prescient enough to get this right for all cases
- I think draft-ietf-6man-ipv6-address-generation-privacy-00 is enough to
explain the privacy considerations to give
  implementors and users enough background to make a qualified choice
- deprecating EUI-64 based interface-identifiers is way too strong, there
are many cases where those are unproblematic to use

I do think there is a problem with the IPv6 over Foo documents (e.g.
RFC2464) requiring the interface-ids based on EUI-64, and leading to
certification tests requiring implementations supporting it.

I would be much more supportive of a document that updated those documents
stating that there are alternative ways of generating the interface-id, and
refer to the generation-privacy document for considerations.
it could have text stating that unless there are link-specific
considerations, stable privacy addresses should be the default interface-id
for addresses larger than link-local scope.

cheers,
Ole

</nochair>

---

From: David Farmer <[email-masked]>
Date: Wed, 27 Nov 2013 11:43:02 -0600

On 11/27/13, 10:56 , Tom Taylor wrote:
...
> "Deprecating Mandatory Use of EUI-64 Based IPv6 Addresses".

+1 on the name change, this much more accurately reflects what I think 
is necessary.

And, I'll reiterate my support for WG adoption.

---

From: David Farmer <[email-masked]>
Date: Wed, 27 Nov 2013 12:43:35 -0600

> over from IPv4 WRT EUI-64-based addresses?

I'm not sure if this is what Tom was referring too, but here is one example.

Early in our IPv6 adoption we preferred EUI-64 addresses because we 
already tracked ports, MAC and IPv4 address associations for our entire 
network, and when EUI-64 addresses were used we didn't need any 
additional tracking.  We knew were all MAC addresses were We knew we 
needed to add IPv6 address tracking to our management system regardless, 
but we could initially use EUI-64s without any additional tracking.

I'll also note, that if there was a way for a network operator to 
control the IID type used for SLAAC we could have generally deployed 
IPv6 one to two years sooner.  Without such a control we had to add full 
IPv6 tracking before we could generally deploy IPv6 to our network.  We 
accomplished this before world IPv6 day, but we could have had IPv6 
generally deployed at least one year and maybe even two years before 
world IPv6 day if we could have ensured use of EUI-64 with SLAAC.  At 
the time DHCPv6 wasn't a practical solution, primarily because of MAC 
OSX's lack of support for DHCPv6 at the time.

So, while I support Privacy Addresses in general they create their own 
set of challenges and can complicate IPv6 deployment in many 
environments.  Frequently, network security requirements need rethinking 
when you use IPv6 privacy addresses.  I'm not saying this is a bad 
thing, but IPv6 deployment is frequently hampered or slowed by the 
amount of rethinking necessary.

Thanks

---

From: Tom Taylor <[email-masked]>
Date: Wed, 27 Nov 2013 17:40:54 -0500

Device tracking, I believe.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 27 Nov 2013 18:35:19 -0500

> I think they use EUI's like 1,2, 3, to make IPv6 addresses look like IPv4

But, those are not EUI-64-based addresses.  So, I am not sure how that
relates.

Regards,
Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Nov 2013 15:29:54 +0100

Le 27/11/2013 17:56, Tom Taylor a écrit :
[...]
> "Deprecating Mandatory Use of EUI-64 Based IPv6 Addresses".

I tend to agree with the suggestion about the title change, and also 
suggest filename change (currently 'deprecate-eui64-based-addresses').

Deprecating EUI-64-based addresses is too close to thinking
Deprecating EUI-64 addresses

EUI-64 is defined at IEEE.

Alex

(IETF's handle on EUI-64 is through RFC4291's relatively clear 'Modified 
EUI-64' term but also less clearly through RFC2464's same 'EUI-64' 
inserting the inner FFFE.  Also, RFC7042 seems to say that when the 
first 3 bytes are 00-00-5E (IANA is OUI) then the inner FFFE must be used.

IMHO, IETF could deprecate the mandatory FFFE in all IPv6 addresses on 
Ethernet-compatible links.  Personally I dont know why it is there 
everywhere.)

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 29 Nov 2013 18:49:34 -0800 (PST)

----- Original Message -----
> From: Tom Taylor <[email-masked]>
> To: Brian Haberman <[email-masked]>; [email-masked]
> Cc: 
> Sent: Thursday, 28 November 2013 9:40 AM

Some more detail would be useful.

Windows apparently abandoned EUI-64 based addresses quite a while ago, and my android phone uses temporary IPv6 addresses for outbound connections. So specifically basing some form of device tracking mechanism on the presence of EUI-64 format IIDs for those two common platforms is and has become quite ineffective.

I'm also confused by the comment about IPv4. There probably isn't enough host address space in commonly deployed IPv4 addresses (i.e., /24s or longer) to put any useful amount of an EUI-48 or similar sized layer 2 address in the IPv4 address, unless they're also deploying locally administered layer 2 addresses.

---

From: Tom Taylor <[email-masked]>
Date: Sat, 30 Nov 2013 12:15:42 -0500

David Farmer's note the other day made things clearer. To quote:

"Early in our IPv6 adoption we preferred EUI-64 addresses because we 
already tracked ports, MAC and IPv4 address associations for our entire 
network, and when EUI-64 addresses were used we didn't need any 
additional tracking.  We knew were all MAC addresses were We knew we 
needed to add IPv6 address tracking to our management system regardless, 
but we could initially use EUI-64s without any additional tracking."

Tom