Subject: [6lo] I-D Action: draft-ietf-6lo-rfc6775-update-07.txt

From: [email-masked]
Date: Fri, 28 Jul 2017 11:45:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF.

        Title           : An Update to 6LoWPAN ND
        Authors         : Pascal Thubert
                          Erik Nordmark
                          Samita Chakrabarti
	Filename        : draft-ietf-6lo-rfc6775-update-07.txt
	Pages           : 31
	Date            : 2017-07-28

Abstract:
   This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
   clarify the role of the protocol as a registration technique,
   simplify the registration operation in 6LoWPAN routers, as well as to
   provide enhancements to the registration capabilities and mobility
   detection for different network topologies including the backbone
   routers performing proxy Neighbor Discovery in a low power network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-07
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-rfc6775-update-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-rfc6775-update-07

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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Jul 2017 18:49:49 +0000

Dear chairs and all:

This revision addresses Sedat and Rahul's WGLC comments, and integrates the computation of the TID as discussed at the WG meeting.

To my best knowledge, the document is ready for the next steps.

Take care,

Pascal

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: vendredi 28 juillet 2017 20:45
To: [email-masked]
Cc: [email-masked]
Subject: [6lo] I-D Action: draft-ietf-6lo-rfc6775-update-07.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.

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

---

From: Rahul <[email-masked]>
Date: Sat, 29 Jul 2017 07:35:39 +0000 (UTC)

Thanks Pascal for the revised text.

Have some more points...

The revised text suggests to use EARO in the DAR/DAC messages (section 
6.1 in 6775-update-07) to include TID so as to indicate freshness.

Current RFC6775 does not use ARO option in DAR/DAC message (section 
4.1), but it copies most (but not all) of its fields including 
registration lifetime, EUI-64 in the Duplicate Address Messages.
Quoting RFC6775, "The information contained in the ARO is also included in 
the multihop DAR and DAC messages used between 6LRs and 6LBRs, but the 
option itself is not used in those messages."

Two points:
a. This update suggests including EARO in DAR/DAC message which is in 
contradiction to the text suggested in section4.1-RFC6775. Per me, I don't 
see a problem with this inclusion, but just want to highlight this fact 
and wondering if a text update could be added.
b. Secondly, with this inclusion, the reg lifetime and EUI-64 is redundant 
in the DAR/DAC (since EARO option and base DAR/DAC have the same fields). 
This is 12bytes redundancy! Essentially what we want is TID to be 
included in DAR/DAC messages but using EARO in DAR/DAC might not be the 
best way to do it.

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 31 Jul 2017 08:00:25 +0000

Great point Rahul, thanks for rising it.

Our initial intention was to potentially make the EARO bigger, in particular to enable larger crypto tokens in AP ND.

We also wanted extensions to indicate the type of ID that replace the MAC as unique ID, which required space.

So far we are not doing any of that so we could probably avoid adding the EARO to the DAR. There is room for the TID. But not for the flags; so we'd need to place the T flag in the ICMP code.

I'd like to see what Erik thinks about that. I s that an abuse?

Pascal

> Le 28 juil. 2017 à 20:50, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Dear chairs and all:
>