Hi Erik, Samita, Thanks for your draft. This proposal is much closer to what I had in mind myself and I feel this is a great step forward!
I have a few questions / comments: - Assumptions: why do you assume that 6LR use RA to configure their global addresses while host are allowed to use DHCPv6? In IPv6, routers are typically ignoring received RAs... It is not very clear whether your proposal allows the case where all addresses (host and 6LR) are assigned using DHCPv6. It might also be that in a route-over situation the routing protocol itself would take care of distributing well chosen prefixes/addresses to allow prefix aggregation in routing tables or routing messages. - Is there any relation between the concept of 'node lifetime' and 'reachable time'? Couldn't you achieve the same effect by setting high values for the reachable time? - Section 7.3: I feel like you are underestimating the role that the routing protocol might play. If you take the example of what RPL is defining, an IPv6 host could very well be a RPL leaf node, in which case it might discover its default router by listening to DIO messages, and send DAO to 'register'. In addition, if the 6LR are RPL routers that use DHCPv6 or another scheme for address allocation, RS/RA might be completely disabled. What do you think? - Section 7.3: Reading your description, is it correct to say that hosts perform NUD and address resolution for their default router? (of course the number of messages is reduced by the heavy use of the SLLA option). Do you also use NS/NA to perform NUD and address resolution between 6LR? - Section 7.3: ND uses already upper-layer protocol feedback. Would you consider to extend it to include lower layer feedback? To summarize my comments, I would like to understand a bit better how you envision the operation of nd-simple when a routing protocol such as RPL is used on top of it. Best, Mathilde -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Erik Nordmark Sent: lundi, 1. mars 2010 05:17 To: 6lowpan Subject: [6lowpan] Fwd: New Version Notification fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00 Samita and I have tried to capture a minimal set of ND optimizations in this draft. Erik -------- Original Message -------- A new version of I-D, draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt has been successfuly submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-chakrabarti-6lowpan-ipv6-nd-simple Revision: 00 Title: IPv6 LoWPAN Neighbor Discovery and Addressing Choices Creation_date: 2010-03-01 WG ID: Independent Submission Number_of_pages: 16 Abstract: IETF 6LoWPAN working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 and other low-power wireless networks have limited or no usage of broadcast or multicast signaling due to energy conservation. Besides the wireless nodes may not strictly follow traditional concept of IP subnet and IP-links while connecting nodes and routers. This document describes simple optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and addressing mechanisms that are useful for small scale 6LoWPAN networks in star and mesh topologies. The optimizations include reducing the amount of Neighbor Discovery multicast traffic and allowing for a single subnet to span multiple routers in a "route-over" topology. The IETF Secretariat. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
