Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Feb 2011 16:57:30 +0100

In September/October, we had the first WGLC on 6LoWPAN-ND, which
resulted in a number of detailed comments and two resulting
fine-tuning iterations of the draft.

draft-ietf-6lowpan-nd-15.txt has been out for two months now.
I understand it has taken part in several interops with multiple
implementations in this period; no issues came up.

We now start the Working Group Last Call on:

   http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15

The document is planned to be submitted by this Working Group to the
IESG for publication as a Standards-Track Document.

This is a two-week Working-Group Last-Call, ending on Thursday,
2011-03-03 at 2359 UTC.

Please review the changes to the document carefully once more, and
send your comments to the 6lowpan list.  Please also do indicate to
the list if you are all-OK with the document.

Gruesse, Carsten

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 17 Feb 2011 10:36:26 -0800

Hi Carsten,

The ZigBee Alliance, as part of development of our IEEE 802.15.4 based IP
stack, has been using draft-ietf-6lowpan-nd since January 2010.  We have 10
companies performing interoperability testing and have held 10 test events
since last January.

We held a test event in December 2010 and are currently at a test event now
and have not run across any issues with ND-15 (the December 2010 event
actually used ND-14 but there were few changes with ND-15).

I have attached a test plan we use for our testing of ND.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: Thursday, February 17, 2011 7:58 AM
To: 6lowpan
Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15

Gruesse, Carsten

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Feb 2011 17:11:14 +0100

Hi Carsten:

My main issue with ND 15 has to do with the role of the 'L'=='on-link'
flag. 

1) The text seems to indicate that the 'L' it determines whether
classical ND or ND registration per this draft should be used

"
   When a host has configured a non-link-local IPv6 address, it
   registers that address with one or more of its default routers using
   the Address Registration option (ARO) in an NS message.
"
I think that the 'L' bit can be reset in environments where ARO is not
wanted. Further, I think that registration is useful in many
environments, even Ethernet, where you do want to set the 'L' bit.
As a consequence, I think 6LowPAN ND should define a new PIO 'W' bit to
indicate whether ARO should be used or not, regardless of whether a node
may look up another node on-link or not.

2) The text also indicates that if there are PIOs with and without 'L'
set, then reset wins. 
That's an interesting rule but then, what if the PIO with 'L' set is
received before the L reset?
And BTW how does a host erroneously receive something? Like the postman
was too busy?
"
   Should the host erroneously receive a Prefix Information option with
   the 'L' (on-link) flag set, then that Prefix Information Option (PIO)
   MUST be ignored.
"
I think that the text should stay away from L bit. If a new 'W' bit is
defined, then I suggest that as soon as the  node receives a PIO with
the 'W' but then it MUST register all its addresses that are based on
that prefix.

Note on the side that RPL extends the meaning of 'L' bit when used
router to router in RPL's PIO, and that it is valid to set the 'L' bit
there.

Pascal
http://www.xtranormal.com/watch/7011357/

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carsten Bormann
> Sent: Thursday, February 17, 2011 4:58 PM
> To: 6lowpan
fine-tuning
> iterations of the draft.
IESG
> for publication as a Standards-Track Document.
> 
send
> your comments to the 6lowpan list.  Please also do indicate to the
list if you
> are all-OK with the document.
> 
> Gruesse, Carsten
>

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Feb 2011 11:10:13 +0100

Having read the doc carefully, I have a question:

The doc is somewhat scizophrenic whether it accepts that a link layer
can
guarantee unique short addresses.
Assumption #6 in section 1.3 seems to say "OK"
Section 3.2 says that if I do not use DHCPv6 (M flag = 1) I MUST use
DAD.
I would like this softened to
"MUST use DAD if the LOWPAN cannot guarantee unique short addresses"

Thanks,
  Anders

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
Sent: 17. februar 2011 16:58
To: 6lowpan
Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Feb 2011 11:17:40 +0100

Section 5.2 says "A host MUST join the all-nodes multicast address"

Does this mean:
"A host must use some multicast control signaling protocol to inform the
default router that it wants to receive traffic sent to the all-nodes
multicast address.
The host must accept messages sent to the all-nodes multicast address"

OR:

"A host must accept messages sent to the all-nodes multicast address
within the link-local range of the host"

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Feb 2011 11:42:12 +0100

Having read the doc carefully, I have a comment:

Section 5.8 addresses sleeping nodes.
While I agree with the text in this section it seems to me that the
description does not cover an important battery host category:

* The frequently listening node (FLN)

In a non-storing routing environment like the one we are specifying in
RPL-P2P in the ROLL WG, we have the option of issuing a reactive
discovery request when needing to get in touch with a host on short
notice. This is a major requirement for real users in home control and
building automation.

The abovementioned FLN is a battery powered
host that can be reached with semi-low latency. The typical use is
installations where wires would be hard to install without affecting
the architectural appearance. Examples include wireless window drape
controllers and electronic door locks.
802.15.4 and Z-Wave have different link-layer solutions for this but
the user experience is the same: Reaction within a second or less.

If an originating node (keyfob or remote control) has lost all its
working routes to a FLN, it must re-discover a source route to the FLN.
But the FLN is sleeping.
I would like a flag in the ARO: "advertise on behalf".
If set, a default router may use the neighbor information to respond
to discovery requests. The actual response format obviously depends
on the actual routing protocol. RPL-P2P is just my actual example.
Thus, how the default router uses the information is out of scope of
the ND spec.

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Feb 2011 11:58:17 +0100

One more thing on ND:

It is obvious that default routers need to know the link layer address
of
a host in order to resolve its IP address. It is however a little more
unclear to me why a host has to deliver the link layer address in a
special SLLA field?

(BTW: As a new reader I may read the term SLLA four times before finding
the
full wording in section 5.5.1 ;-)    )

I suppose the link-layer address of the originating node is already in
the
link-layer header?
Is the purpose solely DAD? If so, a few more words may serve to guide
the reader...

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Feb 2011 14:05:11 +0100

Hi Pascal

Has it been considered how a tunneling source routing header may be
compressed?

(sorry if this question was answered already)

Thanks,
  Anders

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 25 Feb 2011 14:28:49 +0100

Hi Anders,

RFC4861 uses the same wording, where it means you just listen on the
all-nodes multicast address. There is no explicit join method.

I'm not sure in which RFC it describes joining the multicast group. I would
guess RFC4291 as that describes multicast addressing, but there might be
somewhere better.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Anders Brandt
Sent: February 25, 2011 11:18 AM
To: [email-masked]; 6lowpan
Subject: [6lowpan] -nd-15: Joining the all-nodes multicast address

Does this mean:

OR:

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Feb 2011 14:32:04 +0100

Hi Colin

Thanks

> There is no explicit join method.
That's what I thought.

"Join" just sounded like a rather active thing to me...

Cheers,
  Anders

-----Original Message-----
From: Colin O'Flynn [mailto:[email-masked]] 
Sent: 25. februar 2011 14:29
To: Anders Brandt; [email-masked]; '6lowpan'
Subject: RE: [6lowpan] -nd-15: Joining the all-nodes multicast address

Hi Anders,

I'm not sure in which RFC it describes joining the multicast group. I
would
guess RFC4291 as that describes multicast addressing, but there might be
somewhere better.

Regards,

  -Colin

-----Original Message-----
Behalf

Does this mean:

OR:

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 25 Feb 2011 14:41:53 +0100

Hi Anders,

I'm still reading through -15 too, so just wanted to add other comments.

I think part of the problem is you can register any address you want, not
necessarily one based on a MAC address. EUI64-based addresses can be
globally unique, so you can reliably skip DAD on those.

An address generated from a MAC address, if that MAC address is not globally
unique, could potentially collide with another address.

This is very unlikely, as someone would have to randomly choose an IPv6
address in the same space as your MAC-address-derived space.

If you had a closed network where you don't have the 'idiot node' picking
addresses randomly in your space, you could skip DAD. But I think if you had
such a closed network you wouldn't care enough about sticking to the RFCs
anyway.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Anders Brandt
Sent: February 25, 2011 11:10 AM
To: [email-masked]; 6lowpan
Subject: [6lowpan] -nd-15: DAD requirement seems too strict

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Feb 2011 14:53:08 +0100

Hi Colin

>If you had a closed network where you don't have the 'idiot node'
>picking addresses randomly in your space, you could skip DAD. But
>I think if you had such a closed network you wouldn't care enough
>about sticking to the RFCs anyway.

To some extent this ties to the link-layer bootstrapping process.
I know at least one link-layer technology which does guarantee
unique link layer addresses.
Still, I consider the ND doc highly useful and see several reasons
for sticking to it if possible.

And anyway, the document seems to be in conflict with itself on
this issue ...

Cheers,
  Anders

-----Original Message-----
From: Colin O'Flynn [mailto:[email-masked]] 
Sent: 25. februar 2011 14:42
To: Anders Brandt; [email-masked]; '6lowpan'
Subject: RE: [6lowpan] -nd-15: DAD requirement seems too strict

Hi Anders,

I think part of the problem is you can register any address you want,
not
necessarily one based on a MAC address. EUI64-based addresses can be
globally unique, so you can reliably skip DAD on those.

An address generated from a MAC address, if that MAC address is not
globally
unique, could potentially collide with another address.

If you had a closed network where you don't have the 'idiot node'
picking
addresses randomly in your space, you could skip DAD. But I think if you
had
such a closed network you wouldn't care enough about sticking to the
RFCs
anyway.

Regards,

  -Colin

-----Original Message-----

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 1 Mar 2011 01:03:43 -0600 (CST)

Hi Anders

>Thus, how the default router uses the information is out of scope of

A very good point.

Normally, a 6lowpan host would use the ARO in NS/NA messages to register its address with one or more 6LRs. But, section 6.5.5 in nd-15 draft allows two 6LRs to learn each other's link layer addresses using the ARO mechanism. So, it seems that a registered NCE in a 6LR does not necessarily refer to a 6lowpan host and this 6LR, if it is running RPL, can not advertize this NCE address in its DAO or respond to RPL-P2P route discovery messages listing this NCE address as the target.

The ARO flag you mentioned will solve this problem. The 6lowpan hosts would set this flag in the AROs they send, whereas the 6LRs wont.

Thanks
Mukul

----- Original Message -----
From: "Anders Brandt" <[email-masked]>
To: [email-masked], "6lowpan" <[email-masked]>
Sent: Friday, February 25, 2011 4:42:12 AM
Subject: [6lowpan] -nd-15: Battery host support seems to be incomplete

Thanks,
  Anders

-----Original Message-----

Gruesse, Carsten