Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)

[Etienne-Victor Depasquale <edepa () ieee org>]

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) <
pthubert () 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 <edepa () 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) <
> pthubert () 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 <cabo () 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