Routing for RPL Leaves

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 December 2020.¶

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

The design of Low Power and Lossy Networks (LLNs) is generally focused on saving energy, which is the most constrained resource of all. Other design constraints, such as a limited memory capacity, duty cycling of the LLN devices and low-power lossy transmissions, derive from that primary concern.¶

The IETF produced the "Routing Protocol for Low Power and Lossy Networks" [RFC6550] (RPL) to provide IPv6 [RFC8200] routing services within such constraints. RPL belongs to the class of Distance-Vector protocols, which, compared to link-state protocols, limit the amount of topological knowledge that needs to be installed and maintained in each node, and does not require convergence to avoid micro-loops.¶

To save signaling and routing state in constrained networks, RPL allows a routing stretch (see [RFC6687]), whereby routing is only performed along an acyclic graph optimized to reach a Root node, as opposed to straight along a shortest path between 2 peers, whatever that would mean in a given LLN. This trades the quality of peer-to-peer (P2P) paths for a vastly reduced amount of control traffic and routing state that would be required to operate a any-to-any shortest path protocol. Finally, broken routes may be fixed lazily and on-demand, based on dataplane inconsistency discovery, which avoids wasting energy in the proactive repair of unused paths.¶

To provide alternate paths in lossy networks, RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information solicitation (DIS) and DODAG Information Object (DIO) messages. For many of the nodes, though not all, a DODAG provides multiple forwarding solutions towards the Root of the topology via so-called parents. RPL is designed to adapt to fuzzy connectivity, whereby the physical topology cannot be expected to reach a stable state, with a lazy control that creates the routes proactively, but may only fix them reactively, upon actual traffic. The result is that RPL provides reachability for most of the LLN nodes, most of the time, but may not converge in the classical sense.¶

[RFC6550] provides unicast and multicast routing services to RPL-Aware nodes (RANs), either as a collection tree for outwards traffic only, or with routing back to the devices as well. In the latter case, a RAN injects routes to itself using Destination Advertisement Object (DAO) messages sent either to parent-nodes, in the RPL Storing Mode, or to the Root indicating their parent, in the Non-Storing Mode. This process effectively forms a DODAG back to the device that is a subset of the DODAG to the Root with all links reversed.¶

RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND) [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain reachability within a Non-Broadcast Multi-Access (NBMA) subnet. In that mode, some nodes may act as Routers and participate to the forwarding operations whereas others will only terminate packets, acting as Hosts in the data-plane. In [RFC6550] terms, a Host that is reachable over the RPL network is called a Leaf.¶

"When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo] introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects routes in RPL to manage the reachability of its own IPv6 addresses. In contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that does not participate to RPL at all. A RUL is an IPv6 Host [RFC8504] that needs a RPL-Aware Router to obtain routing services over the RPL network.¶

This specification leverages the Address Registration mechanism defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) and request that the 6LR injects a Host route for the Registered Address in the RPL routing on its behalf. A RUL may be unable to participate because it is very energy-constrained, or because it is unsafe to let it inject routes in RPL, in which case using 6LowPAN ND as the interface for the RUL limits the surface of the possible attacks and optionally protects the address ownership.¶

The RPL Non-Storing Mode mechanism is used to extend the routing state with connectivity to the RULs even when the DODAG is operated in Storing Mode. The unicast packet forwarding operation by the 6LR serving a 6LN that is also a RUL is described in [USEofRPLinfo].¶

Examples of routing-agnostic 6LNs include lightly powered sensors such as window smash sensor (alarm system), and kinetically powered light switches. Other applications of this specification may include a smart grid network that controls appliances - such as washing machines or the heating system - in the home. Appliances may not participate to the RPL protocol operated in the Smartgrid network but can still interact with the Smartgrid for control and/or metering.¶

3. 6LoWPAN Neighbor Discovery

   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    |    Status     |    Opaque     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Rsvd | I |R|T|     TID       |     Registration Lifetime     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
 ...             Registration Ownership Verifier                 ...
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4. Updating RFC 6550

This document specifies a new behavior whereby a 6LR injects DAO messages for unicast addresses (see Section 10) and multicast addresses (see Section 11) on behalf of leaves that are not aware of RPL. The RUL addresses are exposed as external targets [RFC6550]. Conforming [USEofRPLinfo], an IP-in-IP encapsulation between the 6LR and the RPL Root is used to carry the RPL artifacts and remove them when forwarding outside the RPL domain, e.g., to a RUL.¶

This document also synchronizes the liveness monitoring at the Root and the 6LBR. The same value of lifetime is used for both, and a single keep-alive message, the RPL DAO, traverses the RPL network. A new behavior is introduced whereby the RPL Root proxies the EDAR message to the 6LBR on behalf of the 6LR (more in Section 6), for any 6LN, RUL or RAN.¶

Section 6.7.7 of [RFC6550] introduces RPL Target Option, which can be used in RPL Control messages such as the DAO message to signal a destination prefix. Section 9 adds the capabilities to transport the ROVR field (see Section 3.2.3) and the IPv6 Address of the prefix advertiser when the Target is a shorter prefix, signaled by a new "F" flag. The position of the "F" flag is indicated in Section 15.¶

Section 6.7.6 of [RFC6550] defines the DODAG Configuration option with reserved flags. This specification defines the new "Root Proxies EDAR/EDAC" (P) flag and encodes it in one of these reserved flags. The "P" flag is set to indicate that the Root performs the proxy operation, which implies that it supports the Updated RPL Target Option (see Section 9). The position of the "P" flag is indicated in Section 14.¶

Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. The new "P" flag is defined only for MOP value between 0 to 6. For a MOP value of 7 or above, the flag MAY be redefined and MUST NOT be interpreted as "Root Proxies EDAR/EDAC" unless the specification of the MOP indicates to do so.¶

The RPL Status defined in section 6.5.1 of [RFC6550] for use in the DAO-ACK message is extended to be placed in DCO messages [EFFICIENT-NPDAO] as well. Furthermore, this specification enables to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and DCO messages, embedded in a RPL Status, more in Section 8.¶

5. Updating draft-ietf-roll-efficient-npdao

[EFFICIENT-NPDAO] defines the DCO for RPL Storing Mode only, with a link-local scope. This specification extends its use to the Non-Storing MOP, whereby the DCO is sent unicast by the Root directly to the RAN that injected the DAO message for the considered target.¶

This specification leverages the DCO between the Root and the 6LR that serves as attachment router for a RUL.¶

6. Updating RFC 8505

This document updates [RFC8505] to change the behavior of a RPL Router acting as 6LR in the 6LoWPAN ND Address Registration of a RUL acting as 6LN. If the RPL Root advertise the capability to proxy the EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the keep-alive EDAR message. Instead, 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.¶

7. Requirements on the RPL-Unware Leaf

This document provides RPL routing for a RUL, that is a 6LN acting as an IPv6 Host and not aware of RPL. Still, a minimal RPL-independent functionality is required from the RUL to obtain routing services.¶

8. Updated RPL Status

The RPL Status is defined in section 6.5.1 of [RFC6550] for use in the DAO-ACK message and values are assigned as follows:¶

The 6LoWPAN ND Status was defined for use in the EARO and the currently defined values are listed in table 1 of [RFC8505]. This specification enables to carry the 6LoWPAN ND Status values in RPL DAO and DCO messages, embedded in the RPL Status field.¶

To achieve this, Section 13.2 reduces the range of the EARO Status values to 0-63 to ensure that they fit within a RPL Status as shown in Figure 3.¶

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |E|A|  Value    |
   +-+-+-+-+-+-+-+-+

The following RPL Status subfields are defined:¶

E:

1-bit flag. Set to indicate a rejection. When not set, a 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 Status Value.¶

Status Value:

6-bit unsigned integer. If the 'A' flag is set this field transports a Status Value defined for IPv6 ND EARO. When the 'A' flag is not set, the Status Value is defined for RPL.¶

When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC message, the RPL Root MUST copy the 6LoWPAN ND Status unchanged in the RPL Status and set the 'A' bit. The RPL Root MUST set the 'E' flag for Values in range 1-10 which are all considered rejections.¶

Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root with a RPL Status that has the 'A' bit set, the 6LR MUST copy the RPL Status Value unchanged in the Status field of the EARO when generating an NA to the RUL.¶

9. Updated RPL Target Option

This specification updates the RPL Target Option to transport the ROVR that was also defined for 6LoWPAN ND messages. This enables the RPL Root to generate the proxied EDAR message to the 6LBR.¶

The new "F" flag is set to indicate that the Target Prefix field contains the address of the advertising node in full, in which case the length of the Target Prefix field is 16 bytes regardless of the value of the Prefix Length field.¶

If the "F" flag is reset, the Target Prefix field MUST be aligned to the next byte boundary after the size (expressed in bits) indicated by the Prefix Length field. Padding bits are reserved and set to 0 as prescribed by section 6.7.7 of [RFC6550].¶

With this specification the ROVR is the remainder of the RPL Target Option. The size of the ROVR is indicated in a new ROVR Size field that is encoded to map one-to-one with the Code Suffix in the EDAR message (see table 4 of [RFC8505]).¶

The modified format is illustrated in Figure 4. It is backward compatible with the Target Option in [RFC6550] and SHOULD be used as a replacement in new implementations even for Storing Mode operations in preparation for upcoming security mechanisms based in the ROVR.¶

   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 |ROVRsz |F|Flags| Prefix Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                Target Prefix (Variable Length)                |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
  ...            Registration Ownership Verifier (ROVR)           ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

New fields:¶

ROVRsz:

Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, denoting a ROVR size of 64, 128, 192, or 256 bits, respectively.¶

F:

1-bit flag. Set to indicate that Target Prefix field contains an Address of prefix advertiser in full.¶

Registration Ownership Verifier (ROVR):

This is the same field as in the EARO, see [RFC8505]¶

10. Protocol Operations for Unicast Addresses

The description below assumes that the Root sets the "P" flag in the DODAG Configuration Option and performs the EDAR proxy operation.¶

If the "P" flag is reset, the 6LR MUST generate the periodic EDAR messages and process the returned status as specified in [RFC8505]. If the EDAC indicates success, the rest of the flow takes place as presented but without the proxied EDAR/EDAC exchange.¶

   6LN/RUL            6LR            Root               6LBR
      |                |              |                   |
      |   NS(EARO)     |              |                   |
      |--------------->|                                  |
      |                |          Extended DAR            |
      |                |--------------------------------->|
      |                |                                  |
      |                |          Extended DAC            |
      |                |<---------------------------------|
      |                |      DAO     |                   |
      |                |------------->|                   |
      |                |              |       EDAR        |
      |                |              |------------------>|
      |                |              |       EDAC        |
      |                |              |<------------------|
      |                |    DAO-ACK   |                   |
      |                |<-------------|                   |
      |   NA(EARO)     |              |                   |
      |<---------------|              |                   |
      |                |              |                   |

   6LN/RUL              6LR           Root              6LBR
      |                  |             |                  |
      |                  |             | NA(EARO, Status) |
      |                  |             |<-----------------|
      |                  | DCO(Status) |                  |
      |                  |<------------|                  |
      | NA(EARO, Status) |             |                  |
      |<-----------------|             |                  |
      |                  |             |                  |

   6LN/RUL            6LR            Root               6LBR
      |                |              |                   |
      |   NS(EARO)     |              |                   |
      |--------------->|                                  |
      |                |      DAO     |                   |
      |                |------------->|                   |
      |                |              |       EDAR        |
      |                |              |------------------>|
      |                |              |       EDAC        |
      |                |              |<------------------|
      |                |    DAO-ACK   |                   |
      |                |<-------------|                   |
      |   NA(EARO)     |              |                   |
      |<---------------|              |                   |

11. Protocol Operations for Multicast Addresses

Section 12 of [RFC6550] details the RPL support for multicast flows. This support is not source-specific and only operates as an extension to the Storing Mode of Operation for unicast packets. Note that it is the RPL model that the multicast packet is passed as a Layer-2 unicast to each of the interested children. This remains true when forwarding between the 6LR and the listener 6LN.¶

"Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its updated version "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810] provide an interface for a listener to register to multicast flows. MLDv2 is backwards compatible with MLD, and adds in particular the capability to filter the sources via black lists and white lists. In the MLD model, the Router is a "querier" and the Host is a multicast listener that registers to the querier to obtain copies of the particular flows it is interested in.¶

On the first Address Registration, as illustrated in Figure 8, the 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in order to start receiving the flow immediately.¶

   6LN/RUL                6LR             Root                6LBR
      |                    |               |                    |
      | unsolicited Report |               |                    |
      |------------------->|               |                    |
      |     <L2 ack>       |               |                    |
      |                    | DAO           |                    |
      |                    |-------------->|                    |
      |                    |    DAO-ACK    |                    |
      |                    |<--------------|                    |
      |                    |               | <if not listening> |
      |                    |               | unsolicited Report |
      |                    |               |------------------->|
      |                    |               |                    |

Since multicast Layer-2 messages are avoided, it is important that the asynchronous messages for unsolicited Report and Done are sent reliably, for instance using a Layer-2 acknowledgment, or attempted multiple times.¶

The 6LR acts as a generic MLD querier and generates a DAO for the multicast target. The lifetime of the DAO is set to be in the order of the Query Interval, yet larger to account for variable propagation delays.¶

The Root proxies the MLD exchange as a listener with the 6LBR acting as the querier, so as to get packets from a source external to the RPL domain.¶

Upon a DAO with a multicast target, the RPL Root checks if it is already registered as a listener for that address, and if not, it performs its own unsolicited Report for the multicast target.¶

An Address re-Registration is pulled periodically by 6LR acting as querier. Note that the message may be sent unicast to all the known individual listeners.¶

Upon the timing out of the Query Interval, the 6LR sends a Query to each of its listeners, and gets a Report back that is mapped into a DAO, as illustrated in Figure 9:¶

   6LN/RUL                6LR             Root                6LBR
      |                    |               |                    |
      |       Query        |               |                    |
      |<-------------------|               |                    |
      |       Report       |               |                    |
      |------------------->|               |                    |
      |     <L2 ack>       |               |                    |
      |                    | DAO           |                    |
      |                    |-------------->|                    |
      |                    |    DAO-ACK    |                    |
      |                    |<--------------|                    |
      |                    |               |                    |
      |                    |               |       Query        |
      |                    |               |<-------------------|
      |                    |               |       Report       |
      |                    |               |------------------->|
      |                    |               |                    |
      |                    |               |                    |

Note that any of the functions 6LR, Root and 6LBR might be collapsed in a single node, in which case the flow above happens internally, and possibly through internal API calls as opposed to messaging.¶

12. Security Considerations

First of all, it is worth noting that with [RFC6550], every node in the LLN is RPL-aware and can inject any RPL-based attack in the network. This specification isolates edge nodes that can only interact with the RPL routers using 6LoWPAN ND, meaning that they cannot perform RPL insider attacks.¶

6LoWPAN ND can optionally provide SAVI features with [AP-ND], which reduces even more the attack perimeter that is available to the edge nodes.¶

The LLN nodes depend on the 6LBR and the RPL participants for their operation. A trust model must be put in place to ensure that the right devices are acting in these roles, so as to avoid threats such as black-holing, (see [RFC7416] section 7) or bombing attack whereby an impersonated 6LBR would destroy state in the network by using the "Removed" Status code.¶

This trust model could be at a minimum based on a Layer-2 Secure joining and the Link-Layer security. This is a generic 6LoWPAN requirement, see Req5.1 in Appendix of [RFC8505].¶

Additionally, the trust model could include a role validation to ensure that the node that claims to be a 6LBR or a RPL Root is entitled to do so.¶

At the time of this writing RPL does not have a zerotrust model whereby it is possible to validate the origin of an address that is injected in a DAO. This specification makes a first step in that direction by allowing the Root to challenge the RUL via the 6LR that serves it.¶

13. IANA Considerations

14. New DODAG Configuration Option Flag

This specification updates the Registry for the "DODAG Configuration Option Flags" that was created for [RFC6550] as follows:¶

15. New RPL Target Option Flag

Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL Target Option Flags" field. IANA is requested to reduce the size of the field in the Registry to 4 bits. This specification also defines a new entry in the Registry as follows:¶

16. New Subregistry for the RPL Non-Rejection Status values

This specification creates a new Subregistry for the RPL Non-Rejection Status values for use in RPL DAO-ACK and DCO messages with the 'A' flag reset, under the ICMPv6 parameters registry.¶

• Possible values are 6-bit unsigned integers (0..63).¶
• Registration procedure is "Standards Action" [RFC8126].¶
• Initial allocation is as indicated in Table 4:¶

17. New Subregistry for the RPL Rejection Status values

This specification creates a new Subregistry for the RPL Rejection Status values for use in RPL DAO-ACK and RCO messages with the 'A' flag reset, under the ICMPv6 parameters registry.¶

• Possible values are 6-bit unsigned integers (0..63).¶
• Registration procedure is "Standards Action" [RFC8126].¶
• Initial allocation is as indicated in Table 5:¶

18. Acknowledgments

The authors wish to thank Ines Robles, Georgios Papadopoulos and especially Rahul Jadhav for their reviews and contributions to this document.¶

Appendix A. Example Compression

Figure 10 illustrates the case in Storing Mode where the packet is received from the Internet, then the Root encapsulates the packet to insert the RPI and deliver to the 6LR that is the parent and last hop to the final destination, which is not known to support [RFC8138].¶

+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI-  |IP-in-IP| NH=1      |11110CPP| UDP | UDP
|Page 1  |Type1 S=0| 6LoRH | 6LoRH  |LOWPAN_IPHC| UDP    | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
         <-4 bytes->                <-        RFC 6282        ->
                                    <-     No RPL artifact ...

The difference with the example presented in Figure 19 of [RFC8138] is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the compressed address of the 6LR as the destination address of the outer IPv6 header. In the original example the destination IP of the outer header was elided and was implicitly the same address as the destination of the inner header. Type 1 was arbitrarily chosen, and the size of 0 denotes a single address in the SRH.¶

In Figure 10, the source of the IP-in-IP encapsulation is the Root, so it is elided in the IP-in-IP 6LoRH. The destination is the parent 6LR of the destination of the inner packet so it cannot be elided. If the DODAG is operated in Storing Mode, it is the single entry in the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The SRH-6LoRH is the first 6LoRH in the chain. In this particular example, the 6LR address can be compressed to 2 bytes so a Type of 1 is used. It results that the total length of the SRH-6LoRH is 4 bytes.¶

In Non-Storing Mode, the encapsulation from the Root would be similar to that represented in Figure 10 with possibly more hops in the SRH-6LoRH and possibly multiple SRH-6LoRHs if the various addresses in the routing header are not compressed to the same format. Note that on the last hop to the parent 6LR, the RH3 is consumed and removed from the compressed form, so the use of Non-Storing Mode vs. Storing Mode is indistinguishable from the packet format.¶

The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that precede it are also removed. The Paging Dispatch [RFC8025] may also be removed if there was no previous Page change to a Page other than 0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and in Page 1. The resulting packet to the destination is the inner packet compressed with [RFC6282].¶

Authors' Addresses