<div dir="ltr">Thank you Carsten, and thank you Pacal. Your replies are valuable and packed with insight.<div><br></div><div>I'll wrap up with how I interpret RPL's behaviour in terms of IP hops.</div><div><br></div><div>On one hand, RFC6775 defines a route-over topology as follows:</div><div>"A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. </div><div>Here, hosts are typically multiple IP hops away from a 6LBR. </div><div>The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts."</div><div>If RPL is route-over by definition, then RFC6775 would imply that there are typically multiple IP hops between a leaf and the border router.</div><div><br></div><div>On the other hand, there at least two contradictions (which I justify after stating them):</div><div>(a) RFC6550 states that "RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet."</div><div>(b) Reduction of a DODAG to a single subnet prefix, albeit only only one parent-child relationship deep, is clearly shown at Contiki-NG's Github page (deep dive section).</div><div><br></div><div>The hinge on which my understanding revolves is that an IP hop traverses a router and ***results in a change of prefix of the link on which the packet travels*** :</div><div><br></div><div>--------<incoming packet; link prefix = p1>------><router>

--------<outgoing packet; link prefix = p2>------></div><div><br></div><div>With RPL, the "hop" would look like as shown below:</div><div><br></div><div>  --------<incoming packet; link prefix = p1>------<router>

--------<outgoing packet; link prefix = p1>------  <br></div><div><br></div><div>There seems to be a change in the meaning associated with "IP hop". </div><div>I guess that I can reconcile both cases through the observation that RPL actually does apply to a single, NBMA link and therefore the IP prefix ***is*** the same.</div><div>Then again, calling the RPL device involved in the packet forwarding by the name "router" feels like an uncomfortable stretch. </div><div>Don't routers sit at the meeting point of different layer 2 links?</div><div><br></div><div><br></div><div>Cheers,</div><div><br></div><div>Etienne</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) <<a href="mailto:pthubert@cisco.com" target="_blank">pthubert@cisco.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Etienne <br>
<br>
You may see ND as the host to * interface for any network and RPL as the router to router interface when the network is NBMA.<br>
<br>
Some of us cared about the interworking. <br>
<br>
Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure.<br>
<br>
Keep safe,<br>
<br>
Pascal<br>
<br>
> Le 29 mai 2020 à 20:28, Carsten Bormann <<a href="mailto:cabo@tzi.org" target="_blank">cabo@tzi.org</a>> a écrit :<br>
> <br>
> Hi Etienne,<br>
> <br>
> 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.<br>
> <br>
>> While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents.<br>
>> <br>
>> 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),<br>
>> it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section.<br>
> <br>
> Yes, you could say that.<br>
> <br>
> ND (Neighbor discovery) describes interfaces between hosts and between hosts and routers.<br>
> 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).<br>
> <br>
> 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.<br>
> 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.<br>
> <br>
>> (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS)<br>
> <br>
> 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.<br>
> <br>
>> (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550<br>
> <br>
> 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.<br>
> <br>
>> (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.<br>
> <br>
> I’m not sure where you get this interpretation: RFC 6550 (RPL) is very much about IP hops.<br>
> Maybe you mean the address architecture that was defined explicitly in RFC 6775; RFC 6550 does not really say much about addresses.<br>
> <br>
> 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.<br>
> <br>
> I have CCed Pascal Thubert who, as a co-author to all three RFCs, certainly will have another perspective on this.<br>
> <br>
> Grüße, Carsten<br>
> <br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Ing. Etienne-Victor Depasquale</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Assistant Lecturer</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Department of Communications & Computer Engineering</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Faculty of Information & Communication Technology</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">University of Malta</span><div>Web. <a href="https://www.um.edu.mt/profile/etiennedepasquale" target="_blank">https://www.um.edu.mt/profile/etiennedepasquale</a><br></div></div></div>