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

[神明達哉 <[e-mail]>]

At Wed, 11 May 2016 20:19:01 -0700,
Bob Hinden <[e-mail]> wrote:

>        Title           : Recommendation on Stable IPv6 Interface Identifiers
>        Authors         : Fernando Gont
>                          Alissa Cooper
>                          Dave Thaler
>                          Will Liu
>     Filename        : draft-ietf-6man-default-iids-11.txt
>     Pages           : 23
>     Date            : 2016-04-27
>
>         https://tools.ietf.org/html/draft-ietf-6man-default-iids-11
>
> as a Proposed Standard.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 25 May 2016.

I've read version 11 of the document.  Personally I don't have a
strong objection to publishing it, but, if I understand the past
concerns correctly, I suspect this version don't fully address them.
I also have one non-trivial point, which I would like to be address
before publication.

If my understanding is correct, one major concern raised in the past
was that some implementors may simply not see the need for the
stability and just want to address the security/privacy issues in a
different way (such as just using randomized link-layer addresses).  I
don't have a strong opinion on this particular concern myself, but I
see the point of such concerns.  If the intent of this document is not
to refuse the concern (which I'm not sure about), the current tone
still seems to be too normative.  Again, I'm not sure if the intent is
to address the concern, but if it is, I think something like the
following will be necessary:

- clarify that this recommendation is only for environments where
  address stability is needed
- clarify that this document assumes "link layer addresses" are
  something permanent, such as MAC addresses that don't change
  throughout the lifetime of the node using the hardware
- update the requirement level and wording to existing RFCs.  For
  example, replaced text for RFC2462 provided in Section 6.1

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

  is probably too strong, since this would invalidate any
  implementation that doesn't implement or use RFCXXXX.  The same
  sense of comment applies to all similar changes.

And, one other point I want to be addressed: in Section 4 it states:

   By default, DHCPv6 server implementations SHOULD NOT generate
   predictable IPv6 addresses (such as IPv6 addresses where the IIDs are
   consecutive small numbers).  [I-D.ietf-dhc-stable-privacy-addresses]
   specifies one possible algorithm that could be employed to comply
   with this requirement.  Another possible algorithm would be to select
   a pseudo-random value chosen from a discrete uniform distribution,
   while avoiding the reserved IPv6 Interface Identifiers [RFC5453]
   [IANA-RESERVED-IID].

 I suggest just removing the second sentence.
 ietf-dhc-stable-privacy-addresses is not a dhc wg item anymore due to
 some controversy, and it's not clear what will happen to its
 successor in the form of individual submission:
 draft-gont-dhcpv6-stable-privacy-addresses-01
 Since this sentence is only to show an example, just showing the
 "another possible algorithm" would suffice.

Finally, one minor editorial nit: in section 6.14

   for instance, using a method described in [8], to autoconfigure one
   or more global unicast addresses.

there should be a 'cut here' line after this text.

--
JINMEI, Tatuya