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

Mailman List Mirror (Read Only)
1

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
© 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

2

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

3

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>------> --------<outgoing packet; link prefix = p2>------>

With RPL, the “hop” would look like as shown below:

--------<incoming packet; link prefix = p1>------ --------<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

4

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

5

I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref to RFC 5942 in section 4.4 that discusses the use of on-link flag.

Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT network such as a RPL domain, or a frame relay network with OSPFv2 NBMA / P2MP models. It takes quite a bit more than resetting the on-link flag to enable IPv6 ND on those NBMA networks, though it is indeed necessary. This is what I tried to express too concisely.

Keep safe,

Pascal

PS For NBMA, RFC 4861 clearly says

non-broadcast multiple access (NBMA)

  • Redirect, Neighbor Unreachability Detection and

next-hop determination should be implemented as

described in this document. Address resolution,

and the mechanism for delivering Router

Solicitations and Advertisements on NBMA links are

not specified in this document. Note that if

hosts support manual configuration of a list of

default routers, hosts can dynamically acquire the

link-layer addresses for their neighbors from

Redirect messages.

6

NBMA is not necessarily a one-size-fits-all category, and it looks like multiple proposals

are considering models for NBMA links. AERO and OMNI define an NBMA link model

for virtual links and do define the operation of IPv6 ND over those links in ways that

go beyond RFC5942. This is encouraged in RFC4861 where it says:

“Unless specified otherwise (in a document that covers operating IP

over a particular link type) this document applies to all link types.

However, because ND uses link-layer multicast for some of its

services, it is possible that on some link types (e.g., Non-Broadcast

Multi-Access (NBMA) links), alternative protocols or mechanisms to

implement those services will be specified (in the appropriate

document covering the operation of IP over a particular link type).”

Fred