------+---------
               |          Internet
               |
            +-----+
            |     | <------------- 6LBR / RPL DODAG Root
            +-----+                     ^
               |                        |
         o    o   o  o                  | RPL
     o o   o  o   o  o     o    o       |
    o  o o  o o    o   o  o   o  o      |  +
    o   o      o     o   o   o    o     |
   o  o   o  o   o  o    o    o  o      | 6LoWPAN ND
      o  o  o  o        o   o           |
     o       o            o    o        v
   o      o     o <------------- 6LR / RPL Border Router
                                        ^
                                        | 6LoWPAN ND only
                                        v
                u <------------- 6LN / RPL-Unaware Leaf

• Sections [3] and [4] present in a non-normative fashion the salient aspects of RPL and 6LoWPAN ND, respectively, that are leveraged in this specification to provide connectivity to a 6LN acting as a RUL across a RPL network.
• Section 5 lists the requirements that a RUL needs to match in order to be served by a RPL router that complies with this specification.
• Section 6 presents the changes made to [RFC 6550]; a new behavior is introduced whereby the 6LR advertises the 6LN's addresses in a RPL Destination Advertisement Object (DAO) message based on the ND registration by the 6LN, and the RPL DODAG root performs the Extended Duplicate Address Request / Extended Duplicate Address Confirmation (EDAR/EDAC) exchange with the 6LoWPAN Border Router (6LBR) on behalf of the 6LR; modifications are introduced to some RPL options and to the RPL Status to facilitate the integration of the protocols.
• Section 7 presents the changes made to [RFC 9009]; the use of the Destination Cleanup Object (DCO) message is extended to the Non-Storing RPL Mode of Operation (MOP) to report asynchronous issues from the root to the 6LR.
• Section 8 presents the changes made to [RFC 6775] and [RFC 8505]; the range of the Address Registration Option / Extended Address Registration Option (ARO/EARO) Status values is reduced to 64 values, and the remaining bits in the original status field are now reserved.
• Sections [9] and [10] present the operation of this specification for unicast and multicast flows, respectively, and Section 11 presents associated security considerations.

6BBR:

6LoWPAN Backbone Router

6CIO:

6LoWPAN Capability Indication Option

6LBR:

6LoWPAN Border Router

6LN:

6LoWPAN Node (a low-power host or router)

6LoRH:

6LoWPAN Routing Header

6LoWPAN:

IPv6 over Low-Power Wireless Personal Area Network

6LR:

6LoWPAN Router

AP-ND:

Address-Protected Neighbor Discovery

ARO:

Address Registration Option

DAC:

Duplicate Address Confirmation

DAD:

Duplicate Address Detection

DAO:

Destination Advertisement Object (a RPL message)

DAR:

Duplicate Address Request

DCO:

Destination Cleanup Object (a RPL message)

DIO:

DODAG Information Object (a RPL message)

DODAG:

Destination-Oriented Directed Acyclic Graph

EARO:

Extended Address Registration Option

EDAC:

Extended Duplicate Address Confirmation

EDAR:

Extended Duplicate Address Request

EUI:

Extended Unique Identifier

LLN:

Low-Power and Lossy Network

MLD:

Multicast Listener Discovery

MOP:

RPL Mode of Operation

NA:

Neighbor Advertisement

NBMA:

Non-Broadcast Multi-Access

NCE:

Neighbor Cache Entry

ND:

Neighbor Discovery

NS:

Neighbor Solicitation

PIO:

Prefix Information Option

RA:

Router Advertisement

RAL:

RPL-Aware Leaf

RAN:

RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)

RH3:

Routing Header for IPv6 (type 3)

ROVR:

Registration Ownership Verifier

RPI:

RPL Packet Information

RPL:

Routing Protocol for Low-Power and Lossy Networks

RUL:

RPL-Unaware Leaf

SAVI:

Source Address Validation Improvement

SLAAC:

Stateless Address Autoconfiguration

SRH:

Source Routing Header

TID:

Transaction ID (a sequence counter in the EARO)

TIO:

Transit Information Option

Classical IPv6 ND:

"[Neighbor Discovery for IP version 6 (IPv6)]" [RFC 4861] and "[IPv6 Stateless Address Autoconfiguration]" [RFC 4862],

6LoWPAN:

"[Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing]" [RFC 6606] and "[IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals]" [RFC 4919], and

6LoWPAN ND:

"[Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)]" [RFC 6775], "[Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery]" [RFC 8505], "[Address-Protected Neighbor Discovery for Low-Power and Lossy Networks]" [RFC 8928], and "[IPv6 Backbone Router]" [RFC 8929].

L:

The node is a 6LR.

E:

The node is an IPv6 ND Registrar -- i.e., it supports registrations based on EARO.

P:

The node is a Routing Registrar -- i.e., an IPv6 ND Registrar that also provides reachability services for the Registered Address.

    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      |   Length = 1  |     Reserved      |D|L|B|P|E|G|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 = 0x05 | Option Length |F|X|Flg|ROVRsz | Prefix Length |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                Target Prefix (Variable Length)                |
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...            Registration Ownership Verifier (ROVR)           ...
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

F:

1-bit flag. Set to 1 to indicate that the Target Prefix field contains the complete (128-bit) IPv6 address of the advertising node.

X:

1-bit flag. Set to 1 to request that the root perform a proxy EDAR/EDAC exchange.

The 'X' flag can only be set to 1 if the DODAG is operating in Non-Storing mode and if the root sets the "Root Proxies EDAR/EDAC (P)" flag to 1 in the DODAG Configuration option; see Section 6.2.

The 'X' flag can be set for host routes to RULs and RANs; it can also be set for internal prefix routes if the 'F' flag is set, using the node's address in the Target Prefix field to form the EDAR, but it cannot be used otherwise.

Flg (Flags):

The 2 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to 0 by the sender and MUST be ignored by the receiver.

ROVRsz (ROVR Size):

Indicates the size of the ROVR. It MUST be set to 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits, respectively.

If a legacy Target option is used, then the value must remain 0, as specified in [RFC 6550].

In the case of a value above 4, the size of the ROVR is undetermined and this node cannot validate the ROVR; an implementation SHOULD propagate the whole Target option upwards as received to enable the verification by an ancestor that would support the upgraded ROVR.

Registration Ownership Verifier (ROVR):

This is the same field as in the EARO; see [RFC 8505].

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |U|A|StatusValue|
   +-+-+-+-+-+-+-+-+

U:

1-bit flag. Set to 1 to indicate a rejection. When set to 0, a Status value of 0 indicates Success / Unqualified acceptance and other values indicate "Not an outright rejection" as per RFC 6550.

A:

1-bit flag. Indicates the type of the RPL Status value.

Status Value:

6-bit unsigned integer.

If the 'A' flag is set to 1, this field transports a value defined for the 6LoWPAN ND EARO Status.

When the 'A' flag is set to 0, this field transports a Status value defined for RPL.

• If the RPL DODAG root advertises the ability to proxy the EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the keep-alive EDAR message. If it is separated from the 6LBR, the root regenerates the EDAR message to the 6LBR periodically, upon a DAO message that signals the liveliness of the address.
• The use of the R flag is extended to the NA(EARO) to confirm whether the route was installed.

1. The 6LN selects a 6LR that provides reachability services for a RUL. This is signaled by a 6CIO in the RA messages with the L, P, and E flags set to 1 as prescribed by [RFC 8505].
2. The 6LN obtains an IPv6 global address, via either (1) Stateless Address Autoconfiguration (SLAAC) [RFC 4862] based on a Prefix Information Option (PIO) [RFC 4861] found in an RA message or (2) some other means, such as DHCPv6 [RFC 8415].
3. Once it has formed an address, the 6LN registers its address and refreshes its registration periodically, early enough within the lifetime of the previous Address Registration, as prescribed by [RFC 6775], to refresh the NCE before the lifetime indicated in the EARO expires. It sets the T flag to 1 as prescribed in [RFC 8505]. The TID is incremented each time and wraps in a lollipop fashion (see Section 5.2.1 of RFC 8505, which is fully compatible with Section 7.2 of RFC 6550).
4. As stated in Section 5.2 of RFC 8505, the 6LN can register with more than one 6LR at the same time.In that case, all the fields in the EARO are set to the same valuefor all of the parallel Address Registrations, with the exceptionof the Registration Lifetime field and the R flag, which may be set todifferent values.The 6LN may cancel a subset of its registrations or may transfer a registration from one or more old 6LRs to one or more new 6LRs. To do so, the 6LN sends a series of NS(EARO) messages, all with the same TID, with a zero Registration Lifetime to the old 6LR(s) and with a non-zero Registration Lifetime to the new 6LR(s). In that process, the 6LN SHOULD send the NS(EARO) with a non-zero Registration Lifetime and ensure that at least one succeeds before it sends an NS(EARO) that terminates another registration. This avoids the churn related to transient route invalidation in the RPL network above the common parent of the involved 6LRs.
5. Following Section 5.1 of RFC 8505, a 6LN acting as a RUL sets the R flag in the EARO of its registration(s) for which it requires routing services. If the R flag is not echoed in the NA, the RUL MUST assume that establishing the routing services via this 6LR failed, and it SHOULD attempt to use another 6LR. The RUL SHOULD ensure that one registration succeeds before setting the R flag to 0. In the case of a conflict with the preceding rule regarding the lifetime, the rule regarding the lifetime has precedence.
6. The 6LN may use any of the 6LRs to which it registered as the default gateway. Using a 6LR to which the 6LN is not registered may result in packets dropped at the 6LR by a Source Address Validation Improvement (SAVI) function [RFC 7039] and thus is not recommended.

1. The Registered Address is signaled as the Target Prefix in the updated Target option in the DAO message; the Prefix Length is set to 128 but the 'F' flag is set to 0, since the advertiser is not the RUL. The ROVR field is copied unchanged from the EARO (see Section 6.1).
2. The 6LR indicates one of its global or unique-local IPv6 unicast addresses as the Parent Address in the TIO associated with the Target option.
3. The 6LR sets the External ('E') flag in the TIO to indicate that it is redistributing an external target into the RPL network.
4. The Path Lifetime in the TIO is computed from the Registration Lifetime in the EARO. This operation converts seconds to the Lifetime Units used in the RPL operation. This creates the deployment constraint that the Lifetime Unit is reasonably compatible with the expression of the Registration Lifetime; e.g., a Lifetime Unit of 0x4000 maps the most significant byte of the Registration Lifetime to the Path Lifetime. In that operation, the Path Lifetime must be set to ensure that the path has a longer lifetime than the registration and also covers the round-trip time to the root. Note that if the Registration Lifetime is 0, then the Path Lifetime is also 0 and the DAO message becomes a No-Path DAO, which cleans up the routes down to the RUL's address; this also causes the root as a proxy to send an EDAR message to the 6LBR with a Lifetime of 0.
5. The Path Sequence in the TIO is set to the TID value found in the EARO.

6LN                                       6LR        Root        6LBR
 |                                         |           |           |
 |<--------------- RA ---------------------|           |           |
 |                                         |           |           |
 |------ NS(EARO) (ROVR=Crypto-ID) ------->|           |           |
 |                                         |           |           |
 |<-NA(EARO) (Status=Validation Requested)-|           |           |
 |                                         |           |           |
 |---- NS(EARO) and proof of ownership --->|           |           |
 |                                         |           |           |
 |                                <validate the proof> |           |
 |                                                     |           |
 |<------- NA(EARO) (Status=10) -----<if failed>       |           |
 |                                                     |           |
 |                                       <else>        |           |
 |                                         |           |           |
 |                                         |--------- EDAR ------->|
 |                                         |                       |
 |                                         |<-------- EDAC --------|
 |                                         |                       |
 |                                         |           |           |
 |                                         |-DAO(X=0)->|           |
 |                                         |           |           |
 |                                         |<- DAO-ACK-|           |
 |                                         |           |           |
 |<---------- NA(EARO) (Status=0) ---------|           |           |
 |                                         |           |           |
                                     ...
 |                                         |           |           |
 |------ NS(EARO) (ROVR=Crypto-ID) ------->|           |           |
 |                                         |-DAO(X=1)->|           |
 |                                         |           |-- EDAR -->|
 |                                         |           |           |
 |                                         |           |<-- EDAC --|
 |                                         |<- DAO-ACK-|           |
 |<---------- NA(EARO) (Status=0) ---------|           |           |
 |                                         |           |           |
                                     ...

1. The target IPv6 address from the RPL Target option is placed in the Registered Address field of the EDAR message;
2. The Registration Lifetime is adapted from the Path Lifetime in the TIO by converting the Lifetime Units used in RPL into units of 60 seconds used in the 6LoWPAN ND messages;
3. The TID value is set to the Path Sequence in the TIO and indicated with an ICMP code of 1 in the EDAR message;
4. The ROVR in the RPL Target option is copied as is in the EDAR, and the ICMP Code Suffix is set to the appropriate value as shown in Table 4 of [RFC 8505], depending on the size of the ROVR field.

• Possible values are 6-bit unsigned integers (0..63).
• The registration procedure is IETF Review [RFC 8126].
• The initial allocation is as indicated in Table 4:

• Possible values are 6-bit unsigned integers (0..63).
• The registration procedure is IETF Review [RFC 8126].
• The initial allocation is as indicated in Table 5:

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3810]

R. Vida, and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.

[RFC4861]

T. Narten, E. Nordmark, W. Simpson, and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.

[RFC6550]

T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.

[RFC6775]

Z. Shelby, S. Chakrabarti, E. Nordmark, and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.

[RFC7102]

JP. Vasseur, "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014,
<https://www.rfc-editor.org/info/rfc7102>.

[RFC7400]

C. Bormann, "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014,
<https://www.rfc-editor.org/info/rfc7400>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC8504]

T. Chown, J. Loughney, and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019,
<https://www.rfc-editor.org/info/rfc8504>.

[RFC8505]

P. Thubert, E. Nordmark, S. Chakrabarti, and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.

[RFC8928]

P. Thubert, B. Sarikaya, M. Sethi, and R. Struik, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 2020,
<https://www.rfc-editor.org/info/rfc8928>.

[RFC9008]

M.I. Robles, M Richardson, and P Thubert, "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>.

[RFC9009]

R.A Jadhav, P Thubert, R.N Sahoo, and Z Cao, "Efficient Route Invalidation", RFC 9009, DOI 10.17487/RFC9009, April 2021,
<https://www.rfc-editor.org/info/rfc9009>.

[RFC4862]

S. Thomson, T. Narten, and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.

[RFC4919]

N. Kushalnagar, G. Montenegro, and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.

[RFC6282]

J. Hui, and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.

[RFC6553]

J. Hui, and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>.

[RFC6554]

J. Hui, JP. Vasseur, D. Culler, and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.

[RFC6606]

E. Kim, D. Kaspar, C. Gomez, and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.

[RFC6687]

J. Tripathi, J. de Oliveira, and JP. Vasseur, "Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6687, DOI 10.17487/RFC6687, October 2012,
<https://www.rfc-editor.org/info/rfc6687>.

[RFC7039]

J. Wu, J. Bi, M. Bagnulo, F. Baker, and C. Vogt, "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>.

[RFC7228]

C. Bormann, M. Ersue, and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.

[RFC7416]

T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, and M. Richardson, "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.

[RFC8025]

P. Thubert, and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>.

[RFC8138]

P. Thubert, C. Bormann, L. Toutain, and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017,
<https://www.rfc-editor.org/info/rfc8138>.

[RFC8415]

T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.

[RFC8929]

P. Thubert, C.E. Perkins, and E. Levy-Abegnoli, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November 2020,
<https://www.rfc-editor.org/info/rfc8929>.

Pascal Thubert

Michael C. Richardson