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

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 2 Mar 2011 18:01:44 +0100

Dear authors, all,

Here are my comments/questions regarding the 6lowpan-nd-15 draft. In general the document looks in good shape.

1)  Parts on multicast may benefit from some more clarification:
section 5.1 "A host would never multicast" -> is this "A host MUST NOT multicast" or SHOULD NOT ?

section 5.6 "Multicast addresses are considered to be on-link and are resolved as specified in [RFC4944] or the appropriate IP-over-foo document."
However section 5.7 says "As all prefixes but the link-local prefix are always assumed to be off-link, multicast-based address resolution between neighbors is not needed",  implying the contrary that multicast addresses are always off-link. Does this conflict?
Also, section 5.6 appears to refer to RFC 4944 Section 9, which is only applicable for mesh-under configurations. What about multicast in route-over configurations?  (Should it be made more explicit here?)

Finally, the text in 5.6  "All other prefixes are assumed to be off-link [RFC5889]" should perhaps be moved lower, so that it indicates the final case of this section. I.e. to first describe the special cases, then finally describe the "all other" case would be clearer I think.

2) Registration lifetime calculation:
 section 5.8.2. mentions "the maximum Registration lifetime is about 7 days".  Taking 65535 units of 60 seconds however, I find 45.5 days?

3)  Finally, some typos & minor remarks:

section 1.3 last paragraph: "involunterily"
"NCE" abbreviation is not defined on first use, also not used in RFC 4861, so should perhaps be defined here.

section 1.4 "messages in host-router interface and" -> "messages in host-router interfaces and" ?
"multhop" -> multihop

section 3.1 "mechanism using new Address" ->"mechanism using a new Address"

section 3.5 "As Routers send RAs to hosts, and when routers optionally receive RA messages or receive multicast NS messages from other Routers the result is Garbage-collectible NCEs."
-> Maybe more clear using:  "When Routers send RAs to hosts, and when routers optionally receive RA messages or receive multicast NS messages from other Routers, the result is Garbage-collectible NCEs."

section 4.1 "an SLLA option MUST be include" -> abbreviation "SLLA" is not defined on first use. Also not used in RFC 4861 main text, so could be defined here.

section 5.5 (last sent.) "use a router it is registered, it" -> "use a router it is registered to, it"

overall:  The text "section section" appears a few times.

best regards,
Esko

Esko Dijk

Philips Corporate Technologies, Research
High Tech Campus 34, Eindhoven, The Netherlands
[email-masked]

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

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

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

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Mathieu Goessens <[email-masked]>
Date: Thu, 03 Mar 2011 20:11:59 +0100

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

Hi folks,

Got two remarks about the actual draft:
- a first remark about the lifetime in AROs
- a second about the behavior on wake up section.

= About the lifetime in AROs =

I don't see anything on the draft to enforce on the router's side that 
ARO.lifetime <= prefix.lifetime ;

The host is not expected to use a greater lifetime. However in some 
cases the actual valid lifetime may have changed since the last RA 
received from the router, especially when the host renews the 
registration of an address (the draft does not mandate to send a RS in 
this case).

The router is not mandated to check that the lifetime of the registered 
address fits within the valid lifetime of the prefix. Can a router 
refuse a registration with a too long lifetime or decrease the lifetime 
in the returned ARO (just like in DHCPv6) ?

I think we should plan a mechanism that allow a router to decrease a 
lifetime requested by a host in a ARO.

I would suggest the following mechanism: When a router receive a NS with 
an ARO, it can reply with an ARO containing a lower lifetime and the 
host must honor this lifetime.

I would suggest the following changes:

== Section 5.5.2.  Processing a Neighbor Advertisement ==

 > If the status field is zero, then the address registration was
 > successful.  The host saves the Registration Lifetime from the
 > Address Registration option for use to trigger a new NS
 > well before the lifetime expires.  If the Status field is not equal
 > to zero, the address registration has failed.

Becomes:
"
If the status field is zero, then the address registration was 
successful.  As the routeur may have decreased the lifetime of the 
address, the host MUST use the Registration Lifetime returned by the 
router in the Address Registration option received in the NS for use to 
trigger a new NS well before the lifetime expires. If the Status field 
is not equal to zero, the address registration has failed.
"

== Section 6.5.  Processing a Neighbor Solicitation ==

 > In addition to the normal validation of a Neighbor Solicitation and
 > its options, the Address Registration option is verified as follows
 > (if present).  If the Length field is not two, or if the Status field
 > is not zero, then the Neighbor Solicitation is silently ignored.

Becomes:
"
In addition to the normal validation of a Neighbor Solicitation and its 
options, the Address Registration option is verified as follows (if 
present).  If the Length field is not two, or if the Status field is not 
zero, then the Neighbor Solicitation is silently ignored.

If the requested lifetime is greater than the prefix lifetime, the 
router MUST decrease it in order to fit within the prefix lifetime. This 
change MUST be done before updating the Neighbor Cache Entry and sending 
subsequent DAR or NA message.
"

== Section  6.5.3.  Updating the Neighbor Cache ==

 > The Registration Lifetime and the EUI-64 are recorded in the
 > Neighbor Cache entry.  A unicast Neighbor Advertisement (NA) is then
 > sent in response to the NS.  This NA SHOULD include a copy of the
 > ARO, with the Status field set to zero.  A TLLA option is not
 > required in the NA, since the host already knows the router's
 > link-layer address from Router Advertisements.

Becomes:
"
The Registration Lifetime and the EUI-64 are recorded in the Neighbor
Cache entry.  A unicast Neighbor Advertisement (NA) is then sent in
response to the NS.  This NA SHOULD include a copy of the ARO, with
the Status field set to zero. If the router had to decrease the lifetime 
of the address, then the ARO option MUST be included to report the 
decreased lifetime to the host.
"

Please also note that it may be interesting to make similar changes in 
DAC/DAR and to update section 5.8.1. (Picking up an appropriate 
registration lifetime)

= About the behaviour on wake up section (5.8.2): =

I think this sentence

 > When a host wakes up from a sleep period it SHOULD maintain its
 > current address registrations that will timeout before the next
 > wakeup.

needs some clarifications.

Even if it's implicit, it doesn't stress enough that a node must 
maintain its addresses before switching to sleep mode in order to be 
able to retrieve it at wake up time. One may consider it just have to do 
so when a node wakes up.

I propose the following sentence that seems more clear to me :

"
When a host plans to switch to sleep mode, it SHOULD maintain its 
current address registrations to ensure that they will not timeout 
before the next wakeup.
"

Also, i am not sure how to interpret the sentence:

 > The
 > host may also need to refresh its prefix and context information by
 > sending a new unicast Router Solicitation

Does it mean that it is left to the implementation to decide wether a 
host refresh its information or not ?

Best Regards,

-- 
Mathieu Goessens,
IRISA, Campus de Beaulieu, 35042 Rennes cedex, France
Tel: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71

---

From: "Noriyuki SATO" <[email-masked]>
Date: Tue, 8 Mar 2011 17:06:13 +0900

Hi all,
This is just a question rather than a comment since the WGLC period is
already over and a matter is really old one. I thought the old draft (before
08 or 07) has a concept of a conjunction of the mesh under and the route
over. However, it looks to me the current draft implicit that there isn't a
concept like that anymore. (Ex. Route over runs among LRs and each LR has
mesh under network individually.)

Am I missing something? Or the document still allows it? Apologize if the WG
already has a consent regarding this.

---
OKI Electric Industry Co., Ltd.
Noriyuki Sato ([email-masked])
Tel +81-6-6260-0700
Fax +81-6-6260-0770

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

Gruesse, Carsten

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Mar 2011 04:15:13 -0700

On 2/25/11 5:28 AM, Colin O'Flynn wrote:
> 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.

It is in RFC 2710 on MLD; it describes that "join" implies.

MLD has an explicit exception for all-nodes as in
    The link-scope all-nodes address (FF02::1) is handled as a special
    case.  The node starts in Idle Listener state for that address on
    every interface, never transitions to another state, and never sends
    a Report or Done for that address.

For other multicast addresses, including link-locals, the expectation is 
that the host would join using MLD.

Note that 6lowpan-nd doesn't require hosts to join the solicited node 
multicast address; that would have required sending MLD reports to 
comply with RFC 2710.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Mar 2011 02:15:27 -0700

Erik

> Regards,
>    -Colin
> Of Anders Brandt
> Sent: February 25, 2011 11:18 AM
> To: [email-masked]; 6lowpan
> Subject: [6lowpan] -nd-15: Joining the all-nodes multicast address
>
> Having read the doc carefully, I have a question:
>
> 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
>
> Sent: 17. februar 2011 16:58
> To: 6lowpan