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: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
