(limited to the 6lowpan mailing list) On May 6, 2010, at 20:38 , Robert Cragie wrote:
> Hi Zach, > > I agree with some of what you say but not all of it. See inline comments. In > a nutshell: > • We need ND for bootstrapping hosts and routers and to maintain hosts. > I think nd-09 supports this well > • Hosts do not need to know anything about routing protocol used in the > wider network > • There is nothing wrong with using RPL's (or any other routing > protocol) implicit multicast mechanism for disseminating lowpan wide > information Exactly, well summarized. Now regarding one point below: > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 (0) 1924 910888 > http://www.gridmerge.com > > > On 05/05/2010 4:42 PM, Zach Shelby wrote: >> Hi, >> >> On May 5, 2010, at 17:18 , Mathilde Durvy (mdurvy) wrote: >> >> >> >>> Hi Pascal, >>> >>> I fully agree with you. >>> In my opinion anything spanning multiple IP hops should not be done by ND. >>> >>> >> That logic doesn't work anymore with route-over LoWPANs. As the prefixes are >> spanning the whole LoWPAN there is a natural need for ND to help with that. > <RCC>(1) I repeat - classic ND has no concept over this, so there isn't a > natural need for ND to help with this. There has been a choice to add in a > mechanism but that mechanism is a 'multicast' mechanism which implicitly has > to define propagation. Propagation is not the domain of ND but is the domain > of the associated routing protocol</RCC> Here is the critical difference. IPv6 has no concept of a prefix being used multihop across multiple routers in the same subnet, which is why RFC4861 never dealt with it. A route-over LoWPAN is special in the way that the same prefix and context information needs to be synchronized multihop. This is not the case with IPv6 where you instead do prefix delegation to routers, thus each router advertises a different prefix. As this flat prefix propagation is special to 6LoWPAN, it is really a 6LoWPAN problem. This is the reason why an optional solution for it simply using RS/RA is included in nd-09 (and in most previous versions of nd as well). Now, as we all seem to agree, a routing protocol could handle the task of getting prefix and context information to 6LRs... but then it needs something pretty 6LoWPAN specific there... General routing protocols designed for IPv6 (DYMO, AODV etc.) won't do this for you, thus in that case 6lowpan-nd has a mechanism that can be used. The challenge in ROLL would be how to support both IPv6 prefix delegation and 6LoWPAN prefix/context dissemination without being 6LoWPAN specific? That will be the real issue to discuss on the ROLL mailing list I guess. Zach -- Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
