draft-ietf-roll-unaware-leaves-08.txt   draft-ietf-roll-unaware-leaves-09.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505 (if approved) M. Richardson Updates: 6550, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 18 June 2020 16 December 2019 Expires: 30 July 2020 27 January 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-08 draft-ietf-roll-unaware-leaves-09
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide unicast and This specification extends RFC6550 and RFC8505 to provide unicast and
multicast routing services in a RPL domain to 6LNs that are plain multicast routing services in a RPL domain to 6LNs that are plain
Hosts and do not participate to RPL, and enables the RPL Root to Hosts and do not participate to RPL, and enables the RPL Root to
proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG. proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 June 2020. This Internet-Draft will expire on 30 July 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 7 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 7
3.1. RFC 6775 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. RFC 6775 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. RFC 8505 Extended ARO . . . . . . . . . . . . . . . . . . 7 3.2. RFC 8505 Extended ARO . . . . . . . . . . . . . . . . . . 7
3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8 3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8
3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9 3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9
4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. RFC 7400 Capability Indication Option . . . . . . . . 9
5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 10 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10
6. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 10 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 11
6. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11
6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11 6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11
6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 11 6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 12
6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 12 6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 13
6.2.2. Support of the Routing Header . . . . . . . . . . . . 12 6.2.2. Support of the Routing Header . . . . . . . . . . . . 13
6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 12 6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 13
7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 13 7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 13
8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 14 8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 14
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15
9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 15 9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 16
9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 18 9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 19
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 18 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 19
9.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 19 9.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 20
9.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 20 9.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 21
9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 22 9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 23
9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 23 9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 24
10. Protocol Operations for Multicast Addresses . . . . . . . . . 23 10. Protocol Operations for Multicast Addresses . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12.1. New DODAG Configuration Option Flag . . . . . . . . . . 26 12.1. New DODAG Configuration Option Flag . . . . . . . . . . 27
12.2. RPL Target Option Flags . . . . . . . . . . . . . . . . 26 12.2. RPL Target Option Flags . . . . . . . . . . . . . . . . 27
12.3. New Subregistry for the RPL Non-Rejection Status 12.3. New Subregistry for the RPL Non-Rejection Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 26 values . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.4. New Subregistry for the RPL Rejection Status values . . 26 12.4. New Subregistry for the RPL Rejection Status values . . 27
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
14. Normative References . . . . . . . . . . . . . . . . . . . . 27 14. Normative References . . . . . . . . . . . . . . . . . . . . 28
15. Informative References . . . . . . . . . . . . . . . . . . . 29 15. Informative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. Example Compression . . . . . . . . . . . . . . . . 30 Appendix A. Example Compression . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power and Lossy The IETF produced the "Routing Protocol for Low Power and Lossy
skipping to change at page 5, line 50 skipping to change at page 5, line 50
* "Registration Extensions for IPv6 over Low-Power Wireless Personal * "Registration Extensions for IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Neighbor Discovery" [RFC8505]. Area Network (6LoWPAN) Neighbor Discovery" [RFC8505].
2.3. Glossary 2.3. Glossary
This document often uses the following acronyms: This document often uses the following acronyms:
AR: Address Resolution (aka Address Lookup) AR: Address Resolution (aka Address Lookup)
6LBR: 6LoWPAN Border Router 6CIO: 6LoWPAN Capability Indication Option
6LN: 6LoWPAN Node (a Low Power Host or Router) 6LN: 6LoWPAN Node (a Low Power Host or Router)
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
(E)ARO: (Extended) Address Registration Option (E)ARO: (Extended) Address Registration Option
(E)DAR: (Extended) Duplicate Address Request (E)DAR: (Extended) Duplicate Address Request
(E)DAC: (Extended) Duplicate Address Confirmation (E)DAC: (Extended) Duplicate Address Confirmation
skipping to change at page 7, line 30 skipping to change at page 7, line 30
carried in the unicast Neighbor Solicitation (NS) and Neighbor carried in the unicast Neighbor Solicitation (NS) and Neighbor
Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the
6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate Address 6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate Address
Request (DAR) and Duplicate Address Confirmation (DAC) messages Request (DAR) and Duplicate Address Confirmation (DAC) messages
between the 6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the between the 6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the
6LBR is the central repository of all the Registered Addresses in its 6LBR is the central repository of all the Registered Addresses in its
domain. domain.
The main functions of [RFC6775] are to proactively establish the The main functions of [RFC6775] are to proactively establish the
Neighbor Cache Entry in the 6LR and to avoid address duplication. Neighbor Cache Entry in the 6LR and to avoid address duplication.
There is no concept of registering the address for an external
service.
3.2. RFC 8505 Extended ARO 3.2. RFC 8505 Extended ARO
"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
updates the behavior of RFC 6775 to enable a generic Address updates the behavior of RFC 6775 to enable a generic Address
Registration to services such as routing and ND proxy, and defines Registration to services such as routing and ND proxy, and defines
the Extended Address Registration Option (EARO) as shown in Figure 1: the Extended Address Registration Option (EARO) as shown in Figure 1:
0 1 2 3 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 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
skipping to change at page 9, line 25 skipping to change at page 9, line 25
RPL network for a lifetime that is indicated by the source of the RPL network for a lifetime that is indicated by the source of the
DAO. This means that there are two periodic messages that traverse DAO. This means that there are two periodic messages that traverse
the whole network to indicate that an address is still reachable, one the whole network to indicate that an address is still reachable, one
to the Root and one to the 6LBR. to the Root and one to the 6LBR.
This specification saves the support of RPL in a 6LN called a RUL and This specification saves the support of RPL in a 6LN called a RUL and
avoids an extraneous periodic flow across the LLN. The RUL only avoids an extraneous periodic flow across the LLN. The RUL only
needs to perform a [RFC8505] Address Registration to the 6LR. The needs to perform a [RFC8505] Address Registration to the 6LR. The
6LR turns it into a DAO message to the Root on behalf of the RUL. 6LR turns it into a DAO message to the Root on behalf of the RUL.
Upon the new DAO, the Root proxies the EDAR exchange to the 6LBR on Upon the new DAO, the Root proxies the EDAR exchange to the 6LBR on
behalf of the 6LR. This is illustrated in Figure 5. behalf of the 6LR. This is illustrated in Figure 6.
3.3.1. RFC 7400 Capability Indication Option
"6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the
6LoWPAN Capability Indication Option (6CIO) that enables a node to
expose its capabilities in Router Advertisement (RA) Messages.
[RFC8505] defines a number of bits in the 6CIO, in particular:
L: Node is a 6LR.
E: Node is an IPv6 ND Registrar -- i.e., it supports registrations
based on EARO.
P: Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that
also provides reachability services for the Registered Addres
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: 6CIO flags
A RUL can get reachability services from a 6LR if and only if the L,
P and E flags are set in a 6CIO originated by the 6LR. A 6LR that
can provide reachability services for a RUL node in a RPL network as
specified in this document sets the L, P and E flags.
4. Updating RFC 6550 4. Updating RFC 6550
This document specifies a new behavior whereby a 6LR injects DAO This document specifies a new behavior whereby a 6LR injects DAO
messages for unicast addresses (see Section 9) and multicast messages for unicast addresses (see Section 9) and multicast
addresses (see Section 10) on behalf of leaves that are not aware of addresses (see Section 10) on behalf of leaves that are not aware of
RPL. The Targets are exposed as External addresses. An IP-in-IP RPL. The Targets are exposed as External addresses. An IP-in-IP
encapsulation that terminates at the border 6LR is used to remove RPL encapsulation that terminates at the border 6LR is used to remove RPL
artifacts and compression techniques that may not be processed artifacts and compression techniques that may not be processed
correctly outside of the RPL domain. correctly outside of the RPL domain.
skipping to change at page 11, line 7 skipping to change at page 11, line 33
6. Requirements on the RPL-Unware Leaf 6. Requirements on the RPL-Unware Leaf
This document provides RPL routing for a RUL, that is a 6LN acting as 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 an IPv6 Host and not aware of RPL. Still, a minimal RPL-independent
functionality is required from the RUL in order to obtain routing functionality is required from the RUL in order to obtain routing
services from the 6LR. services from the 6LR.
6.1. Support of 6LoWPAN ND 6.1. Support of 6LoWPAN ND
In order to obtain routing services from a RPL 6LR, a RUL MUST In order to obtain routing services from a 6LR, a RUL MUST implement
implement [RFC8505] and set the "R" flag in the EARO option. [RFC8505] and set the "R" flag in the EARO option. The RUL MAY
request routing services from a 6LR if and only if the L, R and E
flags are all set in the 6CIO [RFC7400] originated by the 6LR.
The RUL MUST register to all the 6LRs from which it expects to get The RUL MUST register to all the 6LRs from which it requests routing
routing services. The Address Registrations SHOULD be performed in a services. The Address Registrations SHOULD be performed in a rapid
rapid sequence, using the exact same EARO for a same Address. Gaps sequence, using the exact same EARO for a same Address. Gaps between
between the Address Registrations will invalidate some of the routes the Address Registrations will invalidate some of the routes till the
till the Address Registration finally shows on those routes as well. Address Registration finally shows on those routes as well.
[RFC8505] introduces error Status values in the NA(EARO) which can be [RFC8505] introduces error Status values in the NA(EARO) which can be
received synchronously upon an NS(EARO) or asynchronously. The RUL received synchronously upon an NS(EARO) or asynchronously. The RUL
MUST support both cases and refrain from using the Registered Address MUST support both cases and refrain from using the Registered Address
as specified by [RFC8505] depending on the Status value. as specified by [RFC8505] depending on the Status value.
A RUL SHOULD support [AP-ND] to protect the ownership of its A RUL SHOULD support [AP-ND] to protect the ownership of its
addresses. addresses.
6.2. External Routes and RPL Artifacts 6.2. External Routes and RPL Artifacts
skipping to change at page 11, line 36 skipping to change at page 12, line 17
Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be
followed when forwarding packets over an external route: followed when forwarding packets over an external route:
RPL data packets are often encapsulated using IP-in-IP and in Non- RPL data packets are often encapsulated using IP-in-IP and in Non-
Storing Mode, packets going down will carry an SRH as well. RPL data Storing Mode, packets going down will carry an SRH as well. RPL data
packets also typically carry a Hop-by-Hop Header to transport a RPL packets also typically carry a Hop-by-Hop Header to transport a RPL
Packet Information (RPI) [RFC6550]. These additional headers are Packet Information (RPI) [RFC6550]. These additional headers are
called RPL artifacts. called RPL artifacts.
When IP-in-IP is used and the outer headers terminate at a 6LR down When IP-in-IP is used and the outer headers terminate at a 6LR down
the path (see Figure 9 for the compressed format in Storing Mode), the path (see Figure 10 for the compressed format in Storing Mode),
then the 6LR decapsulates the IP-in-IP and the packet that is then the 6LR decapsulates the IP-in-IP and the packet that is
forwarded to the external destination is free of RPL artifacts - but forwarded to the external destination is free of RPL artifacts - but
possibly an RPI if packet was generated by a RAN in the same RPL possibly an RPI if packet was generated by a RAN in the same RPL
domain as the destination RUL. domain as the destination RUL.
Non-Storing Mode DAO messages are used to signal external routes to Non-Storing Mode DAO messages are used to signal external routes to
the Root, even if the DODAG is operated in Storing Mode. This the Root, even if the DODAG is operated in Storing Mode. This
enables to advertise the 6LR that injects the route for use as tunnel enables to advertise the 6LR that injects the route for use as tunnel
endpoint in the data path. endpoint in the data path.
skipping to change at page 13, line 36 skipping to change at page 14, line 13
values in the range 0-63 can be transported. values in the range 0-63 can be transported.
The resulting RPL Status is as follows: The resulting RPL Status is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|A| Value | |E|A| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2: RPL Status Format Figure 3: RPL Status Format
RPL Status subfields: RPL Status subfields:
E: 1-bit flag. Set to indicate a rejection. When not set, a value E: 1-bit flag. Set to indicate a rejection. When not set, a value
of 0 indicates Success/Unqualified acceptance and other values of 0 indicates Success/Unqualified acceptance and other values
indicate "not an outright rejection" as per RFC 6550. indicate "not an outright rejection" as per RFC 6550.
A: 1-bit flag. Indicates the type of the Status value. A: 1-bit flag. Indicates the type of the Status value.
Status Value: 6-bit unsigned integer. If the 'A' flag is set this Status Value: 6-bit unsigned integer. If the 'A' flag is set this
skipping to change at page 14, line 12 skipping to change at page 14, line 38
When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a DAC When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a DAC
message, the RPL Root MUST copy the ARO Status unchanged in a RPL message, the RPL Root MUST copy the ARO Status unchanged in a RPL
Status with the 'A' bit set. Conversely the 6LR MUST copy the value Status with the 'A' bit set. Conversely the 6LR MUST copy the value
of the RPL Status unchanged in the EARO of an NA message that is of the RPL Status unchanged in the EARO of an NA message that is
built upon a RPL Status with the 'A' bit set in a DCO or a DAO-ACK built upon a RPL Status with the 'A' bit set in a DCO or a DAO-ACK
message. message.
8. Updated RPL Target option 8. Updated RPL Target option
This specification updates the RPL Target option to transport the This specification updates the RPL Target option to transport the
ROVR as illustrated in Figure 3. This enables the RPL Root to ROVR as illustrated in Figure 4. This enables the RPL Root to
generate a full EDAR Message as opposed to a keep-alive EDAR that has generate a full EDAR Message as opposed to a keep-alive EDAR that has
restricted properties. restricted properties.
The Target Prefix MUST be aligned to the next 4-byte boundary after The Target Prefix MUST be aligned to the next 4-byte boundary after
the size indicated by the Prefix Length. if necessary it is padded the size indicated by the Prefix Length. if necessary it is padded
with zeros. The size of the ROVR is indicated in a new ROVR Type with zeros. The size of the ROVR is indicated in a new ROVR Type
field that is encoded to map the CodePfx in the EDAR message (see field that is encoded to map the CodePfx in the EDAR message (see
section 4.2 of [RFC8505]). section 4.2 of [RFC8505]).
With this specification the ROVR is the remainder of the RPL Target With this specification the ROVR is the remainder of the RPL Target
skipping to change at page 14, line 42 skipping to change at page 15, line 21
+ + + +
| Target Prefix (Variable Length) | | Target Prefix (Variable Length) |
. Aligned to 4-byte boundary . . Aligned to 4-byte boundary .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Updated Target Option Figure 4: Updated Target Option
New fields: New fields:
ROVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, 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. denoting a ROVR size of 64, 128, 192, or 256 bits, respectively.
Registration Ownership Verifier (ROVR): This is the same field as in Registration Ownership Verifier (ROVR): This is the same field as in
the EARO, see [RFC8505] the EARO, see [RFC8505]
9. Protocol Operations for Unicast Addresses 9. Protocol Operations for Unicast Addresses
skipping to change at page 15, line 27 skipping to change at page 16, line 4
To achieve this, the lifetimes and sequence counters in 6LoWPAN ND To achieve this, the lifetimes and sequence counters in 6LoWPAN ND
and RPL are aligned. In other words, the Path Sequence and the Path and RPL are aligned. In other words, the Path Sequence and the Path
Lifetime in the DAO message are taken from the Transaction ID and the Lifetime in the DAO message are taken from the Transaction ID and the
Address Registration lifetime in the NS(EARO) message from the 6LN. Address Registration lifetime in the NS(EARO) message from the 6LN.
In that flow, the RPL Root acts as a proxy to refresh the state in In that flow, the RPL Root acts as a proxy to refresh the state in
the 6LBR. The proxy operation applies to both RUL and RAN. This the 6LBR. The proxy operation applies to both RUL and RAN. This
means that in a RPL network where the function is enabled, refreshing means that in a RPL network where the function is enabled, refreshing
the state in the 6LBR is the responsibility of the Root. the state in the 6LBR is the responsibility of the Root.
Consequently, only addresses that are injected in RPL will be kept Consequently, only addresses that are injected in RPL will be kept
alive by the RPL Root. alive by the RPL Root.
In a same fashion, if an additional routing protocol is deployed on a In a same fashion, if an additional routing protocol is deployed on a
same network, that additional routing protocol may need to handle the same network, that additional routing protocol may need to handle the
keep alive procedure for the addresses that it serves. keep alive procedure for the addresses that it serves.
On the first Address Registration, illustrated in Figure 4 and On the first Address Registration, illustrated in Figure 5 and
Figure 6 for RPL Non-Storing and Storing Mode respectively, the Figure 7 for RPL Non-Storing and Storing Mode respectively, the
Extended Duplicate Address exchange takes place as prescribed by Extended Duplicate Address exchange takes place as prescribed by
[RFC8505]. Any of the functions 6LR, Root and 6LBR might be [RFC8505]. Any of the functions 6LR, Root and 6LBR might be
collapsed in a single node. collapsed in a single node.
When successful, the flow creates a Neighbor Cache Entry (NCE) in the When successful, the flow creates a Neighbor Cache Entry (NCE) in the
6LR, and the 6LR injects the Registered Address in RPL using DAO/DAO- 6LR, and the 6LR injects the Registered Address in RPL using DAO/DAO-
ACK exchanges all the way to the RPL DODAG Root. The protocol does ACK exchanges all the way to the RPL DODAG Root. The protocol does
not carry a specific information that the Extended Duplicate Address not carry a specific information that the Extended Duplicate Address
messages were already exchanged, so the Root proxies them anyway. messages were already exchanged, so the Root proxies them anyway.
9.1.1. In RPL Non-Storing-Mode 9.1.1. In RPL Non-Storing-Mode
In Non-Storing Mode, the DAO message flow can be nested within the In Non-Storing Mode, the DAO message flow can be nested within the
Address Registration flow as illustrated in Figure 4 and it is Address Registration flow as illustrated in Figure 5 and it is
possible to carry information such as an updated lifetime from the possible to carry information such as an updated lifetime from the
6LBR all the way back to the 6LN. 6LBR all the way back to the 6LN.
6LN 6LR Root 6LBR 6LN 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | Extended DAR | | | Extended DAR |
| |--------------------------------->| | |--------------------------------->|
| | | | | |
skipping to change at page 16, line 33 skipping to change at page 17, line 33
|<---------------| | | |<---------------| | |
| | | | | | | |
(in case if an Error not reported in DAO-ACK) (in case if an Error not reported in DAO-ACK)
| | | | | | | |
| | DCO | | | | DCO | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 4: First Registration Flow in Non-Storing Mode Figure 5: First Registration Flow in Non-Storing Mode
An Address re-Registration is performed by the 6LN to maintain the An Address re-Registration is performed by the 6LN to maintain the
NCE in the 6LR alive before lifetime expires. Upon an Address re- NCE in the 6LR alive before lifetime expires. Upon an Address re-
Registration, as illustrated in Figure 5, the 6LR redistributes the Registration, as illustrated in Figure 6, the 6LR redistributes the
Registered Address NS(EARO) in RPL. Registered Address NS(EARO) in RPL.
6LN 6LR Root 6LBR 6LN 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | DAO | | | | DAO | |
| |------------->| | | |------------->| |
| | | (keep-alive) EDAR | | | | (keep-alive) EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
Figure 5: Next Registration Flow in Non-Storing Mode Figure 6: Next Registration Flow in Non-Storing Mode
This causes the RPL DODAG Root to refresh the state in the 6LBR with This causes the RPL DODAG Root to refresh the state in the 6LBR with
an EDAC message or a keep-alive EDAC if the ROVR is not indicated in an EDAC message or a keep-alive EDAC if the ROVR is not indicated in
the Target Option. In any case, the EDAC message sent in response by the Target Option. In any case, the EDAC message sent in response by
the 6LBR contains the actual value of the ROVR field for that Address the 6LBR contains the actual value of the ROVR field for that Address
Registration. In case of an error on the proxied EDAR flow, the Registration. In case of an error on the proxied EDAR flow, the
error SHOULD be returned in the DAO-ACK - if one was requested - error SHOULD be returned in the DAO-ACK - if one was requested -
using a RPL Status with the 'A' flag set that imbeds a 6LoWPAN Status using a RPL Status with the 'A' flag set that imbeds a 6LoWPAN Status
value as discussed in Section 7. value as discussed in Section 7.
skipping to change at page 18, line 43 skipping to change at page 19, line 43
| | | |<----------------| | | | |<----------------|
| | | | | | | | | |
(in case if an Error) (in case if an Error)
| | | | | | | | | |
| | DCO | | | | DCO | |
| |<------------------------------| | | |<------------------------------| |
| NA(EARO) | | | | | NA(EARO) | | | |
|<--------------| | | | |<--------------| | | |
| | | | | | | | | |
Figure 6: Next Registration Flow in Storing Mode Figure 7: Next Registration Flow in Storing Mode
If the keep alive fails, the path is cleaned up asynchronously using If the keep alive fails, the path is cleaned up asynchronously using
a DCO message [EFFICIENT-NPDAO] as illustrated in Figure 6 and a DCO message [EFFICIENT-NPDAO] as illustrated in Figure 7 and
described in further details in Section 9.2.3. described in further details in Section 9.2.3.
9.2. Detailed Operation 9.2. Detailed Operation
9.2.1. By the 6LN 9.2.1. By the 6LN
This specification does not alter the operation of a 6LoWPAN ND- This specification does not alter the operation of a 6LoWPAN ND-
compliant 6LN, and a RUL is expected to operate as follows: compliant 6LN, and a RUL is expected to operate as follows:
* The 6LN obtains an IPv6 global address, for instance using * The 6LN obtains an IPv6 global address, for instance using
autoconfiguration [RFC4862] based on a Prefix Information Option autoconfiguration [RFC4862] based on a Prefix Information Option
skipping to change at page 23, line 46 skipping to change at page 24, line 46
"Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its
updated version "Multicast Listener Discovery Version 2 (MLDv2) for updated version "Multicast Listener Discovery Version 2 (MLDv2) for
IPv6" [RFC3810] provide an interface for a listener to register to IPv6" [RFC3810] provide an interface for a listener to register to
multicast flows. MLDv2 is backwards compatible with MLD, and adds in multicast flows. MLDv2 is backwards compatible with MLD, and adds in
particular the capability to filter the sources via black lists and particular the capability to filter the sources via black lists and
white lists. In the MLD model, the Router is a "querier" and the 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 Host is a multicast listener that registers to the querier to obtain
copies of the particular flows it is interested in. copies of the particular flows it is interested in.
On the first Address Registration, as illustrated in Figure 7, the On the first Address Registration, as illustrated in Figure 8, the
6LN, as an MLD listener, sends an unsolicited Report to the 6LR in 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in
order to start receiving the flow immediately. Since multicast order to start receiving the flow immediately. Since multicast
Layer-2 messages are avoided, it is important that the asynchronous Layer-2 messages are avoided, it is important that the asynchronous
messages for unsolicited Report and Done are sent reliably, for messages for unsolicited Report and Done are sent reliably, for
instance using an Layer-2 acknoledgement, or attempted multiple instance using an Layer-2 acknoledgement, or attempted multiple
times. times.
The 6LR acts as a generic MLD querier and generates a DAO for the 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 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 of the Query Interval, yet larger to account for variable propagation
skipping to change at page 24, line 31 skipping to change at page 25, line 31
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | <if not listening> | | | | <if not listening> |
| | | unsolicited Report | | | | unsolicited Report |
| | |------------------->| | | |------------------->|
| | | | | | | |
| | | | | | | |
Figure 7: First Multicast Registration Flow Figure 8: First Multicast Registration Flow
An Address re-Registration is pulled by 6LR acting as querier. Note An Address re-Registration is pulled by 6LR acting as querier. Note
that the message may be sent unicast to all the known individual that the message may be sent unicast to all the known individual
listeners. Upon a time out of the Query Interval, the 6LR sends a listeners. Upon a time out of the Query Interval, the 6LR sends a
Query to each of its listeners, and gets a Report back that is mapped Query to each of its listeners, and gets a Report back that is mapped
into a DAO, as illustrated in Figure 8: into a DAO, as illustrated in Figure 9:
6LN 6LR Root 6LBR 6LN 6LR Root 6LBR
| | | | | | | |
| Query | | | | Query | | |
|<-------------------| | | |<-------------------| | |
| Report | | | | Report | | |
|------------------->| | | |------------------->| | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | | | | | |
| | | Query | | | | Query |
| | |<-------------------| | | |<-------------------|
| | | Report | | | | Report |
| | |------------------->| | | |------------------->|
| | | | | | | |
| | | | | | | |
Figure 8: Next Registration Flow Figure 9: Next Registration Flow
Note that any of the functions 6LR, Root and 6LBR might be collapsed 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, in a single node, in which case the flow above happens internally,
and possibly through internal API calls as opposed to messaging. and possibly through internal API calls as opposed to messaging.
11. Security Considerations 11. Security Considerations
The LLN nodes depend on the 6LBR and the RPL participants for their 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 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 right devices are acting in these roles, so as to avoid threats such
skipping to change at page 28, line 29 skipping to change at page 29, line 29
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7400] Bormann, C., "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] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network "IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>. April 2017, <https://www.rfc-editor.org/info/rfc8138>.
skipping to change at page 29, line 8 skipping to change at page 30, line 14
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, [AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", Work in Progress, Internet-Draft, draft- Lossy Networks", Work in Progress, Internet-Draft, draft-
ietf-6lo-ap-nd-12, 10 April 2019, ietf-6lo-ap-nd-13, 6 January 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-12>. <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-13>.
[USEofRPLinfo] [USEofRPLinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", Work in IPv6 encapsulation in the RPL Data Plane", Work in
Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-32, Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-34,
4 November 2019, <https://tools.ietf.org/html/draft-ietf- 20 January 2020, <https://tools.ietf.org/html/draft-ietf-
roll-useofrplinfo-32>. roll-useofrplinfo-34>.
[EFFICIENT-NPDAO] [EFFICIENT-NPDAO]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", Work in Progress, Internet-Draft, Route Invalidation", Work in Progress, Internet-Draft,
draft-ietf-roll-efficient-npdao-17, 30 October 2019, draft-ietf-roll-efficient-npdao-17, 30 October 2019,
<https://tools.ietf.org/html/draft-ietf-roll-efficient- <https://tools.ietf.org/html/draft-ietf-roll-efficient-
npdao-17>. npdao-17>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
skipping to change at page 30, line 27 skipping to change at page 31, line 33
Wireless Personal Area Network (6LoWPAN) Paging Dispatch", Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016, RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>. <https://www.rfc-editor.org/info/rfc8025>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
Appendix A. Example Compression Appendix A. Example Compression
Figure 9 illustrates the case in Storing Mode where the packet is Figure 10 illustrates the case in Storing Mode where the packet is
received from the Internet, then the Root encapsulates the packet to 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 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]. to the final destination, which is not known to support [RFC8138].
The difference with the format presented in Figure 19 of [RFC8138] is The difference with the format presented in Figure 19 of [RFC8138] is
the addition of a SRH-6LoRH before the RPI-6LoRH to transport the the addition of a SRH-6LoRH before the RPI-6LoRH to transport the
destination address of the outer IPv6 header. destination address of the outer IPv6 header.
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-4bytes-> <- RFC 6282 -> <-4bytes-> <- RFC 6282 ->
No RPL artifact No RPL artifact
Figure 9: Encapsulation to Parent 6LR in Storing Mode Figure 10: Encapsulation to Parent 6LR in Storing Mode
In Figure 9, the source of the IP-in-IP encapsulation is the Root, so In Figure 10, the source of the IP-in-IP encapsulation is the Root,
it is elided in the IP-in-IP 6LoRH. The destination is the parent 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. 6LR of the destination of the inner packet so it cannot be elided.
In Storing Mode, it is placed as the single entry in an SRH-6LoRH as In Storing Mode, it is placed as the single entry in an SRH-6LoRH as
the first 6LoRH. Since there is a single entry so the SRH-6LoRH Size the first 6LoRH. Since there is a single entry so the SRH-6LoRH Size
is 0. In this particular example, the 6LR address can be compressed is 0. 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 to 2 bytes so a Type of 1 is used. It results that the total length
of the SRH-6LoRH is 4 bytes. of the SRH-6LoRH is 4 bytes.
In Non-Storing Mode, the encapsulation from the Root would be similar In Non-Storing Mode, the encapsulation from the Root would be similar
to that represented in Figure 9 with possibly more hops in the SRH- to that represented in Figure 10 with possibly more hops in the SRH-
6LoRH and possibly multiple SRH-6LoRHs if the various addresses in 6LoRH and possibly multiple SRH-6LoRHs if the various addresses in
the routing header are not compressed to the same format. Note that 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 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 from the compressed form, so the use of Non-Storing Mode vs. Storing
Mode is indistinguishable from the packet format. Mode is indistinguishable from the packet format.
Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP Follows the RPI-6LoRH and then the IP-in-IP 6LoRH. When the IP-in-IP
6LoRH is removed, all the Router headers that precede it are also 6LoRH is removed, all the Router headers that precede it are also
removed. removed.
The Paging Dispatch [RFC8025] may also be removed if there was no 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 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 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 in Page 1. The resulting packet to the destination is the inner
packet compressed with [RFC6282]. packet compressed with [RFC6282].
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D, 45 Allee des Ormes - BP1200 Building D
45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis 06254 Mougins - Sophia Antipolis
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Michael C. Richardson Michael C. Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
 End of changes. 39 change blocks. 
69 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/