Subject: draft-ietf-6man-default-iids v 09

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Tue, 26 Jan 2016 12:24:10 +0100

I have read version 09 and support the intent of this draft.

I have some editorial suggestions, and find the current formulation of 
the requirements unnecessarily onerous.

Suggested textual changes below:

s/As a result of the aforementioned issues, this document recommends the 
implementation of an alternative scheme ([RFC7217]) as the default 
stable IID generation scheme for SLAAC, such that the aforementioned 
issues are mitigated./To mitigate the aforementioned issues, this 
document RECOMMENDS "A Method for Generating Semantically Opaque 
Interface Identifiers with IPv6 Stateless Address Autoconfiguration 
(SLAAC)" [RFC7217] as the default method for generating IPv6 Interface 
Identifiers to be used with IPv6 Stateless Address Autoconfiguration 
(SLAAC)./

/Generation of IPv6 Interface Identifiers with SLAAC/

IMVHO The title of Section 3 has potential to cause confusion.

How about:

s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for 
Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/

In the requirements, nothing really immediately breaks if the algorithm 
is non-compliant, so a SHOULD is more appropriate IMHO
I also find it problematic to specify how to test compliance with a "MUST".
This proposed standard as currently written might also make existing 
implementations non-compliant with existing IETF standards, and thus 
create a major commercial headache.

suggest:

s/Link layers MUST define a mechanism /Standards defining how IPv6 
packets are transmitted over a specific link layer technology SHOULD 
define a mechanism /

s/The resulting Interface Identifiers remain stable/The resulting 
Interface Identifiers SHOULD remain stable/

s/The resulting Interface Identifiers must change when addresses are 
configured for different prefixes./The resulting Interface Identifiers 
SHOULD change when addresses are configured for different prefixes./

s/it must be difficult for an outside entity to tell whether the 
addresses have been generated by the same host/it SHOULD be difficult 
for an outside entity to tell whether the addresses have been generated 
by the same host/

s/It must be difficult for an outside entity to predict the Interface 
Identifiers that will be generated by the algorithm,/It SHOULD be 
difficult for an outside entity to predict the Interface Identifiers 
that will be generated by the algorithm,/

s/The resulting Interface Identifiers must be semantically opaque./The 
resulting Interface Identifiers SHOULD be semantically opaque./

Section 5 is out of scope IMHO and should be removed entirely. If admins 
manually assign static addresses they're on their own.

s/how each of the RFCs /how each of the following existing RFCs /

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jan 2016 08:41:36 +1300

> I have read version 09 and support the intent of this draft.

Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find
any obvious errors, but I think everybody should have a look at those.

> I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.

I disagree. I think stating the requirements explicitly is useful.

However, I do have one question. Should we add a note that use of the privacy
extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking
is more important than stable addresses?

...
> Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.

I disagree that it's out of scope. On the contrary, giving this warning is very much
in scope - if someone is reading this document, their likely default solution is
manual addressing. I know such people; they're across the road in IT Services.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Jan 2016 17:35:06 -0300

Hi, Brian,

> I disagree. I think stating the requirements explicitly is useful.

FWIW, we ended up clarifying the requirements. Me, I'd be fine with just
recommending RFC7217 without spelling out the requirements.

> is more important than stable addresses?

I'd consider that to be out-of-scope, and/or part of a more general
document.

This one just focuses on stable addresses, and spans all versions of
those -- I'd been fine with just having this doc focus on the stable
slaac addresses.

> manual addressing. I know such people; they're across the road in IT Services.

As currently entitled, the document provides recommendations on stable
addresses, and manually-configured addresses is just one of those -- so
the recommendation would be in scope.

As noted above, I'd been equally happy to have the document just focus
on the stable slaac addressess... but the wg thought that it was better
to tackle all stable addresses.

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jan 2016 13:46:05 +1300

On 27/01/2016 09:35, Fernando Gont wrote:
...
> I'd consider that to be out-of-scope, and/or part of a more general

Fine. But assume that someone is trying to figure what to implement in
their stack. I think this document needs to tell them that there are
other possibilities.

> those -- I'd been fine with just having this doc focus on the stable

Here's what I've just noticed. Although the word "stable" is in the title,
it isn't mentioned in the Abstract and it first appears in the text in quotes,
as if it doesn't really mean what it seems to mean.

I think this needs a few small changes to make it perfect:

In the Abstract, 2nd-last line,
s/Interface Identifiers/stable Interface Identifiers/

In the Introduction,

OLD
   [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
   IPv6 [RFC2460], which typically results in hosts configuring one or
   more "stable" addresses composed of a network prefix advertised by a
   local router, and an Interface Identifier (IID) [RFC4291] that
   typically embeds a link-layer address (e.g., an IEEE LAN MAC
   address).

NEW
   [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
   IPv6 [RFC2460], which typically results in hosts configuring one or
   more stable addresses composed of a network prefix advertised by a
   local router, and an Interface Identifier (IID) [RFC4291] that
   typically embeds a link-layer address (e.g., an IEEE LAN MAC
   address). Where stable addresses are not desirable, privacy
   extensions [RFC4941] allow for frequently changing IIDs.
   The scope of the present document is for cases where stable
   IIDs are required.

Rgds
   Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 26 Jan 2016 19:27:49 -0600

On 1/26/16 18:46 , Brian E Carpenter wrote:
...
>     The scope of the present document is for cases where stable

I like these changes, but I think the two sentence added should be a 
separate paragraph.

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: "weigengyu" <[email-masked]>
Date: Wed, 27 Jan 2016 14:40:25 +0800

Hi Brian and all,

I like it too, it also answers what I concern.
And I agree david's suggestion, i.e. the two sentence added should be a 
separate paragraph."

>    Where stable addresses are not desirable, privacy extensions [RFC4941] 
> allow for frequently changing IIDs.
> The scope of the present document is for cases where stable IIDs are 
> required.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: David Farmer
Sent: Wednesday, January 27, 2016 9:27 AM
To: Brian E Carpenter ; Fernando Gont ; Ray Hunter (v6ops) ; 
[email-masked]
Cc: 6man
Subject: Re: draft-ietf-6man-default-iids v 09

Thanks

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

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 27 Jan 2016 08:38:35 +0100

> Brian E Carpenter <mailto:[email-masked]>
> 26 Jan 2016 20:41
I gave plenty of feedback to Fernando whilst he wrote RFC7217, so I know 
the content and background.

If I filter through this document I can extract 4 threads of what it 
intends to do:

1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 
format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)

2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 
Interface Identifiers to be used with IPv6 Stateless Address 
Autoconfiguration (SLAAC)

3. Document how 1 & 2 impacts text of existing standards

4. When specifying how to transport IPv6 over various link media 
(IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be 
mandated, but these alternatives or the substitute MUST meet certain 
requirements (which are met be RFC7217).

Now those are all things the I can support.

But the current text doesn't do that: it updates existing standards 
without providing a pathway for existing implementations using Interface 
Identifiers constructed in Modified EUI-64 format to remain compliant 
with IETF Standards Track RFCs.

To me, slightly restructuring the text around the 4 intentions would 
make the intentions clearer, and avoid unintended consequences, like 
making existing implementations non-compliant over an issue that quite 
frankly doesn't actually break any functionality.
> Ray Hunter (v6ops) <mailto:[email-masked]>
> 26 Jan 2016 12:24
> s/As a result of the aforementioned issues, this document recommends 
> the implementation of an alternative scheme ([RFC7217]) as the default 
> In the requirements, nothing really immediately breaks if the 
> algorithm is non-compliant, so a SHOULD is more appropriate IMHO
> for an outside entity to tell whether the addresses have been 
> generated by the same host/
>
> Section 5 is out of scope IMHO and should be removed entirely. If 
> admins manually assign static addresses they're on their own.
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Jan 2016 20:04:02 +1100

> is more important than stable addresses?

I agree with providing a brief reference to this. There are now many
IPv6 related RFCs, so reference to related ones can only make finding
IPv6 information easier.

> manual addressing. I know such people; they're across the road in IT Services.

I think I may have suggested including some text about good
static/manual addresses. I think it is useful to include just for
completeness as SLAAC, DHCPv6 and manual addresses are all both
address generation and address configuration methods, and the IIDs
generated and configured using any of them should all have good
privacy properties.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2016 05:14:12 -0300

Hi, Brian,

> their stack. I think this document needs to tell them that there are

There are a couple of things to note here:

1) RFC4941 is implemented along with stable addresses. So the work we're
doing here is pretty much orthogonal to temp addresses. It *is* the
case, though, that at times RFC7217 may be good enough to an extent that
RFC4941 may be deemed as unnecessary (in some scenarios). But, again,
that's pretty much orthogonal.

2) If anything, I guess one might include non-normative text in the
security considerations section. But my take is that we started tackling
the well-known problem of stable SLAAC IIDs, then we augmented the wok
to tackle all stable addresses, and I'm of the idea that eventually, the
more onerous the project, the less feasible it is.

One could, for instance, envision that a whole document could try to
address the problem of tracking/correlation, in which addressing
(including recommendations regarding whether to enable RFC4941 or not)
would be one of the items...

>    The scope of the present document is for cases where stable

I'm 100% in agreement with you. Unless anyone argues against, I will
apply the suggested change.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2016 06:29:35 -0300

Hi, Ray,

On 01/27/2016 04:38 AM, Ray Hunter (v6ops) wrote:
[....]
> format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)

Strictly speaking, we simply recommend against Modified EUI64 as a
default IID generation scheme.

> requirements (which are met be RFC7217).

Actually, what we tried to do is to spell out the properties that we
want in the algorithm that is the default for IID generation with slaac.

That, I could be equally as happy with just recommending RFC7217.

> with IETF Standards Track RFCs.

Not sure what you mean.

Do you mean that:

a) It is not clear in the document that each ipv6-over-foo should now do
rfc7217 rather than modified eui64, or,

b) That i we mandate rfc7217 in all of them, implementations that
currently do modified eui64 would now become non-compliant?

> frankly doesn't actually break any functionality.

Well, one could argue that:

a) right now we do have a requirement to do modified eui-64, which does
have negative security implications

b) there are a number of the standards that concern security, without
necessarily affecting interoperability. And particularly in the light of
all the snowden thing, recommending something that does not allow
trivial tracking seems to be warranted.

That said, what would you propose as a way forward? Or, put another way,
what the specific bit that concerns you?

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2016 06:38:57 -0300

Hi, Ray,

> Identifiers to be used with IPv6 Stateless Address Autoconfiguration

mm... this was in the Intro? -- I wouldn't use normative language there....

> Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/

This seems confusing. Every address has an IID, so the "Incorporating.."
pat seems superfluous.

> Interface Identifiers SHOULD remain stable/
[..]
> resulting Interface Identifiers SHOULD be semantically opaque./

If anything, hw about just using a single normative wod in the
introduction of the requirements, rather than one per requirement?

Thanks!

Best regards,

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 27 Jan 2016 11:08:08 +0100

> Fernando Gont <mailto:[email-masked]>
> 27 Jan 2016 10:29
> Hi, Ray,
>
If the intention was only a recommendation, then an Informational RFC 
"Modified EUI64 IIDs are considered harmful" would suffice IMHO. And I 
think that we have that already.

>> 3. Document how 1&  2 impacts text of existing standards
>>
b)
> trivial tracking seems to be warranted.
Agreed, but the "negativesecurity implications" haven't stopped the 
Internet functioning, or slowed adoption of IPv6.
> what the specific bit that concerns you?

1) I think the document structure could be formed around the intentions 
to make the document clearer and easier to read. I've already posted 4 
suggested sections.

2) The text needs to be formulated so that existing implementations 
using modified EUI-64 IIDs remain standards compliant (so that existing 
products don't immediately get commercially disqualified), whilst still 
ensuring that 7217 (or functional equivalent) is preferred, and 
eventually replaces all use of modified EUI-64 IIDs.

That to me calls out for an explicit "deprecate" of modified EUI-64 
IIDs, and a definition of a suitable replacement.

I don't see the word "deprecate" anywhere in the current text.
> 27 Jan 2016 08:38
> I gave plenty of feedback to Fernando whilst he wrote RFC7217, so I 
> know the content and background.
>
> 2. Mandate that RFC7217 SHOULD be the default method of generating 
> IPv6 Interface Identifiers to be used with IPv6 Stateless Address 
> without providing a pathway for existing implementations using 
> Interface Identifiers constructed in Modified EUI-64 format to remain 
> compliant with IETF Standards Track RFCs.
>
>> I have some editorial suggestions, and find the current formulation 
>> of the requirements unnecessarily onerous.
>>
>> the implementation of an alternative scheme ([RFC7217]) as the 
>> default stable IID generation scheme for SLAAC, such that the 
>> aforementioned issues are mitigated./To mitigate the aforementioned 
>> issues, this document RECOMMENDS "A Method for Generating 
>> Semantically Opaque Interface Identifiers with IPv6 Stateless Address 
>> Autoconfiguration (SLAAC)" [RFC7217] as the default method for 
>> generating IPv6 Interface Identifiers to be used with IPv6 Stateless 
>> Address Autoconfiguration (SLAAC)./
>>
>> s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements 
>> for Automatic IPv6 Addresses Generation Incorporating Interface 
>> Identifiers/
>>
>> configured for different prefixes./The resulting Interface 
>> Identifiers SHOULD change when addresses are configured for different 
>> prefixes./
>>
>> s/The resulting Interface Identifiers must be semantically 
>> opaque./The resulting Interface Identifiers SHOULD be semantically 
>> opaque./
>>
>>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2016 08:21:40 -0300

Hi, Ray,

> think that we have that already.

It's not just a recommendation. Part of SLAAC is what you put in the
IID, not just what you send on the wire. At the end of the day, if you
do something really stupid like, say, having all implemetations set a
hardcoded IID ("say, 1"), then stuff does break. -- So stuff does not
break as long as IIDs are generated e.g. such that values have a uniform
distribution.

And if they change frequently, they can beome an operational nightmare
(e.g., ACLs fail).

So I disagree with that line of reasoning.

>> currently do modified eui64 would now become non-compliant?

My two comments here are:

1) I can perfectly live with a s/MUST/SHOULD/. Would that address your
concern?

2) At the end of the day, yes, if you change a rule, legacy equipment
will not be "forward-compliant". But that's the whole point of
standardizing stuff: defining where we want things to go.

> Internet functioning, or slowed adoption of IPv6.

...nor has the implications of tobacco on the human body folks stop
smoking... still doctors advice against smoking.

Going back to your suggestions in this respect:

> 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)

We're not meaning to do that. We're just ecommending against thier use
as a default iid generation algorithm.

> 2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)

I think this bit is clear, already.

> 3. Document how 1 & 2 impacts text of existing standards

You mean how we patch the corresponding RFCs, or what?

> 4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217).

This is essentially the same as 2. -- not sue why you imply this is a
different item...

> eventually replaces all use of modified EUI-64 IIDs.

Would this be addressed by s/MUST/SHOULD/g so to speak?

> I don't see the word "deprecate" anywhere in the current text.

Actually the opposite. We don't want to ban modified eui-64 exactly for
that reason. We just want to recommend against them (and recommend
rfc7217 instead) as the default iid generation scheme.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 27 Jan 2016 13:13:49 +0100

> Fernando Gont <mailto:[email-masked]>
> 27 Jan 2016 12:21
> Hi, Ray,
>
If purchasing departments state "equipment shall be compliant to RFC 
XXXX IETF Standards Track documents" then this will lead to acute problems.
> smoking... still doctors advice against smoking.
We're in violent agreement that something has to be done, and even very 
much in line with the "what".

We're just debating the "how".

> as a default iid generation algorithm.
If they aren't the default, why retain them at all?

If EUI64 IIDs remain in use, then they're harmful.

e.g in a chain of Internet cafes, you can't (easily) track any RFC7217 
generated address across sites, but you can trivially track any (link 
local) EUI64 IID if it remains configured (in parallel to RFC7217). You 
can of course also track MAC addresses, but that's outside IETF remit.
> You mean how we patch the corresponding RFCs, or what?
Correct.

How they'd be patched.

As per current section 6 but clarifying the impact of applying 1+2, 
rather than actually immediately updating the standards docs.

Today, if we apply section 6 literally as written (cut and paste), then 
any text specifying EUI64 IIDs disappears completely from all standards, 
and virtually all current code is non-compliant.
> This is essentially the same as 2. -- not sue why you imply this is a
Nope. It's effect is more akin to https://tools.ietf.org/html/rfc6564, 
which does not itself define any new extension headers, but does set 
requirements on any future standards for extension headers.

> Would this be addressed by s/MUST/SHOULD/g so to speak?
Not really. Section 6 completely deletes current text, and replaces it 
with new text.
> rfc7217 instead) as the default iid generation scheme.
That's not what's written in the current text IMHO.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2016 09:47:00 -0300

Hi, Ray,

> XXXX IETF Standards Track documents" then this will lead to acute problems.

Well, that's already the case is they require an implementation to be
compliant with RFC7217.

With that in mind, it's impossible to do any work in the IETF. Clearly,
one cannot require an implementation for something that was published
earlier last month.

> If they aren't the default, why retain them at all?

1) The default should be safe... then you can override (if available)
and shoot yourself in the foot

2) If we recommend (say, "SHOULD"), RFC7217, and there are nodes that
not implement it, then they will probably do modified-eui64 -- i.e.,
what they do now.

> can of course also track MAC addresses, but that's outside IETF remit.

RFC7217 is alternative to modified eui64, and 7217 says that if you use
it, you shouldn't use anything else for slaac stable addresses.  --
i.e., theres not going to be simultaneous use of rfc7217 and modiied eui64.

Besides, if you deprecate modiied eui64, then rfc7217 becomes even more
mandatory.. Otherwise, how does a node do slaac?

> and virtually all current code is non-compliant.

No, it doesn't. THe modified eui64 bit remains in an appendix of rfc4291bis.

"Current code" will always be compliant with "the specs of the time the
product was produced".

Clearly, if we change a spec, legacy nodes will not be compliant...
otherwise, we'd not be changing the spec. i.e., this happens "by
definition", so to speak.

> requirements on any future standards for extension headers.

Do you mean "for future ipv6-over-foo" or for the existing ipv6 over foo?

> Not really. Section 6 completely deletes current text, and replaces it

How do you expect to change recommendations without deleting text from
the specs that we're updating? -- I don't really follow.

> That's not what's written in the current text IMHO.

Do we ever say we're deprecating modified eui64?

P.S.: At the time, I had an I-D entitled "deprecating eui64" or the
like, and the title was explicitly changed because of this...

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jan 2016 07:55:02 +1300

Taking the bull by the horns:
On 27/01/2016 20:38, Ray Hunter (v6ops) wrote:

...
> But the current text doesn't do that: it updates existing standards without providing a pathway for existing implementations
> using Interface Identifiers constructed in Modified EUI-64 format to remain compliant with IETF Standards Track RFCs.

I believe that is correct. While it doesn't formally deprecate Modified EUI-64,
it does remove it from all the IPv6-over-foo standards.

> 
> To me, slightly restructuring the text around the 4 intentions would make the intentions clearer, and avoid unintended
> consequences, like making existing implementations non-compliant over an issue that quite frankly doesn't actually break any
> functionality.

I don't think it's an unintended consequence at all. On the contrary, I think it's
exactly what we should do. And yes, it will hopefully affect future procurements.

This will *not* break any running code, except if someone is making false deductions
from IID formats. It's years since Windows stopped using Modified EUI-64 by default,
and we seem to have survived that. (There are a couple of observational studies in
published research that make deductions from IID formats, but is anyone really running
tools that contain logic like "if IID looks like Modified EUI-64 then do this, else
do that"?)

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2016 16:43:01 -0300

Hi, Brian,

On 01/27/2016 03:55 PM, Brian E Carpenter wrote:
> and we seem to have survived that.

Additionally, Linux has already moved away from Modified-EUI64, and my
understanding is that starting next year, distros will start shipping
with RFC7217 on by default.

We have spefici guidance on the subject RFC7258, that is clearly not an
argument in favor of modified eui-64, but rather than contrary.

Let's move on.

> (There are a couple of observational studies in
> published research that make deductions from IID formats, 

We have included something in:
<https://www.rfc-editor.org/authors/rfc7707.txt>. But you'll see that
the modified-eui64 percentage is very small.

(The addr6 tool in <http://www.si6networks.com/tools/ipv6toolkit> makes
this kind of study very easy to do).

> but is anyone really running

They shouldn't.

Thanks!

Cheers,