RFC 6997

Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks

📅 published August 2013, from ietf

Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks 🦋

Okay bestie, this is RFC 6997 🎀, published August 2013 by the Internet Engineering Task Force (IETF) 🌈. It's an Experimental document, so it's for testing and trying things out, not a Standards Track spec 🧪. The ISSN is 2070-1721. The editor is M. Goyal, Ed. from Univ. of Wisconsin Milwaukee, and the other authors are E. Baccelli and M. Philipp (INRIA), A. Brandt (Sigma Designs), and J. Martocci (Johnson Controls) ✨. The header doesn't list anything this one obsoletes or updates, so it's standing on its own 💅.

Part 1 of 9 🫶 more parts are coming, so stay tuned!

Abstract

okay so the abstract says this doc specifies a point-to-point route discovery mechanism that works alongside the Routing Protocol for Low-power and Lossy Networks (RPL) core stuff 🧚. It lets an IPv6 router find "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN), and those routes have to meet specified metrics constraints 📡. That's it, that's the whole vibe ✨.

Status of This Memo

not an Internet Standards Track spec, just published so people can examine it, implement it experimentally, and evaluate it 🧪.

it's an Experimental Protocol for the Internet community 🌸. It's a product of the IETF and represents the IETF community's consensus 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the deets 🙈.

for current status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6997 🔗.

Copyright Notice

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date 📜. Read those carefully, because they describe your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧾.

1. Introduction ....................................................4
2. The Use Cases ...................................................4
3. Terminology .....................................................5
4. Applicability ...................................................6
5. Functional Overview .............................................7
6. P2P Route Discovery Mode of Operation ..........................10
   6.1. Setting a P2P Mode DIO ....................................10
7. P2P Route Discovery Option (P2P-RDO) ...........................15
8. The P2P Discovery Reply Object (P2P-DRO) .......................18
   8.1. Secure P2P-DRO ............................................20
   8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply
        Object ....................................................21
9. P2P-RPL Route Discovery by Creating a Temporary DAG ............21
   9.1. Joining a Temporary DAG ...................................21
   9.2. Trickle Operation for P2P Mode DIOs .......................22
   9.3. Processing a P2P Mode DIO .................................24
   9.4. Additional Processing of a P2P Mode DIO at an
        Intermediate Router .......................................26
   9.5. Additional Processing of a P2P Mode DIO at the Target .....27
   9.6. Processing a P2P-DRO at an Intermediate Router ............28
   9.7. Processing a P2P-DRO at the Origin ........................30
10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) ..31
11. Secure P2P-RPL Operation ......................................32
12. Packet Forwarding along a Route Discovered Using P2P-RPL ......33
13. Interoperability with Core RPL ................................34
14. Security Considerations .......................................34
15. IANA Considerations ...........................................36
   15.1. Additions to Mode of Operation ...........................36
   15.2. Additions to RPL Control Message Options .................36
   15.3. Additions to RPL Control Codes ...........................36
16. Known Issues and Future Work ..................................37
17. Acknowledgements ..............................................37
18. References ....................................................38
   18.1. Normative References .....................................38
   18.2. Informative References ...................................38

1. Introduction ✨

okay so LLNs are the target here 🌿. The IPv6 Routing Protocol for LLNs (RPL) [RFC6550] gives you paths along a Directed Acyclic Graph (DAG) that's rooted at a single router in the network 🌳. The routers in the LLN build and maintain that DAG using Destination-Oriented DAG (DODAG) Information Object (DIO) messages 📨.

here's the tea ☕: when two random routers (neither one is the DAG's root) need to talk, the data packets are stuck only traveling along links in the DAG. That's called point-to-point (P2P) routing, and it might not be enough for home automation [RFC5826] and building automation [RFC5867] apps 🏠🏢. Two reasons:

Routes have to be pre-established. Every possible destination has to announce itself before a source needs to reach it 📣.
Routes only use DAG links. A DAG is built to optimize the routing cost to reach the root. Limiting P2P routes to in-DAG links can make routes way more suboptimal and cause severe traffic congestion near the DAG root 🚦.

so this doc describes an extension to core RPL (the RPL stuff from [RFC6550]) that lets an IPv6 router in the LLN discover routes to one or more IPv6 routers in the LLN "on demand" 🎯. The routes found might not be the very best, but they're guaranteed to meet the specified routing metric constraints. So they're "good enough" from the app's point of view 💅. This reactive P2P route discovery mechanism gets called P2P-RPL from here on 🦋.

there's also a mechanism for measuring the end-to-end cost of an existing route, specified in [RFC6998] 📏. As Section 4 talks about, measuring that cost can help you decide whether to start discovering a better route with P2P-RPL, and which metric constraints to use for it 🧐.

2. The Use Cases 🌸

first use case, super common in home [RFC5826] and commercial building [RFC5867] environments: a device (say, a remote control 🎮) suddenly needs to talk to another device (say, a lamp 💡). It doesn't have a route to the lamp yet, but it does know the lamp's network address ahead of time. So the remote control needs to find a route to the lamp "on demand" ⚡.

second use case, common in commercial buildings 🏬: a huge LLN with hundreds (or thousands!) of routers doing P2P communication along one DAG. That causes severe traffic congestion near the DAG's root 😭. So it's desirable to find direct routes between different source-destination pairs that don't go through the DAG's root 🙌.

other use cases are about energy or latency constraints that the P2P routes along an existing DAG just can't meet, because those routes go through way more routers than necessary to reach the destination 🐢.

3. Terminology 💅

the BCP 14 key words here are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". They're interpreted as described in [RFC2119] 📚.

this doc also uses terminology from [RFC6550] and [RFC6554], and more terms are in [ROLL-TERMS] 🧠. It introduces these terms:

Origin: The IPv6 router that starts the P2P-RPL route discovery 🚀.
Target: The IPv6 router at the other end of the P2P route(s) being discovered. One P2P-RPL route discovery can find routes to multiple Targets at the same time 🎯.
Intermediate Router: An IPv6 router that's neither the Origin nor a Target 🧍.
Forward direction: The direction from the Origin to the Target ➡️.
Reverse direction: The direction from the Target to the Origin ⬅️.
Forward Route: A route in the Forward direction 🛣️.
Reverse Route: A route in the Reverse direction 🔙.
Bidirectional Route: A route that can be used in both the Forward and Reverse directions 🔁.
Ingress-only Interface: A network interface that can only receive packets 📥.
Egress-only Interface: A network interface that can only send packets 📤.
Source Route: A complete, ordered list of routers that a packet can use to travel from a source to a destination node 🗺️.
Hop-by-hop Route: A route where each router on it uses its routing table to figure out the next hop 🪜.
RPL Security Configuration: The values for the Counter is Time, Security Algorithm, Key Identifier Mode, and Security Level fields, as defined in Section 6.1 of [RFC6550], inside the Security section of a secure RPL control message 🔐.

4. Applicability ✨

okay so an Origin can kick off a P2P-RPL route discovery when there's no route between itself and the Target(s), or when the routes it already has aren't good enough for the app 💅 P2P-RPL is built to find Hop-by-hop or Source Routes to one or more Targets, and those routes have to meet the constraints that were set 🎀

sometimes the app already knows what the constraints should be. bestie example: an Origin that expects its Targets to be less than 5 hops away can use hop-count < 5 🦋 other times the Origin has to measure what its current route costs first. like, an Origin that measures the total expected transmission count (ETX) along its current route to a Target and gets 20 can use ETX < x*20 as the constraint, where x is a fraction the Origin picks itself 🧚 a mechanism for measuring the cost of an existing route between two IPv6 routers is specified in [RFC6998] 📏

if there's no existing route between the Origin and the Target(s), or the cost measurement on the existing routes fails, the Origin is going to have to guess the constraints for that first route discovery 😭 but once the initial discovery succeeds or fails, the Origin has a better idea of what constraints to use next time 🌸

P2P-RPL can find better P2P routes than the ones along a global DAG that's built to optimise routing cost to the DAG's root ✨ how much better depends on a bunch of stuff: the network topology, the "distance" between the Origin and the Target (measured with the routing metrics in use), and the conditions in the network at the time 💜 in general, a P2P-RPL route might be way better than the global DAG route when the Origin and the Target are nearby 💖 but when they're far apart, the P2P-RPL route might not be much better 🙈 even then, P2P-RPL can still help dodge congestion that could happen near the root if all the routing only happens along a global DAG 🫶

the cost of a P2P-RPL route discovery (counted in control messages, mostly DIOs) goes up as the distance between the Origin and the Target goes up 📈 but you can keep that cost in check by setting the routing constraints carefully, tuning the Trickle parameters (they control DIO generation), and picking how long a router stays a member of the temporary DAG made for the discovery ⏱️ a network designer should weigh the benefits (potentially better routes, no need to maintain routes proactively, avoiding congestion near the global DAG's root) against the costs when using P2P-RPL 🍓 and the latency of a P2P-RPL route discovery depends again on the distance between the Origin and the Target, plus the Trickle parameters 🌈

like core RPL [RFC6550], P2P-RPL needs links to have bidirectional reachability 🔥 so the routers taking part in a P2P-RPL route discovery have to make sure that

Links that do not have bidirectional reachability do not become part of the route being discovered; and
IPv6 addresses belonging to Ingress-only (or Egress-only) Interfaces do not become part of the route being discovered.

5. Functional Overview ✨

this section is the high-level tour of P2P-RPL 🗺️

a P2P-RPL route discovery works by forming a DAG rooted at the Origin 👑 just like core RPL, P2P-RPL uses IPv6 link-local multicast DIO messages to build the DAG 📡 but unlike core RPL, this DAG is temporary 😤 the routes get discovered and installed while the DAG is alive. once the specified duration of their membership in the DAG is over, the routers leave the DAG, and the DAG stops existing 💀 the installed routes stick around for their own specified lifetime (which is different from how long a router stays in the DAG), even though the DAG that installed them is gone 🦋 in P2P-RPL, the only reason to create the DAG is to discover routes to the Target(s), and the DIOs act as the route discovery messages 💅 each router that joins the DAG works out its own rank in the DAG and ignores later DIOs from lower-ranked neighbors (the ones with a higher numerical value) ✨ so the route discovery messages spread out from the Origin instead of coming back to it 🌸 like in core RPL, a Trickle timer [RFC6206] controls how often a router generates DIOs, which stops it from sending unnecessary messages while still protecting against packet loss 🫶 P2P-RPL also reuses the routing metrics [RFC6551], Objective Functions, and packet-forwarding framework [RFC6554] [RFC6553] that were developed for core RPL 🔥

an Origin can use P2P-RPL to discover routes to one or more Targets, identified by one or more unicast/multicast addresses 🎀 P2P-RPL lets you discover one Hop-by-hop Route or up to four Source Routes per Target 🧚 the discovered routes are guaranteed to meet the specified routing metric constraints, but they might not be the best ones available 🙈 and P2P-RPL may fail to find any route at all if the routing constraints are overly strict 😭

the Origin starts a P2P-RPL route discovery by forming a temporary DAG rooted at itself 🌈 the DIOs used to build the temporary DAG are identified by a new Mode of Operation (P2P Route Discovery mode, defined in Section 6) 💜 DIOs that list the P2P Route Discovery mode as their Mode of Operation are called P2P mode DIOs from here on 💖 a P2P mode DIO always carries exactly one P2P Route Discovery Option (P2P-RDO, defined in Section 7), where the Origin specifies the following info:

The IPv6 address of a Target. This could be a unicast address or a multicast address. Any additional Targets can be specified by including one or more RPL Target options [RFC6550] inside the DIO.
The nature of the route(s) to be discovered: Hop-by-hop or Source Routes. This specification allows for the discovery of one Hop-by-hop Route or up to four Source Routes per Target.
The desired number of routes (if Source Routes are being discovered).
Whether the Target(s) should send P2P Discovery Reply Object (P2P-DRO) messages (defined in Section 8) back to the Origin when they receive a DIO message. A P2P-DRO message carries a discovered Source Route back to the Origin, or establishes a Hop-by-hop Route between the Origin and the Target.

a P2P-RDO also includes the best route from the Origin that the router generating the P2P mode DIO has seen so far 🍓

a P2P mode DIO MAY also carry:

One or more Metric Container options to specify:
- The relevant routing metrics.
- The constraints that the discovered route must satisfy. These constraints also limit how far the DIO messages may travel.
One or more RPL Target options to specify additional unicast or multicast Targets.

as the routers join the temporary DAG, they keep track of the best route(s) they've seen so far from the Origin, and they advertise those routes, along with the matching routing metrics, in their P2P mode DIOs 📣 a router, Targets included, throws away a received P2P mode DIO if the aggregated routing metrics on the route it advertises don't satisfy the listed constraints 🗑️ those constraints can be used to limit how far P2P mode DIO messages spread 🛑 a router may also discard a received P2P mode DIO if it doesn't want to be part of the discovered route, because of limited resources or policy reasons 🙅‍♀️

when a Target receives a P2P mode DIO, the P2P-RDO inside it contains a complete Source Route from the Origin to that Target 🗺️ since the links in the discovered route have bidirectional reachability (Section 7), the Target can use the discovered route to reach the Origin 🔄 so a router that provides a particular service in the LLN (like an outside temperature server, for example) could start a P2P-RPL route discovery and list all its potential clients as Targets, which lets the clients find a Source Route back to the server 🌡️ in that case, the Origin (the server) might want to turn off P2P-DRO message generation by the Targets (the clients) 🙈 if the Origin has asked for P2P-DRO messages to be sent back, the Target can select the discovered route in the received DIO for further processing, as described next 💅 this document doesn't specify a particular method for the Target to use when selecting a route for further processing 🤷‍♀️ example methods include selecting any route that meets the constraints, or selecting the best route(s) discovered over a certain time period ✨

if one or more Source Routes are being discovered, the Target sends the selected Source Route(s) to the Origin in P2P-DRO messages, with one P2P-DRO message carrying one discovered route 📦 when the Origin gets a P2P-DRO message, it stores the discovered route in its memory 🧠 this specification lets the Origin discover up to four Source Routes per Target, so the Origin has plenty of ready-to-use backups in case one or more of those routes fail 🛟 if a Hop-by-hop Route is being discovered, the Target sends a P2P-DRO message containing the selected route to the Origin 🦋 the P2P-DRO message travels back to the Origin along the selected route, and that sets up state for the Forward Route in the routers on the path 🛤️

the Target can ask the Origin to acknowledge receipt of a P2P-DRO message by sending back a P2P-DRO Acknowledgement (P2P-DRO-ACK) message (defined in Section 10) 🫶 the Origin unicasts a P2P-DRO-ACK message to the Target 💌 if the Target doesn't get the requested P2P-DRO-ACK within a certain time interval after sending a P2P-DRO, it resends the P2P-DRO message (up to a certain number of times), carrying the same route as before 🔁

the Trickle timers that delay DIO propagation can cause some nodes to generate DIOs even after the desired routes have already been discovered 😩 to stop those unnecessary messages, the Target can set a "Stop" flag in the P2P-DRO message to let the nodes in the LLN know the route discovery is finished 🛑✨ routers that receive such a P2P-DRO should not generate any more DIOs for this temporary DAG, and they should not process any DIOs for this temporary DAG that they receive in the future 🙅‍♀️ but those routers must still process the P2P-DROs received for this temporary DAG 💜

6. P2P Route Discovery Mode of Operation 👑

this section defines a new RPL Mode of Operation (MOP), P2P Route Discovery mode (or P2P mode, for short), with the value 4 🎀 a DIO message that lists P2P mode as its MOP is identified as doing a P2P-RPL route discovery by creating a temporary DAG 🦋 a P2P mode DIO MUST carry exactly one P2P Route Discovery Option (P2P-RDO, specified in Section 7) 🫶

6.1. Setting a P2P Mode DIO 🎀

okay bestie, the Base object in a P2P mode DIO message MUST be set in the following manner 🧚

RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [RFC6550]. The Origin picks the RPLInstanceID for each route discovery using these rules 💅
- The Origin SHOULD NOT reuse a RPLInstanceID for a route discovery if some routers might still be members of the DAG that the Origin started for the previous route discovery with that same RPLInstanceID. As described in Section 7, a router's membership in a DAG made for a P2P-RPL route discovery lasts for the time duration (say, 't' seconds) given by the L field inside the P2P-RDO. In general there is no upper bound on how long it takes before every router has left that DAG 🫠. In the special case where the discovered route must be at most 'n' hops long, every router must have left the DAG by "(n+1)*t" seconds after the Origin started it. In practice every router should have joined the DAG within 't' seconds of its start, since the route discovery has to finish while the Origin is still in the DAG, so every router should have left within "2*t" seconds of the start. So it's usually enough for the Origin to wait twice the duration in the L field of the P2P-RDO used for the previous route discovery before it reuses the RPLInstanceID for a new one ⏳. Individual P2P-RPL deployments are encouraged to share their experience with different RPLInstanceID reuse policies, which helps guide the development of a Standards Track version of the protocol 🌈
- When starting a new route discovery to a particular Target, the Origin MUST NOT reuse the RPLInstanceID from a previous route discovery to this Target if state created during that previous route discovery might still exist in some routers. Note that a previous route discovery might not have succeeded and some routers might still have ended up creating state anyway 👀. The Default Lifetime and Lifetime Unit parameters in the DODAG Configuration Option set how long the routers, including the Origin and the Target, keep state for a Hop-by-hop or Source Route discovered using P2P-RPL. Say that lifetime is 'X' seconds. As discussed above, any state created during the previous route discovery was most likely created within "2*t" seconds of its start. So it's enough for the Origin to let "X+2*t" seconds pass since the start of the previous route discovery before starting a new route discovery to the same Target with the same RPLInstanceID 🦋
Version Number: This field MUST be set to zero. The temporary DAG used for P2P-RPL route discovery doesn't live long enough to have new versions 🙈.
Grounded (G) Flag: This flag MUST be set to one. Unlike a global RPL instance, the concept of a floating DAG, which provides connectivity within a sub-DAG detached from a grounded DAG, doesn't apply to a local RPL instance. So an Origin MUST always set the G flag to one when it starts a P2P-RPL route discovery 🔥.
- Also, item 3 of Section 8.2.2.2 in [RFC6550] does NOT apply here, and a node MUST NOT start a new DAG if it has no parent left in a P2P-RPL DAG. Not me saying "no" to a new DAG like that 💅

Wait, the NOT in that last line is plain text and must not be capitalised as a keyword. The original says "does not apply" and "MUST NOT initiate". I'll keep those exactly as they are. Here is the corrected version of that bullet:

Also, item 3 of Section 8.2.2.2 in [RFC6550] does not apply, and a node MUST NOT start a new DAG if it has no parent left in a P2P-RPL DAG. Not me saying no to a new DAG like that 💅

Mode of Operation (MOP): This field MUST be set to four, which means P2P Route Discovery mode 🍓.
Destination Advertisement Trigger Sequence Number (DTSN): This field MUST be set to zero on transmission and ignored on reception 💜.
DODAGPreference (Prf): This field MUST be set to zero, which is least preferred 🌸.
DODAGID: This field MUST be set to an IPv6 address of the Origin ✨.
The other fields in the DIO Base object can be set however you like, following the rules described in [RFC6550] 🫶.

A received P2P mode DIO MUST be discarded if it does not follow the rules above for the RPLInstanceID, Version Number, G flag, MOP, and Prf fields inside the Base object. Bye bye, bestie 👋

The DODAG Configuration Option inside a P2P mode DIO MUST be set in the following manner 💖:

The Origin MUST set the MaxRankIncrease parameter to zero to disable local repair of the temporary DAG. A received P2P mode DIO MUST be discarded if the MaxRankIncrease parameter inside its DODAG Configuration Option is not zero 🙅‍♀️.
The Origin SHOULD set the Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as recommended in Section 9.2 🍒.
The Origin sets the Default Lifetime and Lifetime Unit parameters to show the lifetime of the state that the routers, including the Origin and the Target(s), keep for a Hop-by-hop or Source Route discovered using P2P-RPL 🕰️.
The Origin sets the other fields in the DODAG Configuration Option, including the Objective Code Point (OCP) that identifies the Objective Function, however it likes, following the rules described in [RFC6550] 🌟.
As discussed in Section 14, P2P-RPL does not tell apart the "preinstalled" and "authenticated" security modes described in [RFC6550]. So the Origin MUST set the Authentication Enabled (A) flag to zero. A received P2P mode DIO MUST be discarded if the A flag inside the DODAG Configuration Option is not zero 🔐. Security is giving serious main character energy here, no cap.
An Intermediate Router (or a Target) MUST set the various fields in the DODAG Configuration Option of its outgoing P2P mode DIOs to the values they had in the incoming P2P mode DIOs for this DAG 🔁.

A default DODAG Configuration Option takes effect if a P2P mode DIO doesn't carry an explicit one. The default DODAG Configuration Option has these parameter values 🎀:

Authentication Enabled: 0
DIOIntervalMin: 6, which works out to 64 ms as the value of the Imin parameter in a Trickle operation. That's roughly one order of magnitude bigger than the typical transmission delay on IEEE 802.15.4 links, and it matches the recommendation in Section 9.2 for well-connected topologies 🧁.
DIORedundancyConstant: 1. See the discussion in Section 9.2 🌷.
MaxRankIncrease: 0 (to disable local repair of the temporary DAG) 🛑.
Default Lifetime: 0xFF, to mean infinity ♾️.
Lifetime Unit: 0xFFFF, to mean infinity ♾️.
Objective Code Point: 0, i.e., OF0 [RFC6552] is the default Objective Function (OF) 🧠.
The remaining parameters have the default values specified in [RFC6550] 💫.

Individual P2P-RPL deployments are encouraged to share their experience with these default values, which helps guide the development of a Standards Track version of the protocol 💬.

The routing metrics and constraints [RFC6551] used in P2P-RPL route discovery are carried in one or more Metric Container options [RFC6550] inside the P2P mode DIO. A DIO doesn't need a Metric Container if OF0 is the Objective Function in effect. In that case a P2P mode DIO may still set an upper limit on the maximum rank a router may have in the temporary DAG, inside the P2P-RDO 📏.

A P2P mode DIO:

MUST carry one (and only one) P2P-RDO. The P2P-RDO lets you specify one unicast or multicast address for the Target. A received P2P mode DIO MUST be discarded if it does not contain exactly one P2P-RDO 🎯.
MAY carry one or more RPL Target options to specify additional unicast/multicast addresses for the Target. If a unicast address is specified, it MUST be a global address or a unique-local address 🌍.
MAY carry one or more Metric Container options to specify routing metrics and constraints 📊.
MAY carry one or more Route Information Options [RFC6550]. In the context of P2P-RPL, a Route Information Option tells the Target(s) about the Origin's connectivity to the prefix in the option 🗺️.
MAY carry one DODAG Configuration Option. If a P2P mode DIO doesn't carry an explicit DODAG Configuration Option, the default one defined in this section is in effect 🫧.

An RPL option other than those listed above MUST be ignored when found inside a received P2P mode DIO, and it MUST NOT be included in the P2P mode DIOs that the receiving router generates 🙃.

Following core RPL, a P2P mode DIO MUST propagate via link-local multicast. The IPv6 source address in a P2P mode DIO MUST be a link-local address, and the IPv6 destination address MUST be the link-local multicast address all-RPL-nodes [RFC6550]. A P2P mode DIO MUST be transmitted on all interfaces the router has in this RPL routing domain [RFC6554] ✨🦋

7. P2P Route Discovery Option (P2P-RDO) ✨

Okay bestie, this section introduces a brand new RPL control message option: the P2P Route Discovery Option (P2P-RDO) 🎀 It's giving main character energy 💅

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x0a | Option Length |R|H| N | Compr | L |MaxRank/NH |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         TargetAddr                            |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       Address[1..n]                           |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Format of the P2P Route Discovery Option (P2P-RDO)

The layout of a P2P-RDO is shown in Figure 1 🦋 A P2P mode DIO and a P2P-DRO message (defined in Section 8) MUST carry exactly one P2P-RDO. A P2P-RDO is made up of the following fields:

Option Type: 0x0a.
Option Length: This is an 8-bit unsigned integer giving the length in octets of the option, not counting the Option Type and Option Length fields. 📏
Reply (R): The Origin sets this flag to one to let the Target(s) send P2P-DRO messages back to the Origin. If this flag is set to zero, a Target MUST NOT generate any P2P-DRO messages. 🚫
Hop-by-hop (H): This flag only matters if the R flag is set to one. The Origin sets it to one if it wants Hop-by-hop Routes, and to zero if it wants Source Routes. This specification allows for one Hop-by-hop Route or up to four Source Routes per Target. The Hop-by-hop Route is established in the Forward direction, meaning from the Origin to the Target. This specification does not allow for Hop-by-hop Routes in the Reverse direction. 🔁
Number of Routes (N): This field only matters if the R flag is set to one and the H flag is set to zero. In that case the Targets are allowed to send P2P-DRO messages carrying discovered Source Routes back to the Origin. The value in the N field plus one tells you how many Source Routes each Target should convey to the Origin. When Hop-by-hop Routes are being discovered, the N field MUST be set to zero on transmission and ignored on reception. 🔢
Compr: This is a 4-bit unsigned integer showing how many prefix octets are elided from the Target field and the Address vector. For example, the Compr value will be zero if full IPv6 addresses are carried in the Target field and the Address vector. 🗜️
Lifetime (L): This is a 2-bit field that sets the exact duration a router joining the temporary DAG (including the Origin and the Target(s)) MUST keep its membership in the DAG. A router MUST leave the temporary DAG once the time elapsed since it joined reaches the value in this field. Here's the mapping between the value and the router's membership time in the temporary DAG:
- 0x00: 1 second
- 0x01: 4 seconds
- 0x02: 16 seconds
- 0x03: 64 seconds

The Origin sets this field based on how long it expects route discovery to take. That includes the time for the DIOs to reach the Target(s) and the P2P-DROs to travel back to the Origin. The time for the DIOs to reach the Target(s) depends on the Trickle parameters (Imin and the redundancy constant) and on the expected distance (in hops and/or ETX) to the Target(s). While picking a value, the Origin should also keep in mind that every router joining the temporary DAG will have to stay in the DAG for this whole time. ⏳

MaxRank/NH:
- When a P2P-RDO is included in a P2P mode DIO, this field gives the upper limit on the integer portion of the rank (calculated using the DAGRank() macro defined in [RFC6550]) that a router may have in the temporary DAG being created. An Intermediate Router MUST NOT join a temporary DAG being created by a P2P mode DIO if the integer portion of its rank would be equal to or higher (in numerical value) than the MaxRank limit. A Target can join the temporary DAG at a rank whose integer portion is equal to the MaxRank. A router MUST discard a received P2P mode DIO if the integer part of the advertised rank equals or exceeds the MaxRank limit. A value of 0 in this field means the MaxRank is infinity. 🏔️
- When a P2P-RDO is included in a P2P-DRO message, this field gives the index of the next-hop (NH) address inside the Address vector. 👉
TargetAddr: This is an IPv6 address of the Target after Compr number of prefix octets have been elided. When the P2P-RDO is included in a P2P mode DIO, this field may contain a unicast address or a multicast address. If a unicast address is specified, it MUST be a global address or a unique-local address. Any additional Target addresses can be specified by including one or more RPL Target options [RFC6550] in the DIO. When the P2P-RDO is included in a P2P-DRO, this field MUST contain a unicast global or unique-local IPv6 address of the Target generating the P2P-DRO. 🎯
Address[1..n]: This is a vector of IPv6 addresses representing the complete route so far in the Forward direction. 🛤️
- Each element in the Address vector has a size of (16 - Compr) octets and MUST contain a valid global or unique-local IPv6 address with the first Compr octets elided.
- The total number of elements in the Address vector is given by n = (Option Length - 2 - (16 - Compr))/(16 - Compr).
- The IPv6 address that a router adds to the vector MUST belong to the interface on which the router received the DIO containing this P2P-RDO. Further, this interface MUST NOT be an Ingress-only Interface. This means the route built up in the Address vector can be a Bidirectional Route, which a Target can use to send a P2P-DRO message to the Origin. 🔄
- The Address vector MUST carry the accumulated route in the Forward direction. In other words, the first element in the Address vector MUST contain the IPv6 address of the router next to the Origin, and so on.
- The Origin and Target addresses MUST NOT be included in the Address vector.
- A router adding its address to the vector MUST ensure that none of its addresses already exist in the vector. A Target specifying a complete route in the Address vector MUST ensure that the vector does not contain any address more than once. 🙅‍♀️
- The Address vector MUST NOT contain any multicast addresses. 💜

8. The P2P Discovery Reply Object (P2P-DRO) ✨

okay so this section introduces two brand new RPL control message types 🎀: the P2P Discovery Reply Object (P2P-DRO), with code 0x04, and the Secure P2P-DRO, with code 0x84. 💖 A P2P-DRO has one of two jobs:

it carries a discovered Source Route from a Target back to the Origin 🦋
it sets up a Hop-by-hop Route as it travels from a Target to the Origin 🌈

It also has a bonus job 💅: it tells the routers in the LLN that the P2P-RPL route discovery is finished, so there's no need to keep generating DIO messages for that temporary DAG. ✨

Here's the lowkey strict part 🙈. A P2P-DRO MUST carry one (and only one) P2P-RDO, and the TargetAddr field in that P2P-RDO MUST contain a unicast IPv6 address of the Target that generates the P2P-DRO. The P2P-DRO MUST travel from the Target to the Origin using link-local multicast, following the route written in the Address vector of the P2P-RDO that's inside the P2P-DRO. The IPv6 source address MUST be a link-local address, and the IPv6 destination address MUST be the link-local multicast address all-RPL-nodes [RFC6550]. And the P2P-DRO MUST be transmitted on all interfaces the router has in this RPL routing domain [RFC6554]. 🔥

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RPLInstanceID |    Version    |S|A|Seq|     Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         DODAGID                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Option(s)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

 Figure 2: Format of the Base P2P Discovery Reply Object (P2P-DRO)

Here's the layout of the base P2P-DRO 🧚, which is shown in Figure 2. It has these fields:

RPLInstanceID: this gives you the RPLInstanceID of the temporary DAG used for route discovery 🌸
Version: this gives you the Version of the temporary DAG used for route discovery. Since a temporary DAG always has Version zero, this field MUST always be set to zero. 🍓
Stop (S): when a Target sets this flag to one, it means the P2P-RPL route discovery is over 🛑. Every router that receives such a P2P-DRO, including the ones not listed in the route inside a P2P-RDO:
- SHOULD NOT process any more DIOs received for this temporary DAG
- SHOULD NOT generate any more DIOs for this temporary DAG
- SHOULD cancel any pending DIO transmissions for this temporary DAG

Quick but important 👑: the Stop flag only shuts down DIO generation and processing for the P2P-RPL route discovery. It does NOT change how P2P-DRO messages get processed at the Origin or at Intermediate Routers. So a router (the Origin or an Intermediate Router) MUST keep processing P2P-DRO messages even if an earlier P2P-DRO (with the same RPLInstanceID and DODAGID fields) had the Stop flag set to one. When the flag is zero, it doesn't imply anything, and it MUST be ignored on reception. 🫶

Ack Required (A): when the Target sets this flag to one, the Origin MUST unicast a P2P-DRO-ACK message (defined in Section 10) to the Target once it receives the P2P-DRO. 📬
Sequence Number (Seq): this 2-bit field is the sequence number for the P2P-DRO 🔢. It matters when the A flag is set to one, which means the Target wants an acknowledgement from the Origin for a P2P-DRO it received. The Origin puts the RPLInstanceID, the DODAGID, and the Sequence Number of the received P2P-DRO inside the P2P-DRO-ACK it sends back to the Target. 💜
Reserved: these bits are saved for future use 🔒. They MUST be set to zero on transmission and MUST be ignored on reception.
DODAGID: this gives you the DODAGID of the temporary DAG used for route discovery. The DODAGID also identifies the Origin 🎯. The RPLInstanceID, the Version, and the DODAGID together uniquely identify the temporary DAG used for route discovery, and you can copy them from the DIO message that advertised the temporary DAG. 🦄
Options: the P2P-DRO message:
- MUST carry one (and only one) P2P-RDO, and that P2P-RDO MUST specify a complete route between the Target and the Origin. A received P2P-DRO MUST be discarded if it doesn't contain exactly one P2P-RDO. 🚫
- MAY carry one or more Metric Container options that hold the aggregated routing metric values for the route specified in the P2P-RDO. 📊

Any RPL option other than the ones listed above MUST be ignored when it's found inside a received P2P-DRO message. 🙅‍♀️

8.1. Secure P2P-DRO

A Secure P2P-DRO message follows the format shown in Figure 7 of [RFC6550]. Its base format is the base P2P-DRO shown in Figure 2. 🔐

8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply Object

A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO, and that P2P-RDO MUST be set as defined in Section 7. 💅 Specifically, these fields MUST be set as follows:

Reply (R): this flag MUST be set to zero on transmission and ignored on reception. 🤍
Hop-by-Hop (H): the H flag in the P2P-RDO inside a P2P-DRO message MUST have the same value as the H flag in the P2P-RDO inside the corresponding DIO message. 🪄
Number of Routes (N): this field MUST be set to zero on transmission and ignored on reception. 0️⃣
Lifetime (L): this field MUST be set to zero on transmission and ignored on reception. ⏳
MaxRank/NH: this field gives the index of the next-hop address in the Address vector. When a Target generates a P2P-DRO message, the NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - Compr). 🧮
TargetAddr: this field MUST contain a unicast global or unique-local IPv6 address of the Target that generates the P2P-DRO. 🎯
Address[1..n]: the Address vector MUST contain a complete route between the Origin and the Target. The first element holds the IPv6 address of the router next to the Origin, and the last element holds the IPv6 address of the router next to the Target. 🗺️

9. P2P-RPL Route Discovery by Creating a Temporary DAG 🧵

This section walks through the P2P-RPL route discovery operation step by step 🪡.

9.1. Joining a Temporary DAG

Every router taking part in a P2P-RPL route discovery, including the Origin and the Target(s), MUST join the temporary DAG that's being created for that purpose 🌐. When a router joins a temporary DAG advertised by a P2P mode DIO, it MUST keep its membership in that temporary DAG for as long as the L field inside the P2P-RDO says ⏰. A temporary DAG exists for exactly one reason: to make the P2P-RPL route discovery process work. 🫧 The temporary DAG MUST NOT be used to route data packets. To put it another way, joining a temporary DAG does NOT let a router set up routing table entries that list its parents in the temporary DAG as next hops. The last bullet point in Section 3.2.8 of [RFC6550] doesn't apply when the DAG is a temporary DAG created for P2P-RPL route discovery. 🙅‍♀️

Because of how a temporary DAG is built for P2P-RPL route discovery, this document doesn't allow P2P mode DIOs to be solicited with DODAG Information Solicitation (DIS) messages, as described in [RFC6550]. 🚷 A router taking part in a P2P-RPL route discovery MUST NOT reset its Trickle timer, which controls when P2P mode DIOs are sent in response to a multicast DIS. Also, the router MUST NOT send a P2P mode DIO in response to a unicast DIS. Put simply, the rules in Section 8.3 of [RFC6550] about how a router responds to multicast and unicast DIS messages don't apply to P2P mode DIOs. 🥹

A router MUST detach from the temporary DAG created for a P2P-RPL route discovery once its membership has lasted as long as the L field inside the P2P-RDO says 🏁. Once a router receives a P2P-DRO with the Stop flag set to one, it SHOULD NOT send or process any more DIOs for this temporary DAG, and it SHOULD also cancel any pending DIO transmissions. 🛑✨

9.2. Trickle Operation for P2P Mode DIOs ✨

okay so a RPL router uses a Trickle timer [RFC6206] to control DIO transmissions 💅 Trickle is what gives quick resolution of any "inconsistency" while also avoiding redundant DIO transmissions. It also protects against DIO loss, which matters a lot because LLNs are not very reliable 🥺 When controlling the transmissions of a P2P mode DIO, a Trickle timer SHOULD follow these rules:

The receipt of a P2P mode DIO that allows the router to advertise a better route (in terms of the routing metrics and the OF in use) than before is considered "inconsistent" and hence resets the Trickle timer. Note that the first receipt of a P2P mode DIO advertising a particular temporary DAG is always considered an "inconsistent" event 🔥
The receipt of a P2P mode DIO from a parent in the temporary DAG is considered neither "consistent" nor "inconsistent" if it does not allow the router to advertise a better route than before. So the receipt of these DIOs has no impact on the Trickle operation 🫶 Note that this document does not impose any requirements on how a router might choose its parents in the temporary DAG.
The receipt of a P2P mode DIO is considered "consistent" if the source of the DIO is not a parent in the temporary DAG and either of the following conditions is true:
- The DIO advertises a better route than the router but does not allow the router to advertise a better route itself; or
- The DIO advertises a route as good as the route (to be) advertised by the router.

Note that the Trickle algorithm's DIO suppression rules are in effect at all times. Hence, a P2P-RPL router may suppress a DIO transmission even if it has not made any DIO transmissions yet 🙈

The receipt of a P2P mode DIO that advertises a worse route than what the router advertises (or would advertise when it gets a chance to generate its DIO) is considered neither "consistent" nor "inconsistent", i.e., the receipt of such a DIO has no impact on the Trickle operation.
The Imin parameter SHOULD be set taking into account the connectivity within the network. For highly connected networks, a small Imin value (on the order of the typical transmission delay for a DIO) may lead to congestion in the network, because a large number of routers reset their Trickle timers in response to the first receipt of a DIO from the Origin. These routers would generate their DIOs within the Imin interval and cause additional routers to reset their Trickle timers and generate more DIOs 😭 So for highly connected networks, the Imin parameter SHOULD be set to a value at least one order of magnitude larger than the typical transmission delay for a DIO. For sparsely connected networks, the Imin parameter can be set to a value that is a small multiple of the typical transmission delay for a DIO. Note that the Imin value has a direct impact on the time required for a P2P-RPL route discovery to complete. In general, that time would increase approximately linearly with the value of the Imin parameter. Since the route discovery must complete while the Origin still belongs to the temporary DAG created for that purpose, the Origin should set the time duration for which a router maintains its membership in the temporary DAG (indicated by the L field inside the P2P-RDO) to a large enough value, taking into account the Imin value as well as the expected distance (in terms of hops and/or ETX) to the Target(s) 🧚
The Imax parameter SHOULD be set to a large value (several orders of magnitude higher than the Imin value) and is unlikely to be critical for P2P-RPL operation. This is because the first receipt of a P2P mode DIO for a particular temporary DAG is considered an inconsistent event, and that would lead to the resetting of the Trickle timer duration to the Imin value. Given the temporary nature of the DAGs used in P2P-RPL, the Trickle timer may not get a chance to increase much 🌸
The recommended value of redundancy constant "k" is 1. With this value of "k", a DIO transmission will be suppressed if the router receives even a single "consistent" DIO during a timer interval. This setting is designed to reduce the number of messages generated during a route discovery process, and it is suitable for environments with low or moderate packet loss rates. However, this setting may result in an increase in the time required for the route discovery process to complete. A higher value for the redundancy constant may be more suitable in:
- environments with high packet loss rates; or
- deployments where the time required for the route discovery process to complete needs to be as small as possible; or
- deployments where specific destinations are reachable only through specific Intermediate Routers (and hence these Intermediate Routers should not suppress their DIOs).

A particular deployment should take the above-mentioned factors into account when deciding on the value of the redundancy constant 🍓

Individual P2P-RPL deployments are encouraged to share their experience with these rules, to help guide the development of a Standards Track version of the protocol. Applicability Statements that specify the use of P2P-RPL MUST provide guidance for setting Trickle parameters, particularly Imin and the redundancy constant 👑

9.3. Processing a P2P Mode DIO ✨

The rules for DIO processing and transmission in Section 8 of RPL [RFC6550] apply to P2P mode DIOs as well, except as modified in this document. In particular, in accordance with Section 8.2.3 of RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is malformed, according to the rules specified in this document and in [RFC6550] 🚫

The following rules for processing a received P2P mode DIO apply to both Intermediate Routers and the Target.

A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received DIO, taking into account the metric's value in both Forward and Reverse directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, the P2P-DRO messages travel from the Target to the Origin along a discovered route 💖

A router MUST discard a received P2P mode DIO with no further processing:

if the DIO advertises INFINITE_RANK as defined in Section 17 of [RFC6550]
if the integer part of the rank advertised in the DIO equals or exceeds the MaxRank limit listed in the P2P Route Discovery Option
if the routing metric values do not satisfy one or more of the mandatory route constraints listed in the DIO, or if the router cannot evaluate the mandatory route constraints, e.g., if the router does not support the metrics used in the constraints
if the router previously received a P2P-DRO message with the same RPLInstanceID and DODAGID as the received DIO and with the Stop flag set to one

The router MUST check the Target addresses listed in the P2P-RDO and any RPL Target options included in the received DIO. If one of its IPv6 addresses is listed as a Target address, or if it belongs to the multicast group specified as one of the Target addresses, the router considers itself a Target and processes the received DIO as specified in Section 9.5. Otherwise, the router considers itself an Intermediate Router and processes the received DIO as specified in Section 9.4 🎀

9.4. Additional Processing of a P2P Mode DIO at an Intermediate Router ✨

An Intermediate Router MUST discard a received P2P mode DIO with no further processing:

if the DIO is received on an Ingress-only Interface; or
if the receiving interface does not have a global or unique-local IPv6 address configured with the address prefix implied by the Compr field in the P2P-RDO inside the received DIO; or
if the router cannot uniquely identify the address prefix implied by the Compr field in the P2P-RDO (this might happen if the receiving interface has multiple global/unique-local IPv6 addresses, each configured with a different address prefix); or
if adding its IPv6 address to the route in the Address vector inside the P2P-RDO would result in the route containing multiple addresses belonging to this router.

On receiving a P2P mode DIO, an Intermediate Router MUST do the following. The router MUST determine whether this DIO advertises a better route than the router itself, and whether the receipt of the DIO would allow the router to advertise a better route than before. Accordingly, the router SHOULD consider this DIO as consistent/inconsistent from the Trickle perspective, as described in Section 9.2. Note that the route comparison in a P2P-RPL route discovery is performed using the parent selection rules of the OF in use, as specified in Section 14 of RPL [RFC6550]. If the received DIO would allow the router to advertise a better route, the router MUST add a unicast IPv6 address of the receiving interface (after eliding Compr prefix octets) to the route in the Address vector inside the P2P-RDO, and remember this route for inclusion in its future DIOs 🦋

When an Intermediate Router adds an IPv6 address to a route, it MUST ensure that:

the IPv6 address is a unicast global or unique-local IPv6 address assigned to the interface on which the DIO containing the route was received;
the IPv6 address was configured with the address prefix implied by the Compr field in the P2P-RDO inside the received DIO.

To improve the diversity of the routes being discovered, an Intermediate Router SHOULD keep track of multiple routes (as long as all these routes are the best seen so far), one of which SHOULD be selected in a uniform random manner for inclusion in the P2P-RDO inside the router's next DIO 🌈 Note that the route accumulation in a P2P mode DIO MUST take place even if the Origin does not want any P2P-DRO messages to be generated (i.e., the R flag inside the P2P-RDO is set to zero). This is because the Target may still be able to use the accumulated route as a Source Route to reach the Origin 💜

9.5. Additional Processing of a P2P Mode DIO at the Target 🎯

Okay bestie, the Target gets some extra stuff to do too 💅. The Target MAY remember the discovered route contained in the P2P-RDO in the received DIO and use it as a Source Route to reach the Origin 🦋. That Source Route lasts for the lifetime set by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option currently in effect ⏳. It can be extended (or shortened) appropriately if an upper-layer protocol drops a hint ✨.

If the Reply flag inside the P2P-RDO in the received DIO is set to one, the Target MUST select one or more discovered routes and send one or more P2P-DRO messages back to the Origin, carrying one discovered route each 🌈. If the H flag inside the P2P-RDO is set to one, the Target needs to select one route and send a P2P-DRO message along that route back to the Origin 🧚. As this P2P-DRO message travels back to the Origin, the routers on the path set up a hop-by-hop routing state, which builds a Hop-by-hop Route in the Forward direction. It's giving teamwork 🫶.

If the H flag is set to zero, the number of Source Routes to select (and the number of P2P-DRO messages to send back) is one plus the value of the N field in the P2P-RDO 🍓. The Target can choose the discovered route inside the received DIO as one or more of the routes carried inside a P2P-DRO message back to the Origin 💜. This document doesn't prescribe one specific way for the Target to pick routes 🙈. Some example methods are choosing each route that meets the specified routing constraints until you've got the desired number, or choosing the best routes discovered over a certain time period 🔥. If the Target is selecting multiple routes, it SHOULD avoid picking routes that have large segments in common, because nobody wants three copies of the same path 💀.

If the Target selects the route contained in the P2P-RDO in the received DIO, it sends a P2P-DRO message back to the Origin, which is identified by the DODAGID field in the DIO 📨. The P2P-DRO message MUST include a P2P-RDO that contains the selected route inside the Address vector. Various fields inside the P2P-RDO MUST be set as specified in Section 8.2 💅. The Target MAY set the A flag inside the P2P-DRO message to one if it wants the Origin to send back a P2P-DRO-ACK message after receiving the P2P-DRO 🎀. In that case, the Target waits for the duration of P2P_DRO_ACK_WAIT_TIME for the P2P-DRO-ACK message to arrive. If it doesn't show up in that time, the Target retransmits the P2P-DRO message. The Target MAY retransmit the P2P-DRO message this way up to MAX_P2P_DRO_RETRANSMISSIONS times ⏰. Both P2P_DRO_ACK_WAIT_TIME and MAX_P2P_DRO_RETRANSMISSIONS are configurable parameters, to be chosen based on the characteristics of each individual deployment 🌸. Also, all P2P-DRO transmissions and retransmissions MUST take place while the Target is still part of the temporary DAG created for the route discovery. A Target MUST NOT transmit a P2P-DRO if it no longer belongs to this DAG 🚫.

The Target MAY set the Stop flag inside the P2P-DRO message to one if:

this router is the only Target specified in the corresponding DIO, i.e., the corresponding DIO specified a unicast address of the router as the TargetAddr inside the P2P-RDO with no additional Targets specified via RPL Target options; and
the Target has already selected the desired number of routes.

The Target MAY include a Metric Container option in the P2P-DRO message 📊. This Metric Container holds the end-to-end routing metric values for the route specified in the P2P-RDO. The Target MUST transmit the P2P-DRO message via a link-local multicast 📡.

A Target MUST NOT forward a P2P mode DIO any further if no other Targets are to be discovered. That means a unicast IPv6 address (of this Target) is specified as the TargetAddr inside the P2P-RDO and no additional Targets are specified via RPL Target options inside the DIOs for this route discovery 🛑. Otherwise, the Target MUST generate DIOs for this route discovery the same way an Intermediate Router would 🔁.

9.6. Processing a P2P-DRO at an Intermediate Router 🧭

If the DODAGID field in the received P2P-DRO doesn't list a router's own IPv6 address, the router considers itself an Intermediate Router, and it MUST process the received message in the following manner 🫶:

The router MUST discard the received P2P-DRO with no further processing if it does not belong to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in the P2P-DRO 🗑️.
If the Stop flag inside the received P2P-DRO is set to one, the router SHOULD NOT send or receive any more DIOs for this temporary DAG, and it SHOULD cancel any pending DIO transmissions 🛑.
The router MUST ignore any Metric Container options contained in the P2P-DRO message 🙈.
If an Address[NH] element inside the P2P-RDO lists the router's own unicast IPv6 address, the router is part of the route carried in the P2P-RDO 💖. In this case, the router MUST do the following:
- To prevent loops, the router MUST discard the P2P-DRO message with no further processing if the Address vector in the P2P-RDO includes multiple IPv6 addresses assigned to the router's interfaces 🌀.
- If the H flag inside the P2P-RDO is set to one, the router MUST store the state for the Forward Hop-by-hop Route carried inside the P2P-RDO 💾. This state consists of:
  - the RPLInstanceID and the DODAGID fields of the P2P-DRO
  - the route's destination, the Target (identified by the TargetAddr field inside the P2P-RDO)
  - the IPv6 address of the next hop, Address[NH+1] (unless the NH value equals the number of elements in the Address vector, in which case the Target itself is the next hop)

This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery ⏳.

If the router already maintains a Hop-by-hop state listing the Target as the destination, carrying the same RPLInstanceID and DODAGID fields as the received P2P-DRO, and the next-hop information in that state does not match the next hop indicated in the received P2P-DRO, the router MUST discard the P2P-DRO message with no further processing 🚨. Note that this situation would occur in the following two cases:
- When the route listed in the Address vector inside the P2P-RDO contains a previously undetected loop. In this case, this rule causes the P2P-DRO messages to be discarded 🔄.
- When a Hop-by-hop Route between the Origin and the Target, previously established using the same RPLInstanceID and DODAGID as the route currently being established, still exists and at least partially overlaps the route currently being established 🧩.
The router MUST decrement the NH field inside the P2P-RDO and send the P2P-DRO message further via link-local multicast 📡.

9.7. Processing a P2P-DRO at the Origin 🏁

When a router receives a P2P-DRO message that lists its IPv6 address in the DODAGID field, it recognizes itself as the Origin for the corresponding P2P-RPL route discovery 👑. It notes the Target that originated this message (from the TargetAddr field inside the P2P-RDO) and processes the message in the following manner:

The Origin MUST discard the received P2P-DRO with no further processing if it no longer belongs to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in the P2P-DRO 🗑️.
If the Stop flag inside the received P2P-DRO is set to one, the Origin SHOULD NOT generate any more DIOs for this temporary DAG, and it SHOULD cancel any pending DIO transmissions 🛑.
If the P2P-RDO inside the P2P-DRO has the H flag set to zero, the Address vector inside the P2P-RDO contains a Source Route to this Target 🗺️. The Origin MUST set the lifetime of this Source Route to the value specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option in the P2P mode DIOs used for this route discovery. This lifetime could be extended (or shortened) appropriately, following a hint from an upper-layer protocol 🌷.
If the P2P-RDO inside the P2P-DRO has the H flag set to one, the P2P-DRO message is establishing a Hop-by-hop Route to this Target 🪄. The Origin MUST store in its memory the state for this Hop-by-hop Route, in the manner described in Section 9.6 💾. This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery ⏳. A Standards Track version of P2P-RPL may consider specifying a signaling mechanism that lets the Origin extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route, following a suitable hint from an upper-layer protocol 🔮.
If the received P2P-DRO message contains one or more Metric Container options, the Origin MAY store the values of the routing metrics associated with the discovered route in its memory 📈. This information may be useful when formulating the constraints for any future P2P-RPL route discovery to this Target 🧠.
If the A flag is set to one in the received P2P-DRO message, the Origin MUST generate a P2P-DRO-ACK message, as described in Section 10, and unicast the message to the Target 💌. The Origin MAY use the route just discovered to send the P2P-DRO-ACK message to the Target 🛤️. Section 12 describes how a packet may be forwarded along a Source/Hop-by-hop Route discovered using P2P-RPL ✨.

10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) 💌

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RPLInstanceID |    Version    |Seq|        Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         DODAGID                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 3: Format of the Base P2P Discovery Reply Object
                       Acknowledgement (P2P-DRO-ACK)

okay so a P2P-DRO can totally get lost on its way back to the Origin 😭. DIOs get Trickle-controlled retransmissions to help them out, but P2P-DROs are way more prone to loss because LLNs are kinda unreliable. And since a P2P-DRO travels via link-local multicast, it can't use link-level acknowledgements to make itself more reliable 🙈. An Intermediate Router might also just drop it (like if it can't store the state for the Hop-by-hop Route the P2P-DRO is setting up) 💀.

So to protect against that, the Target MAY ask the Origin to send back a P2P-DRO Acknowledgement (P2P-DRO-ACK) when it gets a P2P-DRO 🫶. If the Target doesn't get that ack within the P2P_DRO_ACK_WAIT_TIME interval after sending the P2P-DRO, it has to resend the message (see Section 9.5) 🔁.

This section defines two new RPL control message types: the P2P-DRO Acknowledgement (P2P-DRO-ACK), with code 0x05, and the Secure P2P-DRO-ACK, with code 0x85 ✨. A P2P-DRO-ACK MUST travel as a unicast message from the Origin to the Target. The IPv6 source and destination addresses used in a P2P-DRO-ACK MUST be global or unique-local. The format of a base P2P-DRO-ACK message is shown in Figure 3 🎀. Various fields in a P2P-DRO-ACK MUST have the same values as the corresponding fields in the P2P-DRO message. The field marked as "Reserved" MUST be set to zero on transmission and MUST be ignored on reception. A Secure P2P-DRO-ACK message follows the format shown in Figure 7 of [RFC6550], where the base format is the same as the base P2P-DRO-ACK shown in Figure 3 💅.

11. Secure P2P-RPL Operation 🔐

every RPL control message type has a secure version, including the ones defined in this document 🫧. A secure RPL control message is identified by the value 1 in the most significant bit of the Code field. Each secure RPL control message contains a Security section (see Figures 7 and 8 of [RFC6550]) whose contents are described in Section 6.1 of [RFC6550]. Sections 6.1, 10, and 19 of [RFC6550] describe core RPL's security apparatus, and those sections apply to P2P-RPL's secure operation too, except as constrained in this section.

Core RPL lets a router decide locally, on a per-packet basis, whether to use security and which Security Configuration (see definition in Section 3) to use. The only exception is the requirement to send a Secure DIO in response to a Secure DIS (see Section 10.2 of [RFC6550]) 🙄. P2P-RPL is different. This document says that routers taking part in a P2P-RPL route discovery have to follow the Origin's lead on security. The Origin decides whether to use security and which Security Configuration to use for it 👑. All the routers in this route discovery MUST generate only secure control messages if the Origin so decides, and MUST use for this purpose the Security Configuration that the Origin chose. The Origin MUST NOT set the "Key Identifier Mode" field inside the chosen Security Configuration to value 1, because that setting means a per-pair key, and per-pair keys don't work for stuff that travels by (link-local) multicast (e.g., DIOs) or over multiple hops (e.g., P2P-DROs) 🚫. The Origin MUST use the chosen Security Configuration to secure all the control messages (DIOs and P2P-DRO-ACKs) it generates.

A router MUST NOT join the temporary DAG being created for a P2P-RPL route discovery if:

it receives both secure and unsecure DIOs, or Secure DIOs with different Security Configurations, pertaining to this route discovery (i.e., referring to the same RPLInstanceID and DODAGID combination) prior to joining; or
it cannot use the Security Configuration found in the Secure DIOs pertaining to this route discovery.

When a router (an Intermediate Router or a Target) joins a temporary DAG being created using Secure DIOs, it MUST remember the common Security Configuration used in the received Secure DIOs, and it MUST use this configuration to secure all the control messages (DIOs and P2P-DROs) it generates 🧠.

Now the spicy part 🌶️. If an Intermediate Router (or a Target) runs into a control message (a DIO, a P2P-DRO, or a P2P-DRO-ACK) for this route discovery that is either not secure or doesn't follow the Security Configuration the router remembers, the router MUST enter the "lock down" mode for the rest of its stay in this temporary DAG 😱. A router in the "lock down" mode MUST NOT generate or process any control messages (irrespective of the Security Configuration used) pertaining to this route discovery. And if the Origin receives a control message (a P2P-DRO) that doesn't follow the Security Configuration the Origin chose for this route discovery, it MUST discard the received message with no further processing 🗑️.

12. Packet Forwarding along a Route Discovered Using P2P-RPL 🦋

An Origin uses the Source Routing Header (SRH) [RFC6554] to send a packet along a Source Route discovered using P2P-RPL.

Travelling along a Hop-by-hop Route established using P2P-RPL means you need to specify the RPLInstanceID and the DODAGID (of the temporary DAG used for the route discovery) to identify the route 🗺️. This is because a P2P-RPL route discovery doesn't use globally unique RPLInstanceID values. So both the RPLInstanceID (a local value assigned by the Origin) and the DODAGID (an IPv6 address of the Origin) are needed to uniquely identify a P2P-RPL Hop-by-hop Route to a particular destination 💜.

An Origin includes an RPL option [RFC6553] inside the IPv6 Hop-by-Hop Options header of a packet to send it along a Hop-by-hop Route established using P2P-RPL. For this, the Origin MUST set the DODAGID of the temporary DAG used for the route discovery as the source IPv6 address of the packet. Further, the Origin MUST specify inside the RPL option the RPLInstanceID of the temporary DAG used for the route discovery, and set the O flag inside the RPL option to one. When an Intermediate Router gets this packet, it checks the O flag and correctly infers the source IPv6 address of the packet as the DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, the RPLInstanceID, and the destination address to find the routing state it should use to forward the packet further 🧚.

13. Interoperability with Core RPL 🤝

This section describes how RPL routers that implement P2P-RPL interact with RPL routers that don't. In general, P2P-RPL operation doesn't affect core RPL operation, and vice versa 🌸. However, core RPL does let a router join a DAG as a leaf node even if it doesn't understand the Mode of Operation (MOP) used in the DAG. So a RPL router that doesn't implement P2P-RPL might conceivably join a temporary DAG being created for a P2P-RPL route discovery as a leaf node, and keep its membership even after the DAG no longer exists. This may drain the router's memory 😬. Still, such RPL-only leaf nodes don't interfere with P2P-RPL route discovery, since a leaf node may only generate a DIO advertising an INFINITE_RANK, and all routers implementing P2P-RPL are required to discard such DIOs ✅. Note that core RPL doesn't require a router to join a DAG whose MOP it doesn't understand. Plus, RPL routers in a particular deployment may have strict restrictions on the DAGs they can join, which helps mitigate the problem 🛡️.

The P2P-RPL mechanism described in this document works best when all the RPL routers in the LLN implement P2P-RPL 💖. In general, the ability to discover routes, as well as the quality of the discovered routes, gets worse as the fraction of RPL routers that implement P2P-RPL goes down 📉.

14. Security Considerations ✨

Okay bestie, security is the part where we get serious 🔒, so listen up. The security stuff for P2P-RPL is basically a cousin of RPL's (check out Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] cover RPL's security framework, which gives you data confidentiality, authentication, replay protection, and delay protection. P2P-RPL can use that same framework too, but you have to follow the constraints in Section 11 🫶.

Here's the big rule: every router in a secure route discovery has to use the Security Configuration the Origin picked. The whole point is that one sneaky router with a weaker config can't wreck the security of the entire discovery 💀. With the "lock down" mechanism from Section 11 turned on, an Origin is very unlikely to accept a route that was found under a Security Configuration it didn't mean to use. If someone tries a different config, the worst case is that route discovery just fails. The best case is even cooler: the rogue router's neighbors go into "lock down" mode and act like firewalls, so discovery keeps going everywhere else 🧱✨.

Now, RPL defines three security modes: unsecured, preinstalled, and authenticated 🔐. In unsecured mode, no secure control messages are used, and the only protection you get is whatever the link-layer protocols provide. In preinstalled mode, every node joins a secure DAG with a preinstalled group key, either as a "router" (a node that can forward packets from its parents or children in the DAG) or as a "host" (a node that can't act as a router). In authenticated mode, nodes can join as "hosts" using the preinstalled key, but they then have to authenticate to a key server to get the key that lets them work as "routers" 🗝️.

The temporary DAG made for a P2P-RPL discovery can't be used to route packets, so it doesn't make sense to call a node a "router" or a "host" in that DAG. Because of that, P2P-RPL doesn't draw a line between preinstalled and authenticated modes 🙃. A router can only join a temporary DAG for a secure P2P-RPL discovery if it supports the Security Configuration in use, and that config also says which key is in use. It doesn't matter whether the key was preinstalled or acquired dynamically. The router has to have the key in use before it can join the DAG being built for a secure P2P-RPL route discovery 🔑.

Now the scary part 😱. If a rogue router can support the Security Configuration in use (especially if it knows the key), it can join a secure P2P-RPL discovery and cause all sorts of chaos. It could advertise false info in its DIOs so it gets itself included in the discovered route(s). It could create bogus P2P-DRO messages with bad routes, or mess with genuine P2P-DRO messages it receives. A rogue router acting as the Origin could also launch denial-of-service attacks on the LLN by starting fake P2P-RPL route discoveries. For that kind of situation, RPL's authenticated mode is super useful, because a node can only get the key for a P2P-RPL discovery after proper authentication 🛡️.

Also, a P2P-DRO message travels along a Source Route written inside the message itself, so some of the problems that got Type 0 routing headers deprecated [RFC5095] might apply here too 🥺. To stop a P2P-DRO from looping forever, this document says each Intermediate Router has to check that the Source Route in the message doesn't contain a routing loop involving itself before it forwards the message any further. As Section 9.6 spells out, that check means the router makes sure its IPv6 addresses don't show up more than once in the Source Route with one or more other IPv6 addresses in between 💖.

15. IANA Considerations 🌸

15.1. Additions to Mode of Operation

This document defines a new Mode of Operation called "P2P Route Discovery Mode of Operation" (see Section 6) and gives it the value 4 from the "Mode of Operation" space [RFC6550] 🦋.

  +-------+---------------------------------------+---------------+
  | Value |              Description              |   Reference   |
  +-------+---------------------------------------+---------------+
  |   4   | P2P Route Discovery Mode of Operation | This document |
  +-------+---------------------------------------+---------------+

                          Mode of Operation

15.2. Additions to RPL Control Message Options

This document also defines a new RPL option called "P2P Route Discovery" (see Section 7), which gets the value 0x0a from the "RPL Control Message Options" space [RFC6550] 🎀.

            +-------+---------------------+---------------+
            | Value |       Meaning       |   Reference   |
            +-------+---------------------+---------------+
            |  0x0a | P2P Route Discovery | This document |
            +-------+---------------------+---------------+

                     RPL Control Message Options

15.3. Additions to RPL Control Codes

This document adds the following new RPL messages 📬:

"P2P Discovery Reply Object" (see Section 8), which gets the value 0x04 from the "RPL Control Codes" space [RFC6550].
"Secure P2P Discovery Reply Object" (see Section 8.1), which gets the value 0x84 from the "RPL Control Codes" space [RFC6550].
"P2P Discovery Reply Object Acknowledgement" (see Section 10), which gets the value 0x05 from the "RPL Control Codes" space [RFC6550].
"Secure P2P Discovery Reply Object Acknowledgement" (see Section 10), which gets the value 0x85 from the "RPL Control Codes" space [RFC6550].

 +--------+----------------------------------------+-----------------+
 |  Code  |              Description               |    Reference    |
 +--------+----------------------------------------+-----------------+
 |  0x04  |       P2P Discovery Reply Object       |  This document  |
 |  0x84  |   Secure P2P Discovery Reply Object    |  This document  |
 |  0x05  |       P2P Discovery Reply Object       |  This document  |
 |        |            Acknowledgement             |                 |
 |  0x85  |   Secure P2P Discovery Reply Object    |  This document  |
 |        |            Acknowledgement             |                 |
 +--------+----------------------------------------+-----------------+

                           RPL Control Codes

16. Known Issues and Future Work 🔮

This document is an Experimental specification 🧪. The goal is to help P2P-RPL get deployed in LLN scenarios where reactive P2P route discovery is useful or necessary. Once there's enough operational experience, the plan is to revise this spec and move it onto the Standards Track 🚀. Experience reports about P2P-RPL implementation and deployment are very welcome, especially on:

Secure P2P-RPL operation (Section 11);
Rules governing Trickle operation (Section 9.2);
Values in the default DODAG Configuration Option (Section 6.1);
The RPLInstanceID reuse policy (Section 6.1);
Utility and implementation complexity of allowing multiple Target addresses in a P2P-RPL route discovery.

17. Acknowledgements 💜

The authors thank the following people (listed alphabetically) for their help building this document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell, Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin Stiemerling, Pascal Thubert, Hristo Valev, and JP Vasseur 🫶✨.

18. References 📚

18.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
           "The Trickle Algorithm", RFC 6206, March 2011.

[RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
           Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
           Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
           Lossy Networks", RFC 6550, March 2012.

[RFC6551]  Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
           Barthel, "Routing Metrics Used for Path Calculation in
           Low-Power and Lossy Networks", RFC 6551, March 2012.

[RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
           Routing Header for Source Routes with the Routing Protocol
           for Low-Power and Lossy Networks (RPL)", RFC 6554,
           March 2012.

18.2. Informative References

[RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
           of Type 0 Routing Headers in IPv6", RFC 5095,
           December 2007.

[RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
           Routing Requirements in Low-Power and Lossy Networks",
           RFC 5826, April 2010.

[RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
           "Building Automation Routing Requirements in Low-Power and
           Lossy Networks", RFC 5867, June 2010.

[RFC6552]  Thubert, P., "Objective Function Zero for the Routing
           Protocol for Low-Power and Lossy Networks (RPL)",
           RFC 6552, March 2012.

[RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
           Power and Lossy Networks (RPL) Option for Carrying RPL
           Information in Data-Plane Datagrams", RFC 6553,
           March 2012.

[RFC6998]  Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
           "A Mechanism to Measure the Routing Metrics along a Point-
           to-Point Route in a Low-Power and Lossy Network",
           RFC 6998, August 2013.

[ROLL-TERMS]
           Vasseur, JP., "Terminology in Low power And Lossy
           Networks", Work in Progress, March 2013.

Authors' Addresses 🌈

Mukul Goyal (editor)
University of Wisconsin Milwaukee
3200 N. Cramer St.
Milwaukee, WI  53201
USA

Phone: +1-414-229-5001
EMail: mukul@uwm.edu


Emmanuel Baccelli
INRIA

Phone: +33-169-335-511
EMail: Emmanuel.Baccelli@inria.fr
URI:   http://www.emmanuelbaccelli.org/


Matthias Philipp
INRIA

Phone: +33-169-335-511
EMail: matthias-philipp@gmx.de


Anders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen, Dk-2100
Denmark

Phone: +45-29609501
EMail: abr@sdesigns.dk


Jerald Martocci
Johnson Controls
507 E. Michigan Street
Milwaukee, WI  53202
USA

Phone: +1-414-524-4010
EMail: jerald.p.martocci@jci.com

📦 where this page comes from

ietf: rfc6997 2013-08
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms