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

"weigengyu" <weigengyu@bupt.edu.cn> Mon, 09 May 2016 06:35 UTC

Return-Path: <weigengyu@bupt.edu.cn>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2353C12B04E for <ipv6@ietfa.amsl.com>; Sun, 8 May 2016 23:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.458
X-Spam-Level:
X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT_rbenylPvE for <ipv6@ietfa.amsl.com>; Sun, 8 May 2016 23:35:37 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id C249812B024 for <ipv6@ietf.org>; Sun, 8 May 2016 23:35:36 -0700 (PDT)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id AA87819F420 for <ipv6@ietf.org>; Mon, 9 May 2016 14:35:35 +0800 (HKT)
Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 2CE5419F404; Mon, 9 May 2016 14:35:35 +0800 (HKT)
Message-ID: <8E1CCE051EDF4491953D6E093809DA68@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: Alissa Cooper <alissa@cooperw.in>
References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> <CD39E9F1-4060-4884-91B3-5A974C3FFFF7@cooperw.in>
In-Reply-To: <CD39E9F1-4060-4884-91B3-5A974C3FFFF7@cooperw.in>
Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt
Date: Mon, 09 May 2016 14:35:35 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/7WxaV5_jVb_8B9yrt4z1D60Rop0>
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2016 06:35:39 -0000

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, internet-drafts@ietf.org 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------