Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative.
You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Etienne Victor > > Maybe you’re confusing link and a subnet? > > This is discussed at length here: > > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ > > RPL can route inside a subnet using host routes. This is how a multi link > subnet can be made to work... > > Please let me know if the draft above helped and whether it is clear > enough. The best way for that discussion would be to cc 6MAN. > > Keep safe, > > Pascal > > Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <ed...@ieee.org> a > écrit : > > > Thank you Carsten, and thank you Pacal. Your replies are valuable and > packed with insight. > > I'll wrap up with how I interpret RPL's behaviour in terms of IP hops. > > On one hand, RFC6775 defines a route-over topology as follows: > "A topology where hosts are connected to the 6LBR through the use of > intermediate layer-3 (IP) routing. > Here, hosts are typically multiple IP hops away from a 6LBR. > The route-over topology typically consists of a 6LBR, a set of 6LRs, and > hosts." > 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. > > On the other hand, there at least two contradictions (which I justify > after stating them): > (a) RFC6550 states that "RPL also introduces the capability to bind a > subnet together with a common prefix and to route within that subnet." > (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). > > 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*** : > > --------<incoming packet; link prefix = p1>------><router> > --------<outgoing packet; link prefix = p2>------> > > With RPL, the "hop" would look like as shown below: > > --------<incoming packet; link prefix = p1>------<router> > --------<outgoing packet; link prefix = p1>------ > > There seems to be a change in the meaning associated with "IP hop". > 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. > Then again, calling the RPL device involved in the packet forwarding by > the name "router" feels like an uncomfortable stretch. > Don't routers sit at the meeting point of different layer 2 links? > > > Cheers, > > Etienne > > On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) < > pthub...@cisco.com> wrote: > >> Hello Etienne >> >> 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. >> >> Some of us cared about the interworking. >> >> Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure. >> >> Keep safe, >> >> Pascal >> >> > Le 29 mai 2020 à 20:28, Carsten Bormann <c...@tzi.org> a écrit : >> > >> > 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 >> > >> > > > -- > 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 > > -- 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
