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

[Mathieu Goessens <[e-mail]>]

On 17/02/2011 16:57, Carsten Bormann wrote:
> We now start the Working Group Last Call on:
>
>     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: [phone], Fax: [phone]