Subject: I-D Action: draft-ietf-6man-default-iids-02.txt

From: [email-masked]
Date: Fri, 23 Jan 2015 09:30:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Recommendation on Stable IPv6 Interface Identifiers
        Authors         : Fernando Gont
                          Alissa Cooper
                          Dave Thaler
                          Will Liu
	Filename        : draft-ietf-6man-default-iids-02.txt
	Pages           : 8
	Date            : 2015-01-23

Abstract:
   The IPv6 addressing architecture defines Modified EUI-64 format
   Interface Identifiers, and the existing IPv6 over various link-layers
   specify how such identifiers are derived from the underlying link-
   layer address (e.g., an IEEE LAN MAC address) when employing IPv6
   Stateless Address Autoconfiguration (SLAAC).  The security and
   privacy implications of embedding link-layer addresses in the
   Interface Identifier have been known and understood for some time
   now, and some popular IPv6 implementations have already deviated from
   such schemes to mitigate these issues.  This document changes the
   recommended default Interface Identifier generation scheme to that
   specified in RFC7217, and recommends against embedding link-layer
   addresses in IPv6 Interface Identifiers.  It formally updates
   RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590,
   RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and
   RFC5121, which require IPv6 Interface Identifiers to be derived from
   the underlying link-layer address.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-default-iids-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Jan 2015 15:11:51 -0300

Folks,

We've posted a revision of the aforementioned I-D. This version is
mostly meant to address:

1) Ralph's comments regarding relaxing the requirements for some
link-layer technologies

2) Comments about our use of hardware addresses (now changed to
link-layer addresses).

This version of the document should be ready for WGLC... but please let
us know if we have missed something.

Thanks,
Fernando

On 01/23/2015 02:30 PM, [email-masked] wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: James Woodyatt <[email-masked]>
Date: Fri, 23 Jan 2015 12:11:30 -0800

Everyone—

Link layers MUST define a mechanism that provides that mitigates the
> security and privacy implications discussed in Section 1.

Editorial nit: "that provides that mitigates" seems like an awkward phrase,
and I'm not sure what it means. This is a pretty important requirement
specification, so I'd like to see it written with optimal clarity. How
about this for starters:

  Link layers MUST define a mechanism that provides mitigation of the
security and privacy issues discussed in section 1.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Jan 2015 17:30:55 -0300

Hi, James,

On 01/23/2015 05:11 PM, James Woodyatt wrote:
> Editorial nit: "that provides that mitigates" seems like an awkward
> phrase, and I'm not sure what it means. This is a pretty important
> requirement specification, so I'd like to see it written with optimal
> clarity. How about this for starters:
> 

You're right (my bad!) -- will get this fixed in the next rev.

Thanks!

Best regards,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 23 Jan 2015 22:34:12 +0000 (UTC)

Hi,

I think there is a bit of a mismatch between the ID's title and the contents. I think the title is a bit too general when the ID is only specific to the SLAAC methods of address generation and address configuration.

I'd much prefer to see the title left as it is and the advice extended to 

- the use of RFC7217 like IIDs as a default policy for stateful DHCPv6 (i.e., draft-ietf-dhc-stable-privacy-addresses), unless overridden by the stateful DHCPv6 operator (as a side note and to support advising on a default DHCPv6 address generation policy, the current version of OpenWRT comes with both SLAAC and stateful DHCPv6 addressing enabled by default (not sure why though).)

- a bit of advice that manually/statically generated and configured interface IDs should also be chosen with these sorts of properties too

Alternatively, I think the title needs to be changed to something like "Recommendation on Stable SLAAC IPv6 Interface Identifiers"

Regards,
Mark.

________________________________
From: Fernando Gont <[email-masked]>
To: [email-masked] 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Ralph Droms <[email-masked]> 
Sent: Saturday, 24 January 2015, 5:11
Subject: Default IIDs (Re: I-D Action: draft-ietf-6man-default-iids-02.txt)

Folks,

Thanks,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Jan 2015 20:11:41 -0300

Hi, Mark,

On 01/23/2015 07:34 PM, Mark ZZZ Smith wrote:
> 
> I think there is a bit of a mismatch between the ID's title and the
> contents. I think the title is a bit too general when the ID is only
> specific to the SLAAC methods of address generation and address
> configuration.
> 
> - the use of RFC7217 like IIDs as a default policy for stateful
> DHCPv6 (i.e., draft-ietf-dhc-stable-privacy-addresses), unless
> overridden by the stateful DHCPv6 operator (as a side note and to
> support advising on a default DHCPv6 address generation policy, the
> current version of OpenWRT comes with both SLAAC and stateful DHCPv6
> addressing enabled by default (not sure why though).)

You make a good observation. What you suggest sound sensible (although
default-iids has reqs for hosts, while
draft-ietf-dhc-stable-privacy-addresses would apply to servers). What do
other folks think?

(FWIW, what do you mean by "both enabled by default"? Since DHCPv6 is
triggered by having the relevant bits of RA messages set appropriately,
I think it make sense to have the "DHCPv6 machinery" enabled by
default.. or did I miss something?)

> - a bit of advice that manually/statically generated and configured
> interface IDs should also be chosen with these sorts of properties
> too

Well. this wouldn't be "default iids", so... I guess we could leave them
out?

> Alternatively, I think the title needs to be changed to something
> like "Recommendation on Stable SLAAC IPv6 Interface Identifiers"

Having words on the DHCPv6 IIDs sound sensible. But I can certainly live
with this other alternative option.

What does the wg think about this?

Thanks,

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 23 Jan 2015 23:51:07 +0000 (UTC)

Hi Fernando,

----- Original Message -----
From: Fernando Gont <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>; "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Ralph Droms <[email-masked]>
Sent: Saturday, 24 January 2015, 10:11
Subject: Re: Default IIDs (Re: I-D Action: draft-ietf-6man-default-iids-02.txt)

Hi, Mark,

* So perhaps that is further evidence that the title is currently a bit too general - I interpret the title mean advice on choosing stable IID values, regardless of what device or method is used to generate or choose them ("Recommendation on Stable IPv6 Interface Identifiers"). In the case of SLAAC that is the host, in the case of stateful DHCPv6, that is the DHCPv6 server, and in the case of manual/static, that is the operator. I think the primary and fundamental motivation for using manual/static addresses has always been to have stable IDs, so people might even interpret the current title to mean it only applies to the choice of manual/static addresses and not SLAAC (and possibly stateful DHCPv6).

* I meant that a stateful DHCPv6 server is enabled by default on OpenWRT, in parallel with RAs with PIOs with their A bit set too ("SLAAC enabled" by default) - and a few of my hosts that are stateful DHCPv6 enabled by default (Fedora 20/21) are getting addresses using both SLAAC and stateful DHCPv6. I thought and broadly still think that it would be more common for SLAAC to be enabled by default on a link and an operator would choose to enable stateful DHCPv6 (and probably then disable SLAAC). That is why I'm little surprised that OpenWRT enables stateful DHCPv6 by default, however I think that then means that advice on default IID selection for stateful DHCPv6 becomes more useful as there is at least one instance where stateful DHCPv6 has been enabled by default 'in the wild'.

* That's a good point, there is of course no such thing as a 'default' manually generated IID. I'd see text regarding advice on choosing IID values for static addresses as more of a side note or passing comment, just to cover it off somewhere (perhaps as the title might imply that it is covered), as it is currently the third alternative method of address generation and configuration to SLAAC and stateful DHCPv6.

Regards,
Mark.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Jan 2015 13:40:36 +1300

I'm all for this draft.

I think it might benefit from informational references to
RFC 7136 and RFC 7421, as context for the reader.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Jan 2015 01:26:34 -0300

Hi, Brian!

Thanks so much for your feedback! -- Please find my comments in-line....

> RFC 7136 and RFC 7421, as context for the reader.

How about adding this:
"  [RFC7136] clarifies that the IID should be treated as an
   opaque value, while [RFC7421] provides an analysis of the 64-bit
   boundary in IPv6 addressing."

to the very end of Section 1, as part of the "NOTE"?

P.S.: Any thoughts on Mark's proposal regarding DHCPv6 and the document
title?

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jan 2015 09:13:18 +1300

Hi Fernando,
> to the very end of Section 1, as part of the "NOTE"?

OK, thanks.

> P.S.: Any thoughts on Mark's proposal regarding DHCPv6 and the document

I think it's a good idea. Otherwise we'll see people using guessable
sequences for DHCPv6-based addresses, and that can't be a good thing.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Jan 2015 17:14:51 +0100

> You're right (my bad!) -- will get this fixed in the next rev.

HEllo,

BEyond fixing the double that, what does this requirement mean to link 
layers?

For example, ieee 802.11p does not offer security features, assuming 
some other ieee protocol (and why not an IP protocol) will.  Would the 
default-iid requirement still apply to ieee 802.11p links?

Also, better privacy needs IIDs bigger than 64 (what does 'mitigate' 
mean).  Does default-iid requirement mean that new link layers should 
use IIDs of other length than 64?

What is this requirement more clearly?

Alex