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 protected] [mailto:[email protected]] 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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
