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

[Etienne-Victor Depasquale <[e-mail]>]

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) <
[e-mail]> 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 <[e-mail]> 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) <
> [e-mail]> 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 <[e-mail]> 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