Subject: [6lo] FW: I-D Action: draft-rashid-6lo-iid-assignment-01.txt

From: AbdurRashidSangi <[email-masked]>
Date: Fri, 17 Jun 2016 09:41:05 +0000

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-masked] [mailto:[email-masked]] 
Sent: 2016年6月17日 11:42
To: [email-masked]
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/

---

From: Yong-Geun Hong <[email-masked]>
Date: Mon, 20 Jun 2016 14:46:59 +0900

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. In this situation, IID assignment by 6LBR may have pros and
cons. It is better to describe the pros and cons more detail.
 I am wondering how to provide backward compatibility to legacy devices
that use conventional generating IIDs.

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?

Best regards.

Yong-Geun.

On Fri, Jun 17, 2016 at 6:41 PM, AbdurRashidSangi <[email-masked]>
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.
>
> 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.
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: AbdurRashidSangi <[email-masked]>
Date: Mon, 20 Jun 2016 07:30:57 +0000

Dear Yong-Geun,

Thank you for your comments. Replies are mentioned with tag [RS] in-line.

Regards.
Rashid Sangi.

From: 6lo [mailto:[email-masked]] On Behalf Of Yong-Geun Hong
Sent: 2016年6月20日 13:47
To: AbdurRashidSangi
Cc: [email-masked]
Subject: Re: [6lo] FW: I-D Action: draft-rashid-6lo-iid-assignment-01.txt

Dear Rashid Sangi.

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-masked]<mailto:[email-masked]>> wrote:
Hello everyone,

Thanks.
Rashid Sangi.
Huawei, Beijing, China.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 2016年6月17日 11:42
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-rashid-6lo-iid-assignment-01.txt

Abstract:

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>.

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

---

From: Yong-Geun Hong <[email-masked]>
Date: Tue, 21 Jun 2016 22:01:21 +0900

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-masked]>
wrote:

> *From:* 6lo [mailto:[email-masked]] *On Behalf Of *Yong-Geun Hong
> *Sent:* 2016年6月20日 13:47
> *To:* AbdurRashidSangi
> *Cc:* [email-masked]
> *Subject:* Re: [6lo] FW: I-D Action:
> draft-rashid-6lo-iid-assignment-01.txt
>
>
>
>
>
> Dear Rashid Sangi.
>
>
>
> https://datatracker.ietf.org/doc/draft-hong-mobileip-acar/).
> Unfortunately, this works did not continue.
>
>
>
> 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.

> [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.

> [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.

---

From: AbdurRashidSangi <[email-masked]>
Date: Wed, 22 Jun 2016 09:45:36 +0000

Dear Yong-Geun,

Your input received with thanks and the modifications would be projected in next version, accordingly.

Regards.
Rashid Sangi.

>From: Yong-Geun Hong [mailto:[email-masked]] 
>Sent: 2016年6月21日 21:01
>To: AbdurRashidSangi
>Cc: [email-masked]