RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
Hello folks, I'm not sure whether this is within scope as it regards LoWPANs ... please chastise freely and ignore if LoWPANs are out of scope. While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents. I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs), it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section. For example: (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS) (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550 (c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops. Can anyone confirm or contradict this impression? Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Hi Etienne, I’m also not sure many of the classical network operators assembled in NANOG work with 6LoWPANs today, but I still can answer your question.
While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents.
I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs), it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section.
Yes, you could say that. ND (Neighbor discovery) describes interfaces between hosts and between hosts and routers. 6LoWPAN-ND does not use host-to-host interfaces (different from Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in the L — on-link — bit, which isn’t set in 6LoWPAN-ND). RFC 6550 was completed at a time when many people who came in from the WSN (wireless sensor network) world thought they could get away with a network that is wholly composed of routers. Even the “leaf” nodes in the RPL world were participating in the routing protocol and therefore didn’t really need a host-router interface. There was no separate host-router interface in that world, because there were no non-router hosts.
(a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS)
Right, DIO and DAO are router-to-router messages. If there are no hosts (and routers don’t bootstrap themselves as hosts), you don’t need ND.
(b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550
RFC6550 is route over by definition. Actually, the term was coined by the people working closely with the RPL development; RFC 6775 does appropriate it as 6LoWPAN-ND is applicable in either case.
(c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops.
I’m not sure where you get this interpretation: RFC 6550 (RPL) is very much about IP hops. Maybe you mean the address architecture that was defined explicitly in RFC 6775; RFC 6550 does not really say much about addresses. Note that the RPL people have since proceeded to (at least partially) embrace the host-router concept from the IP architecture; RFC 8505 is an update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people. I have CCed Pascal Thubert who, as a co-author to all three RFCs, certainly will have another perspective on this. Grüße, Carsten
participants (2)
-
Carsten Bormann
-
Etienne-Victor Depasquale