Subject: [6lo] FW: New Version Notification for draft-rashid-6lo-iid-assignment-02.txt

From: AbdurRashidSangi <[email-masked]>
Date: Mon, 31 Oct 2016 09:19:10 +0000

Hi all,

Please provide us your further comments. The draft is updated as per comments received:

In IETF96:
	- Apart from suggested mechanism for generating IID (RFC7217), this draft left to implementers to use a simple random number, RFC4941 or other appropriate mechanism to generate an IID.     
	- A section for arguments to show that address collision does exist, also included in this update. The proposed mechanism is OPTIONAL and doesn't intend complexity to 6LoWPAN ND. Proposed approach is very important for the applications that require higher privacy or to avoid failure of time-critical applications, which probably would suffer from repeated DAD cycle.  

On mailing list:
	- Typographical mistake.     

Regards,
Rashid Sangi,
Huawei, Beijing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 2016年10月31日 16:03
To: Mach Chen; Mach Chen; Charles Perkins; AbdurRashidSangi; AbdurRashidSangi; Charles E. Perkins
Subject: New Version Notification for draft-rashid-6lo-iid-assignment-02.txt

A new version of I-D, draft-rashid-6lo-iid-assignment-02.txt
has been successfully submitted by Abdur Rashid Sangi and posted to the IETF repository.

Name:		draft-rashid-6lo-iid-assignment
Revision:	02
Title:		Designating 6LBR for IID Assignment
Document date:	2016-10-30
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-rashid-6lo-iid-assignment-02.txt
Status:         https://datatracker.ietf.org/doc/draft-rashid-6lo-iid-assignment/
Htmlized:       https://tools.ietf.org/html/draft-rashid-6lo-iid-assignment-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-rashid-6lo-iid-assignment-02

Abstract:
   In IPv6 Stateless Address Autoconfiguration (SLAAC), randomizing the
   interface identifier (IID) is a common practice to promote privacy.
   If there are a very large number of nodes, as has been discussed in
   several use cases, the effect will to proportionately increase the
   number of IIDs.  A duplicate address detection (DAD) cycle is needed
   for each configured IID, introducing more and more overhead into the
   network.  Each failed DAD requires the initiating node to regenerate
   a new IID and undergo the DAD cycle again.  This document proposes an
   optimized approach when higher privacy is required by given network
   by allowing 6LBR (6LoWPAN Border Router) to provide a unique IID,
   avoiding the potential duplication.  Such practice also prevent
   probable failure of time-critical application by enabling 6LBR to
   suggest unique IID, in case of address collision.

   Additionally, further optimizations are suggested to enable multiple
   concurrent DAD cycles and to return the suggested IID from 6LBR to
   6LN in a space-efficient manner.

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.

The IETF Secretariat