Re: I-D Action: draft-ietf-6man-default-iids-11.txt

["weigengyu" <[e-mail]>]

Hi all,

Is it not a problem to promote RFC7217 in which concept errors are existed?

RFC7217 did not only giving a definition of stable address, but also 
defining an algorithm to generate it.
The algorithm contains concept error in my opinion.

>
>        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
>
> Abstract:
>   This document changes the default scheme for generating stable
>   Interface Identifiers with SLAAC to that specified in RFC7217, and
>   recommends against embedding link-layer addresses in IPv6 Interface
>   Identifiers.


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----原始邮件----- 
From: weigengyu
Sent: Monday, May 09, 2016 2:35 PM
To: Alissa Cooper
Cc: [e-mail]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt

Hi，

> This document changes the default scheme for generating stable
   Interface Identifiers with SLAAC to that specified in RFC7217,

There is a question about RFC7217 as this draft is to promote it.
In RFC7217,  in Page 6 and page 7,  "5.  Algorithm Specification"
"1.  Compute a random (but stable) identifier with the expression:
       RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
       Where:
       RID:
          Random (but stable) Identifier
       F():
          A pseudorandom function (PRF) that MUST NOT be computable from
          the outside (without knowledge of the secret key).  F() MUST
          also be difficult to reverse, such that it resists attempts to
          obtain the secret_key, even when given samples of the output
          of F() and knowledge or control of the other input parameters.
          F() SHOULD produce an output of at least 64 bits.  F() could
          be implemented as a cryptographic hash of the concatenation of
          each of the function parameters.  SHA-1 [FIPS-SHS] and SHA-256
          are two possible options for F().  Note: MD5 [RFC1321] is
          considered unacceptable for F() [RFC6151]. "

It seems it is a concept error for RID.
RID is not random or random identifier according to the context above.

F() is an inreverse function, not a pseudorandom function.
Within parameters of F(Prefix, Net_Iface, Network_ID, DAD_Counter,
secret_key),
only the secret_key is generated by a pseudorandom function.
But the secret_key is also a constant because it keeps unchanged after being
generated.

There are not random features.

The question is why it is called RID, Random ID?


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Alissa Cooper
Sent: Thursday, April 28, 2016 10:41 PM
To: IETF IPv6 Mailing List
Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt

This version incorporates comments based on discussion before and during
IETF 95 (thanks to Fernando for spinning the rev). I think this version
addresses the comments received and should be ready to move forward.

Alissa


> On Apr 27, 2016, at 5:49 PM, [e-mail] wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 Maintenance 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-11.txt
> Pages           : 23
> Date            : 2016-04-27
>
> Abstract:
>   This document changes the default scheme for generating stable
>   Interface Identifiers with SLAAC 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, RFC5072, and RFC5121, by removing the text in these RFCs
>   that required the IPv6 Interface Identifiers to be derived from the
>   underlying link-layer address, and replacing the aforementioned text
>   with a pointer to this document.  Additionally, this document updates
>   RFC3315 by specifying additional requirements on the generation of
>   Interface Identifiers used in Dynamic Host Configuration Protocol
>   version 6 (DHCPv6).  It also provides advice to system administrators
>   who employ manual configuration.  This document does not change any
>   existing recommendations concerning the use of temporary addresses as
>   specified in RFC 4941.
>
>
> 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:
> https://tools.ietf.org/html/draft-ietf-6man-default-iids-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-11
>
>
> 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/
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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


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