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.

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?

 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.

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.

Best regards.

Yong-Geun.


On Fri, Jun 17, 2016 at 6:41 PM, AbdurRashidSangi 
<[email protected]<mailto:[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]> 
[mailto:[email protected]<mailto:[email protected]>]
Sent: 2016年6月17日 11:42
To: [email protected]<mailto:[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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
6lo mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo

Reply via email to