Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[Lorenzo Colitti <[e-mail]>]

I continue to oppose this document.

This draft says that existing address generation mechanisms are bad for
privacy, and proceeds to change them. But there is nothing wrong with
the existing address generation mechanisms as if the link-layer addresses
are not stable, (e.g., random MAC addresses), and a growing body of IETF
work

This draft forbids implementations from using existing address generation
mechanisms using random MAC addresses, which is a perfectly valid way to
address the privacy problem this draft is purportedly solving, and is an
approach standardized in other IETF work, for example,
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1
(now in RFC editor queue).

Here are several examples of how this draft forbids using address
generation mechanisms with random MAC addresses.

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.
...
   In standardized recommendations for IPv6 IID generation meant to
   achieve particular security and privacy properties, it is therefore
   necessary to recommend against embedding link-layer addresses in IPv6
   IIDs.
...
   By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed the underlying link-layer address in the IID.

These statements should not say "link-layer address". They should say
"stable link-layer-address" or "non-ephemeral link-layer-address" or
"link-layer address that are not known to be ephemeral".

Worse, consider this normative text:

   The entire text of Section 4 of [RFC2464] is replaced with the
   following text:

   ---------------- cut here -------------- cut here ----------------
   The Interface Identifier [AARCH] for an Ethernet interface MUST be
   generated as specified in [RFCXXXX].

This explicitly prohibits an implementation from taking a random MAC
address and forming an EUI-64 address out of it.

On Fri, May 13, 2016 at 5:43 AM, Brian E Carpenter <
[e-mail]> wrote:

> With the clarifying references to RFC4941, I think this document is
> in good shape and ready to be advanced.
>
>     Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>