Hi: I posted support for this draft to the WG mailing list. At the same time, I regretted the lack of a sequence counter in the registration mechanism. Ralph suggested that I share my concerns in this step of the review process.
The sequence counter existed in earlier versions of the draft and was called a TID (see http://tools.ietf.org/html/draft-ietf-6lowpan-nd-08#page-18). Similar sequence counters exist in other registration mechanisms such as MIPv6. The sequence counter is useful for: 1) anti-replay 2) correlation of requests and responses in case messages cross (e.g. in mesh under) 3) mobility support (when radio conditions change, a device might need to select an alternate router) Items 1 and 2 were not enough to convince the authors to keep the TID, and item 3 is somewhat an external to the specification. Yet, item 3 is the one I'm most concerned with, because it is required in order to inject the registration in a routing protocol such as RPL, or over a backbone in an ND proxy operation as was supported in earlier versions of the draft (till 8). In the case of RPL, the path sequence in the transit option is used to determine which path is stale after a movement as described in http://tools.ietf.org/html/draft-ietf-roll-rpl-19#section-9.2.1 . The TID would be trivially mapped into that path sequence but cannot be regenerated by the attachment router should the device move. IOW, without a TID, a device must be hardwired to its router for RPL to operate properly. RPL is very explicit about that limitation in section 7.1: " If a host does not pass a counter to its router, then the router is in charge of computing the Path Sequence on behalf of the host and the host can only register to one router for that purpose. " In the case of the backbone router that is now discussed separately from ND in http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02, we want a transparent mobility for the constrained device, so we need a mechanism to determine the freshest of conflicting registrations. The backbone routers would use the TID to figure which registration is freshest and determine which router should proxy over the backbone. In any case, it appears that though the ND mechanism could probably live without a sequence counter in most cases, a sequence counter is quite critical for the global integration of the protocol in a multi-hop radio infrastructure. What do you think? Pascal -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of The IESG Sent: vendredi 16 décembre 2011 22:02 To: IETF-Announce Cc: [email protected] Subject: Last Call: <draft-ietf-6lowpan-nd-18.txt> (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard The IESG has received a request from the IPv6 over Low power WPAN WG (6lowpan) to consider the following document: - 'Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)' <draft-ietf-6lowpan-nd-18.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email protected] mailing lists by 2012-01-04. Exceptionally, comments may be sent to [email protected] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks. The document, thus updates RFC 4944 to specify the use of the optimizations defined here. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
