Dear Rashid Sangi. Thanks for your response. See my comments inline.
Best regards. Yong-Geun. On Mon, Jun 20, 2016 at 4:30 PM, AbdurRashidSangi <[email protected]> wrote: > Dear Yong-Geun, > > > > Thank you for your comments. Replies are mentioned with tag [RS] in-line. > > > > Regards. > > Rashid Sangi. > > > > > > *From:* 6lo [mailto:[email protected]] *On Behalf Of *Yong-Geun Hong > *Sent:* 2016年6月20日 13:47 > *To:* AbdurRashidSangi > *Cc:* [email protected] > *Subject:* Re: [6lo] FW: I-D Action: > draft-rashid-6lo-iid-assignment-01.txt > > > > > > Dear Rashid Sangi. > > > > Thanks for your contribution. > > > > I read your draft and it is interesting. > > > > I would like to deliver my comments. > > > > 1. IID Assignment by 6LBR > > When I extended Mobile IPv6, I also thought that a router can perform > movement detection, formulates a new CoA of the MN and does Duplicate > Address Detection (DAD) on behalf of the MN ( > https://datatracker.ietf.org/doc/draft-hong-mobileip-acar/). > Unfortunately, this works did not continue. > > > > Until now, generating IIDs depends on the nature of networks and link > layer technologies. In the constrained environments, IID of each device are > heterogeneous. > > [RS] Considering the heterogeneous nature of IID, this draft suggests an > existing way that can be used to generate an IID. > > [Yong-Geun] O.K. I see your point. > > > In this situation, IID assignment by 6LBR may have pros and cons. It is > better to describe the pros and cons more detail. > > [RS] Do you mean the pros/cons with and without the proposed arrangement > (designating 6LBR to assign IIDs) or comparison with approach like DHCP? > [Yong-Geun] I want to say it is better to have pros/cons with and without the proposed arrangement. > > > I am wondering how to provide backward compatibility to legacy devices > that use conventional generating IIDs. > > [RS] This approach is a non-default approach. EARO would be initiated by > 6LN and the node decides to either use this approach or not. > [Yong-Geun] O.K. I see your point. > > > 2. Mismatch of main body texts and figure > > In figure 1, "Randomized Secret Key" is used but "Randomized Private > Key" is used in the main body texts. > > Is it same or different? > > [RS] As we know, secret key is used in symmetric cryptography where only > one key is needed for encryption and decryption and the concept of > private/public key is used in a-symmetric cryptography where two entities > uses each kind of key -interchangeably - to provide different services > "Authentication, Integrity or Confidentiality". > > > > RFC7217 refers to Secret Key and private key is mistakenly mentioned in > the draft. We would correct it in next version. > [Yong-Geun] Good. > > > Best regards. > > > > Yong-Geun. > > > > > > On Fri, Jun 17, 2016 at 6:41 PM, AbdurRashidSangi <[email protected]> > wrote: > > Hello everyone, > > We just uploaded the next version for this draft. In addition to > designating 6LBR for IID assignment, it also proposes a simple XOR'ed > operation to deliver to 6LN the suggested IID in a space-efficient manner. > > Currently, 128 bits are allocated in DAC/DAR to carry 'Registered Address' > but this draft completely elides these 128 bits and exchange the address by > aggregating it with EUI-64. > > Let us know your comments/views/suggestions. > > Thanks. > Rashid Sangi. > Huawei, Beijing, China. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 2016年6月17日 11:42 > To: [email protected] > Subject: I-D Action: draft-rashid-6lo-iid-assignment-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Designating 6LBR for IID Assignment > Authors : Abdur Rashid Sangi > Mach (Guoyi)Chen > Charles E. Perkins > Filename : draft-rashid-6lo-iid-assignment-01.txt > Pages : 11 > Date : 2016-06-16 > > 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 that requires 6LBR (6LoWPAN Border Router) to > provide a unique IID, avoiding the potential duplication. > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-rashid-6lo-iid-assignment/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-rashid-6lo-iid-assignment-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-rashid-6lo-iid-assignment-01 > > > 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/ > > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo > > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
