Subject: [6lowpan] Comments on draft-ietf-6lowpan-nd-09

From: Robert Cragie <[email-masked]>
Date: Fri, 14 May 2010 16:26:19 +0100

Here is a list of comments and typos on draft-ietf-6lowpan-nd-09. I 
tried to send this as marked-up HTML (much easier to read) but it won't 
let me, so here are the distilled comments.

Robert

Comments:

page 5:

"DAD of use multicast" - grammar?
"from the same prefix can be used" - 'reached' instead of 'used'?

page 7:

"EUI-64s are globally unique" - What about the case of spoofed/cloned 
EUI-64s? What would be the effect using this ND? Would it be 
significant? My guess is probably not but it might be worth making this 
clear

page 8:

"However, the Address Registration mechanism might be useful for other 
link layer technologies" - I would have thought all the mechanisms and 
modifications may apply to other link layer technologies

page 9:

The process during which a LoWPAN node sends an Neighbor Solicitation 
message - Is "LoWPAN node" a specific term? If so, needs to be defined. 
I would also suggest it is called 6LoWPAN Node (6LN?) to be consistent

"that allows for sleeping nodes" - 6LoWPAN nodes? Check for this 
throughout the document

"initial set of default routers" - This might seem pedantic, but 
"Router" (with an uppercase R) is defined in this document and "router" 
(with a lowercase r) is defined in RFC4861 and they are subtly 
different. Maybe have this consistency across the document

page 10:

"which in turn use normal Neighbor Discovery mechanisms to convey this 
information to the hosts" - I think this is questionable; there are some 
differences

"DAD is optional if DHCPv6 is used to assign addresses" - Or an 
alternative address assignment mechanism

page 12:

"In this case, the Neighbor Solicitation and Advertisement messages will 
be forwarded between the 6LR and 6LBRs" - This is overloading the 
original use of NS/NA as defined in RFC4861 quite a lot and changing the 
rules. There seemed to be resistance to defining a new message but 
wouldn't that actually be better?

page 16:

C: 1-bit context compression flag - I would add the proposed text at the 
end of the definition to make it clear what this flag is for: "This flag 
is used to manage the context lifecycle based on the recommendations in 
Section 7.2"

page 18:

"and sent to the IPv6 All-Routers multicast address" - There is also a 
case for being able to send unicast as it is possible the host has 
discovered which router it wishes to join the network through by other 
means, e.g. 802.15.4 beacon request. This could potentially limit 
traffic. Section 5.8.2 also says it can be sent unicast.

page 19:

"This includes the Context ID, the prefix" - Possibly some confusion 
between the context prefix and the prefix in the PIO. Maybe clarfication 
on the terminology is needed.

page 21:

"or the appropriate IP-over-foo document" - Is this a well-known phrase 
in the IETF community? :-)

page 25:

"then care should be taken to ensure that there isn't a flood of 
ARO-carrying messages **sent** to the 6LBR as each router hears an ARO 
from their neighboring routers" - Is this likely to happen with a 
unicast to 6LBR? (** typo 'send' -> 'sent' **)

page 28:

"then the RA MUST be silently ignored" - "Silently ignored" is a 
tautology. Either "silently discarded" or simply "ignored"

page 29:

"The routers periodically send Router Advertisements" - "may 
periodically send"? It is optional, isn't it? Also might be worth 
mentioning this information could be disseminated by other mechanisms.

page 30:

8.2.1. Special Message Validation - This is a rather complex rule for 
NS/NA processing as the hop limit processing may well happen before 
payload processing. Could it be made simpler or more logical?

page 31:

"It proceeds to look for the Registration Address in the DAD Table.  If 
an entry is found and the recorded EUI-64 is different than the EUI-64 
in the ARO, then it returns an NA with the ARO Status set to 1 
('Duplicate Address').  Otherwise it returns an NA with ARO Status set 
to zero." - It would be really nice if it could also return a 'suggested 
address'. This would complete address assignment without the host having 
to guess again.

page 33:

Figure 3: Do you need the 'NS' and 'NA' component in the diagram? It 
makes it inconsistent with Figure 2.

Typos:

The change is bracketed by <span class=hilite></span>

page 7:

Optimize Neighbor Discovery with <span class=hilite>mechanisms that 
are</span> minimal yet sufficient for the operation in both mesh-under 
and route-over configurations.

<span class=hilite>Provide s</span>upport for sleeping hosts.

<span class=hilite>Provide an o</span>ptional duplicate address 
detection mechanism suitable for route-over LoWPANs

page 8:

Note that nothing in this document precludes a node <span 
class=hilite>being</span> a router on some interfaces

page 9:

In a mesh-under configuration only <span class=hilite>6LBRs</span> and 
hosts exist; there are no <span class=hilite>6LRs</span> in mesh-under 
topologies

The most important part of the <span class=hilite>optimizations</span> 
is the evolved host-to-router interaction that allows for sleeping

page 11:

In an isolated <span class=hilite>LoWPAN,</span> a ULA

page 19:

The host SHOULD unicast <span class=hilite>a</span> Router Solicitation

Unicast Neighbor Solicitation (NS) messages are <span 
class=hilite>sent</span> by hosts

page 21:

Link-layer addresses for neighbors are stored in Neighbor Cache entries 
[<A href="http://tools.ietf.org/html/rfc4861" title="&quot;Neighbor 
Discovery for IP version 6 (IPv6)&quot;">RFC4861</A><span 
class=hilite>]. </span>In order to achieve LoWPAN compression

page 23:

in the Router Advertisement messages it sends.<span class=hilite>  
If</span> the 6LR has <span class=hilite>received RAs from different 
6LBRs, with the same or different prefixes and context information, 
</span> then it will

page 24:

Section 8.2</A> <span class=hilite>specifies</span> optional behavior 
for a 6LBR for other

If the NS contains a valid ARO, then the router inspects its Neighbor 
Cache on the arriving interface to see if it is a duplicate. <span 
class=hilite>If there is no Neighbor Cache entry for the IPv6 source 
address of the NS or if there is such a Neighbor Cache entry and the 
EUI-64 is the same, then it isn't a duplicate.  Otherwise it is a 
duplicate address.</span>

page 25:

When routers use ARO to register with each other and the optional DAD to 
the 6LBR <span class=hilite>is in use (<A 
href="http://tools.ietf.org/html/draft-ietf-6lowpan-nd-09#section-8.2">Section 
8.2</A>),</span> then care should be taken to ensure that there isn't a 
flood of ARO-carrying messages <span class=hilite>sent</span> to the 
6LBR as each router

page 27:

Optionally the Router Advertisement messages can be used to disseminate 
<span class=hilite>prefixes and contexts</span> to all

page 28:

then the routers follow [<A href="http://tools.ietf.org/html/rfc4861" 
title="&quot;Neighbor Discovery for IP version 6 
(IPv6)&quot;">RFC4861</A>]<span class=hilite>, which</span> states that 
they merely do some

it sends the 'expiry time'<span class=hilite>, preventing accidentally 
moving</span> further into the future.  For example, if a 6CO with a 
Valid lifetime of 10 minutes is <span class=hilite>received</span> at 
time T, and the router includes this in a RA it sends at time T+5 minutes

If multihop distribution is performed using RA messages, then the 
routers MUST ensure that the ABRO always <span class=hilite>stays</span> 
together

page 29:

<span class=hilite>The routers</span> also respond to Router 
Solicitations by unicasting RA messages

page 30:

Neighbor Cache. <span class=hilite>This conceptual data structure is 
called the DAD table.</span>  It is indexed by

page 31:

When a 6LBR that implements the optional multihop DAD receives an NS 
from a 6LR, <span class=hilite>which contains</span> an ARO with Length 
= 4, then it MUST NOT verify that the hop limit is 255 as specified 
above. <span class=hilite>It</span> proceeds to look for the 
Registration Address in the DAD Table

page 33:

one might want to use <span class=hilite>Secure</span> Neighbor 
Discovery <span class=hilite>(SeND)</span>

-- 

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: Zach Shelby <[email-masked]>
Date: Sat, 29 May 2010 16:07:39 +0300

Hi Robert,

Thanks for the comments, below you'll find merged comments from the authors. On the nit and grammar related comments I will check those though while doing editing on nd-10 so don't be bothered that I skip them below. We have started creating tickets on changes in progress for nd-10.

On May 14, 2010, at 6:26 PM, Robert Cragie wrote:

> page 7:
> 
> "EUI-64s are globally unique" - What about the case of spoofed/cloned EUI-64s? What would be the effect using this ND? Would it be significant? My guess is probably not but it might be worth making this clear

We decided it might take a whole bunch of text to discuss all the issues that might happen with duplicate EUI-64s. For this spec we simply assume that EUI-64s are unique thus we don't try to detect duplicates.

> page 8:
> 
> "However, the Address Registration mechanism might be useful for other link layer technologies" - I would have thought all the mechanisms and modifications may apply to other link layer technologies

That should read "this specification" might be useful... 

> 
> page 9:
> 
> The process during which a LoWPAN node sends an Neighbor Solicitation message - Is "LoWPAN node" a specific term? If so, needs to be defined. I would also suggest it is called 6LoWPAN Node (6LN?) to be consistent
> 
> "that allows for sleeping nodes" - 6LoWPAN nodes? Check for this throughout the document

I added a ticket to add the term 6LN.

> 
> "initial set of default routers" - This might seem pedantic, but "Router" (with an uppercase R) is defined in this document and "router" (with a lowercase r) is defined in RFC4861 and they are subtly different. Maybe have this consistency across the document

We'll try to improve consistency. 

> 
> page 10:
> 
> "which in turn use normal Neighbor Discovery mechanisms to convey this information to the hosts" - I think this is questionable; there are some differences
> 
> "DAD is optional if DHCPv6 is used to assign addresses" - Or an alternative address assignment mechanism

We don't know of alternative assignment mechanisms, so let's just talk about DHCPv6 in this draft.

> 
> page 12:
> 
> "In this case, the Neighbor Solicitation and Advertisement messages will be forwarded between the 6LR and 6LBRs" - This is overloading the original use of NS/NA as defined in RFC4861 quite a lot and changing the rules. There seemed to be resistance to defining a new message but wouldn't that actually be better?

This was the approach in earlier versions of 6lowpan-nd with Neighbor Registration/Confirmation, but for this draft we chose to use NS/NA across the board for simplicity, although what you suggest has been discussed. Let's keep using the same NS/NA message in Section 8.2 as for the base registration for now unless people run into major implementation problems or we get IESG comments on this. This is something we should keep in mind though.

> page 16:
> 
> C: 1-bit context compression flag - I would add the proposed text at the end of the definition to make it clear what this flag is for: "This flag is used to manage the context lifecycle based on the recommendations in Section 7.2"

Thanks, ticket added.

> 
> page 18:
> 
> "and sent to the IPv6 All-Routers multicast address" - There is also a case for being able to send unicast as it is possible the host has discovered which router it wishes to join the network through by other means, e.g. 802.15.4 beacon request. This could potentially limit traffic. Section 5.8.2 also says it can be sent unicast.

Will look into this.

> 
> page 19:
> 
> "This includes the Context ID, the prefix" - Possibly some confusion between the context prefix and the prefix in the PIO. Maybe clarfication on the terminology is needed.

Will try to clarify overall.

> 
> page 21:
> 
> "or the appropriate IP-over-foo document" - Is this a well-known phrase in the IETF community? :-)

Yes ;-)

> 
> page 25:
> 
> "then care should be taken to ensure that there isn't a flood of ARO-carrying messages **sent** to the 6LBR as each router hears an ARO from their neighboring routers" - Is this likely to happen with a unicast to 6LBR? (** typo 'send' -> 'sent' **)

Some proposals are currently being considered for limiting the amount of NSs.

> 
> page 28:
> 
> "then the RA MUST be silently ignored" - "Silently ignored" is a tautology. Either "silently discarded" or simply "ignored"

Silently ignored is more common in IETF terminology.

> 
> page 29:
> 
> "The routers periodically send Router Advertisements" - "may periodically send"? It is optional, isn't it? Also might be worth mentioning this information could be disseminated by other mechanisms.

Periodic sending is a must for Section 8.1 to ensure new information is disseminated. Section 8.1 already makes it clear that this mechanism is optional and e.g. a routing protocol might already do this. 

> 
> page 30:
> 
> 8.2.1. Special Message Validation - This is a rather complex rule for NS/NA processing as the hop limit processing may well happen before payload processing. Could it be made simpler or more logical?

We didn't find anything particularly hard there. 

> 
> page 31:
> 
> "It proceeds to look for the Registration Address in the DAD Table.  If an entry is found and the recorded EUI-64 is different than the EUI-64 in the ARO, then it returns an NA with the ARO Status set to 1 ('Duplicate Address').  Otherwise it returns an NA with ARO Status set to zero." - It would be really nice if it could also return a 'suggested address'. This would complete address assignment without the host having to guess again.

We had the ability to request an address in previous nd versions, but that was removed due to push-back from people thinking that the point here was address assignment (which it was not). We don't think it is wise to start adding that kind of feature here again (although personally I would find it useful). In the end, this process is only done the first time a node registers a short address on the LoWPAN so the overhead from trying again in case of a duplicate should not be significant. 

Zach

> http://www.gridmerge.com
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 30 May 2010 06:08:35 -0700

> We decided it might take a whole bunch of text to discuss all the issues that might happen with duplicate EUI-64s. For this spec we simply assume that EUI-64s are unique thus we don't try to detect…

Just to clarifiy, this stance isn't just because we are lazy.

I believe that detecting cloned/spoofed hosts in a 6lowpan environment 
is impossible. We assume that the clone is identical to the original 
host. Thus not only is the EUI-64 identical, but any other factory or 
configuration information is assumed to be identical.

Suppose a simple topology with a single 6LBR, and the original and 
cloned hosts attach to this 6LBR.
1. How can the 6LBR tell the difference between a packet from the 
original and the clone? It can't, because they look the same and they 
arrive on the same interface on the 6LBR. For instance, if it receives a 
packet from the original with a high signal strength, and a millisecond 
later receives a low strength packet from the clone, that wouldn't 
indicate they there are two different hosts since the change in signal 
strength could happen with a single host and changing radio conditions.

2. Can the 6LBR do some challenge-response against the host(s) to see 
whether there is one host or two? That doesn't seem possible since the 
6LBR can choose to target a transmission to only one of them (they are 
both within radio range and use the same MAC address). Thus any 
challenge would be heard by both of the hosts, and in many cases the 
clone might hear the response from the original host (and vice versa).

Note that there other types of networks can detect duplicates.
For example, if a cell phone is in Chicago and San Francisco at the same 
time one can assume that one of them is a clone.
Or if the same source MAC address appears on different wired Ethernet 
switch ports at the same time, then it is probably a duplicate (or could 
be a single host which has two NICs, or that disconnected and the 
reconnected to the switch). In this case, the Ethernet switch can target 
some form of challenge by selectively sending out each of the ports, to 
be able to tell whether it is a move, a dual-attached single host, or a 
case of two hosts.
If the link-layer creates some form of session keys as part of some 
association protocol, then I suspect one can also tell the there is a 
clone. But I don't know if anybody has studied the security of such 
approach.
In any case, we assume none of those capabilities for 6lowpans.

    Erik