draft-ietf-roll-unaware-leaves-03.txt   draft-ietf-roll-unaware-leaves-04.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
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: March 2, 2020 August 30, 2019 Expires: March 12, 2020 September 9, 2019
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-03 draft-ietf-roll-unaware-leaves-04
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. hosts and do not participate to RPL.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 March 2, 2020. This Internet-Draft will expire on March 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 6 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6
4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 8 3.1. RFC 6775 . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 9 3.2. RFC 8505 Extended ARO . . . . . . . . . . . . . . . . . . 7
6. 6LN Requirements to be a RPL-Unware Leaf . . . . . . . . . . 9 3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 9 3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8
6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 10 3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 10 3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9
6.2.2. Support of the Routing Header . . . . . . . . . . . . 10 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 9
6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 11 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 10
7. Updated RPL Target option . . . . . . . . . . . . . . . . . . 11 6. 6LN Requirements to be a RPL-Unware Leaf . . . . . . . . . . 10
8. Protocol Operations for Unicast Addresses . . . . . . . . . . 12 6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 10
8.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 12 6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 11
8.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 12 6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 11
8.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 14 6.2.2. Support of the Routing Header . . . . . . . . . . . . 11
8.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 12
8.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 15 7. Updated RPL Target option . . . . . . . . . . . . . . . . . . 12
8.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 16 8. Protocol Operations for Unicast Addresses . . . . . . . . . . 13
8.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 18 8.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 13
8.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 19 8.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 14
9. Protocol Operations for Multicast Addresses . . . . . . . . . 20 8.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 16
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 8.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 18
12.1. RPL Target Option Flags . . . . . . . . . . . . . . . . 22 8.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 20
8.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 21
9. Protocol Operations for Multicast Addresses . . . . . . . . . 21
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. RPL Target Option Flags . . . . . . . . . . . . . . . . 24
12.2. New Subsubregistry for the Status values of the RPL DAO- 12.2. New Subsubregistry for the Status values of the RPL DAO-
ACK Message . . . . . . . . . . . . . . . . . . . . . . 22 ACK Message . . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Example Compression . . . . . . . . . . . . . . . . 26 Appendix A. Example Compression . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 6, line 37 skipping to change at page 7, line 4
RAL: RPL-Aware Leaf RAL: RPL-Aware Leaf
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RUL: RPL-Unaware Leaf RUL: RPL-Unaware Leaf
TID: Transaction ID (a sequence counter in the EARO) TID: Transaction ID (a sequence counter in the EARO)
3. 6LoWPAN Neighbor Discovery 3. 6LoWPAN Neighbor Discovery
3.1. RFC 6775
The "IPv6 Neighbor Discovery (IPv6 ND) Protocol" (NDP) suite The "IPv6 Neighbor Discovery (IPv6 ND) Protocol" (NDP) suite
[RFC4861] [RFC4862] was defined for transit media such a Ethernet, [RFC4861] [RFC4862] was defined for transit media such a Ethernet,
and relies heavily on multicast operations for address discovery and and relies heavily on multicast operations for address discovery and
duplicate address detection (DAD). duplicate address detection (DAD).
"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
(6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained (6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained
LLNs. In particular, 6LoWPAN ND introduces a unicast host address LLNs. In particular, 6LoWPAN ND introduces a unicast host address
registration mechanism that contributes to reducing the use of registration mechanism that contributes to reducing the use of
multicast messages that are present in the classical IPv6 ND multicast messages that are present in the classical IPv6 ND
protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) protocol. 6LoWPAN ND defines a new Address Registration Option (ARO)
that is carried in the unicast Neighbor Solicitation (NS) and that is carried in the unicast Neighbor Solicitation (NS) and
Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN)
and the 6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate and the 6LoWPAN Router (6LR).
Address Request (DAR) and Duplicate Address Confirmation (DAC)
messages 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 domain.
"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 6LoWPAN ND also defines the Duplicate Address Request (DAR) and
updates the behavior of RFC 6775 to enable a generic registration to Duplicate Address Confirmation (DAC) messages between the 6LR and the
routing services and defines an Extended ARO (EARO). The format of 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the central
the EARO is shown in Figure 1: repository of all the Registered Addresses in its domain.
The main functions of [RFC6775] are to proactively establish the
Neighbor Cache Entry in the 6LR and to avoid address duplication.
There is no concept of registering the address for an external
service such as RPL routing. That feature is introduced with
"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505].
3.2. RFC 8505 Extended ARO
[RFC8505] updates the behavior of RFC 6775 to enable a generic
registration to services such as routing, and defines an Extended ARO
(EARO). The format of the EARO is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque | | Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime | | Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier ... ... Registration Ownership Verifier ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EARO Option Format Figure 1: EARO Option Format
[RFC8505] specifies the use of the R flag in the EARO by the 3.2.1. R Flag
Registering Node. With [RFC8505], the Registering Node sets the R
flag to indicate whether the 6LR should ensure reachability for the [RFC8505] introduces the R flag in the EARO. The Registering Node
Registered Address, e.g., by means of routing or proxying ND. sets the R flag to indicate whether the 6LR should ensure
Adapted to this specification, this means that a 6LN operates as a reachability for the Registered Address, e.g., by means of routing or
RUL for an IPv6 address iff it sets the R flag in the NS(EARO) used proxying ND. If the R flag is not set, then the Registering Node is
to register the address. If the R flag is not set, then the expected to be a RAN that handles the reachability of the Registered
Registering Node is expected to be a RAN that handles the Address by itself.
reachability of the Registered Address by itself. Conversely, this
document specifies a behavior of a RPL router acting as 6LR for the This document specifies how the R flag is used in the context of RPL.
registration 6LR that depends on the setting of the R flag in the A 6LN operates as a RUL for an IPv6 address iff it sets the R flag in
NS(EARO). The RPL router generates a DAO message for the Registered the NS(EARO) used to register the address. The RPL router generates
Address upon an NS(EARO) iff the R flag in the EARO is set. a DAO message for the Registered Address upon an NS(EARO) iff the R
flag in the EARO is set. Conversely, this document specifies a
behavior of a RPL router acting as 6LR for the registration 6LR that
depends on the setting of the R flag in the NS(EARO).
3.2.2. TID, I Field and Opaque Fields
The EARO also includes a sequence counter called Transaction ID The EARO also includes a sequence counter called Transaction ID
(TID), which maps to the Path Sequence Field found in Transit Options (TID), which maps to the Path Sequence Field found in Transit Options
in RPL DAO messages. This is the reason why the support of [RFC8505] in RPL DAO messages. This is the reason why the support of [RFC8505]
by the RUL as opposed to only [RFC6775] is a prerequisite for this by the RUL as opposed to only [RFC6775] is a prerequisite for this
specification (more in Section 6.1). The EARO also transports an specification (more in Section 6.1). The EARO also transports an
Opaque field and an "I" field that describes what the Opaque field Opaque field and an "I" field that describes what the Opaque field
transports and how to use it. transports and how to use it. Section 8.2.1 specifies the use of the
"I" field and of the Opaque field by a RUL.
Section 8.2.1 specifies the use of the R flag, of the "I" field and 3.2.3. ROVR
of the Opaque field by a RUL.
Section 5.3. of [RFC8505] introduces the Registration Ownership
Verifier (ROVR) field of a variable length from 64 to 256 bits. The
ROVR is a replacement of the EUI-64 field in the ARO [RFC6775] that
was used to identify uniquely a registration based on the Link-Layer
address of the owner but provided no protection against spoofing.
"Address Protected Neighbor Discovery for Low-power and Lossy "Address Protected Neighbor Discovery for Low-power and Lossy
Networks" [I-D.ietf-6lo-ap-nd] protects the ownership of an address Networks" [I-D.ietf-6lo-ap-nd] leverages the ROVR field as a
and enables a challenge that is leveraged by this specification. It cryptographic proof of ownership to prevent a rogue third party from
also enables Source Address Validation by a 6LR that will drop the misusing the address. [I-D.ietf-6lo-ap-nd] adds a challenge/response
packets that are sourced at an address that is not registered. exchange to the [RFC8505] registration and enables Source Address
Validation by a 6LR that will drop packets with a spoofed address.
This specification does not address how the protection by
[I-D.ietf-6lo-ap-nd] could be extended to RPL. On the other hand, it
adds the ROVR to the DAO to build the proxied EDAR at the Root, which
means that nodes that are aware of the host route to the 6LN are now
aware of the associated ROVR as well.
3.3. RFC 8505 Extended DAR/DAC
[RFC8505] updates the periodic DAR/DAC exchange that takes place
between the 6LR and the 6LBR using Extended DAR/DAC messages. The
Extended Duplicate Address messages can carry the ROVR field of
variable size. The periodic EDAR/EDAC exchange is triggered by a
NS(EARO) message and is intended to create and then refresh the
corresponding state in the 6LBR for a lifetime that is indicated by
the 6LN. Conversely, RPL [RFC6550] specifies a periodic DAO from the
6LN all the way to the Root that maintains the routing state in 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
the whole network to indicate that an address is still reachable, one
to the Root and one to the 6LBR. This represents a waste of
bandwidth and energy that can be undesirable in an LLN.
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
needs to perform a [RFC8505] registration to the 6LR. The 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 behalf of the
6LR. This is illustrated in Figure 4.
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 8) and multicast messages for unicast addresses (see Section 8) and multicast
addresses (see Section 9) on behalf of leaves that are not aware of addresses (see Section 9) 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. This specification updates RPL correctly outside of the RPL domain.
[RFC6550] to mandate that External Routes are advertised using Non-
Storing Mode signaling even in a Storing-Mode network in order to
inform the root of the address of the 6LR that terminates the IP-in-
IP tunnel.
[RFC8505] specifies a periodic EDAR/EDAC exchange that takes place
between the 6LR and the 6LBR. It is triggered by a NS(EARO) message
and is intended to create and then refresh the corresponding state in
the 6LBR for a lifetime that is indicated by the 6LN. Conversely,
RPL [RFC6550] specifies a periodic DAO that maintains the routing
state in 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 the whole network to indicate that an address is still
reachable, one to the Root and one to the 6LBR.
This document synchronizes the liveness monitoring at the Root and This document synchronizes the liveness monitoring at the Root and
the 6LBR. A same value of lifetime is used for both, and a single the 6LBR. A same value of lifetime is used for both, and a single
keep alive message, the RPL DAO, traverses the RPL network. A new keep alive message, the RPL DAO, traverses the RPL network. A new
behavior is introduced whereby the RPL Root proxies the EDAR message behavior is introduced whereby the RPL Root proxies the EDAR message
to the 6LBR on behalf of the 6LR (more in Section 5). [RFC6550] is to the 6LBR on behalf of the 6LR (more in Section 5). [RFC6550] is
updated with new RPL Status values for use in DAO-ACK and DCO that updated with new RPL Status values for use in DAO-ACK and DCO that
map the 6LoWNAN ND values defined in Table 1 of [RFC8505]. The map the 6LoWPAN ND values defined in Table 1 of [RFC8505]. The
Resulting set is shown in Table 1. The Status code are listed in the resulting set is shown in Table 1.
same order and DAO-ACK Status code of 128 maps to 6LoWPAN ND Status
Code of 1.
Section 5.3. of [RFC8505] introduces the Registration Ownership Section 6.7. of [RFC6550] introduces the RPL Control Message Options
Verifier (ROVR) of a variable length from 64 to 256 bits. A ROVR is such as the RPL Target Option that can be included in a RPL Control
created by the Registering Node and associated to the registration of Message such as the DAO. Section 7 updates the RPL Target Option to
an IPv6 Address. It is used to detect a duplication (DAD) and may optionally transport the ROVR used in the IPv6 Registration (see
also enable the Registering Node to prove its ownership of the Section 3.2.3) so the RPL Root can generate a full EDAR Message.
Registered Address [I-D.ietf-6lo-ap-nd]. Section 6.7. of [RFC6550]
introduces the RPL Control Message Options such as the RPL Target
Option that can be included in a RPL Control Message such as the DAO.
This document updates the RPL Target Option to optionally transport a
ROVR, more in Section 7. This enables the RPL Root to generate a
full EDAR Message as opposed to a keep-alive EDAR that has restricted
properties.
5. Updating RFC 8505 5. Updating RFC 8505
This document updates [RFC8505] to introduce a keep-alive EDAR This document updates [RFC8505] to introduce a keep-alive EDAR
message and a keep-alive NS(EARO) message. The keep-alive messages message and a keep-alive NS(EARO) message. The keep-alive messages
are used for backward compatibility, when the DAO does not transport are used for backward compatibility, when the DAO does not transport
a ROVR as specified in Section 7. The keep-alive messages have a a ROVR as specified in Section 7. The keep-alive messages have a
zero ROVR field and can only be used to refresh a pre-existing state zero ROVR field and can only be used to refresh a pre-existing state
associated to the Registered Address. More specifically, a keep- associated to the Registered Address. More specifically, a keep-
alive message can only increase the lifetime and/or increment the TID alive message can only increase the lifetime and/or increment the TID
of the existing state in a 6LBR. of the existing state in a 6LBR.
Upon the renewal of a 6LoWPAN ND registration, this specification Upon the renewal of a 6LoWPAN ND registration, this specification
changes the behavior of a RPL router acting as 6LR for the changes the behavior of a RPL router acting as 6LR for the
registration as follows: if the Root indicates the capability to registration as follows. If the Root indicates the capability to
proxy the EDAR/EDAC exchange to the 6LBR then the 6LR refrains from proxy the EDAR/EDAC exchange to the 6LBR then the 6LR refrains from
sending an EDAR message. If the Root is separated from the 6LBR, the sending an EDAR message; if the Root is separated from the 6LBR, the
Root regenerates the EDAR message to the 6LBR upon a DAO message that Root regenerates the EDAR message to the 6LBR upon a DAO message that
signals the liveliness of the Address. signals the liveliness of the Address.
6. 6LN Requirements to be a RPL-Unware Leaf 6. 6LN Requirements to be a 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
a plain host and not aware of RPL. Still, a minimal RPL-independent a plain host and not aware of RPL. Still, a minimal RPL-independent
functionality is expected from the 6LN in order to obtain routing functionality is expected from the 6LN 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
A RUL MUST implement [RFC8505] and set the R flag in the EARO option. A RUL MUST implement [RFC8505] and set the R flag in the EARO option.
A 6LN is considered to be a RUL if and only if it sets the R flag in A 6LN is considered to be a RUL if and only if it sets the R flag in
the EARO. the EARO.
A RUL SHOULD implement [RFC8505] and set the R flag in the EARO A RUL MUST register to all the 6LRs from which it expects to get
option. A 6LN is considered to be a RUL if and only if it sets the R routing services. The registrations SHOULD be performed in a rapid
flag in the EARO. sequence, using the exact same EARO for a same Address. Gaps between
the registrations will invalidate some of the routes till the
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 suggested by [RFC8505] depending on the Status value. as specified by [RFC8505] depending on the Status value.
A RUL SHOULD supports [I-D.ietf-6lo-ap-nd] to protect the ownership A RUL SHOULD support [I-D.ietf-6lo-ap-nd] to protect the ownership of
of its addresses. its addresses.
6.2. External Routes and RPL Artifacts 6.2. External Routes and RPL Artifacts
Section 4.1. of [I-D.ietf-roll-useofrplinfo] provides a set of rules
that MUST be 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. When IP-in-IP is used and the outer headers called RPL artifacts. When IP-in-IP is used and the outer headers
terminate at a 6LR down the path (see Figure 8 for the format in terminate at a 6LR down the path (see Figure 8 for the compressed
Storing Mode), then the 6LR decapsulates the IP-in-IP and the packet format in Storing Mode), then the 6LR decapsulates the IP-in-IP and
that is forwarded to the external destination is free of RPL the packet that is forwarded to the external destination is free of
artifacts. RPL artifacts - but possibly an RPI if packet was generated by a RAN
in the same RPL domain as the destination RUL.
IP-in-IP to the 6LR MUST be used if the final destination cannot An IP-in-IP tunnel to a 6LR that injected the route is used for
handle or ignore the RPL artifacts or the way they are compressed external routes unless the final destination is known to handle or
[RFC8138]. An External route indicates by default a node or a prefix ignore the RPL artifacts properly [RFC8200]. Non-Storing Mode
that is not known to handle or ignore the RPL artifacts. The signaling is used to signal external routes to the Root, which
RECOMMENDED behaviour when using IP-in-IP to an External route is enables to advertise the tunnel endpoint. A RUL is an example of
that the outer headers terminate at the 6LR that injected the target that is reachable via an external host route and is expected
External route. Non-Storing Mode signaling MUST be used to inject to ignore the RPI and the consumed SRH artifacts. In the case of a
External routes to the Root in order to advertise the 6LR that is RUL, tunneling may not be necessary.
associated to a RUL.
In order to save the IP-in-IP encapsulation and to support Storing A RUL may not support IP-in-IP tunneling [RFC8504], so if IP-in-IP is
Mode of operation, it is preferred that the 6LN can ignore an RPI and used, and unless the Root as a better knowledge, the tunnel should
consume a routing header in both the native and [RFC8138]-compressed terminate at the 6LR that injected the external route to the RUL.
forms. In order to enable IP-in-IP to a 6LN in Non-Storing Mode, it
is also of interest that the 6LN supports decapsulating IP-in-IP in Additionally, the RUL cannot be expected to support the compression
both forms. method defined in [RFC8138]. The 6LR that injected the route
uncompresses the packet before forwarding over an external route,
even when delivering to a RUL, even when it is not the destination of
the incoming packet.
6.2.1. Support of the HbH Header 6.2.1. Support of the HbH Header
A RUL is expected to process an unknown Option Type in a Hop-by-Hop A RUL is expected to process an unknown Option Type in a Hop-by-Hop
Header as prescribed by section 4.2 of [RFC8200]. This means in Header as prescribed by section 4.2 of [RFC8200]. This means in
particular that an RPI with an Option Type of 0x23 particular that an RPI with an Option Type of 0x23
[I-D.ietf-roll-useofrplinfo] is ignored when not understood. [I-D.ietf-roll-useofrplinfo] is ignored when not understood.
6.2.2. Support of the Routing Header 6.2.2. Support of the Routing Header
A RUL is expected to process an unknown Routing Header Type as A RUL is expected to process an unknown Routing Header Type as
prescribed by section 4.4 of [RFC8200]. This means in particular prescribed by section 4.4 of [RFC8200]. This means in particular
that Routing Header with a Routing Type of 3 [RFC6553] is ignored that Routing Header with a Routing Type of 3 [RFC6553] is ignored
when the Segments Left is zero, and dropped otherwise. when the Segments Left is zero, and dropped otherwise.
6.2.3. Support of IPv6 Encapsulation 6.2.3. Support of IPv6 Encapsulation
A RUL may support IPv6-in-IPv6 decapsulation when it is the Section 2.1 of [I-D.ietf-roll-useofrplinfo] sets the rules for
destination of the outer header but that is not assumed by [RFC8504]. forwarding IP-in-IP either to the final 6LN or to a parent 6LR. In
If the 6LN is a RUL, it may be able to drop the inner packet if it is order to enable IP-in-IP to the 6LN in Non-Storing Mode, the 6LN must
not the destination of the inner header. By default the IP-in-IP be able to decapsulate the tunneled packet and either drop the inner
tunnel should terminate at the parent 6LR so supporting this packet if it is not the final destination, or pass it to the upper
capability in a RUL is secondary. layer for further processing. Unless it is aware that the RUL can
handle IP-in-IP properly, the Root that encapsulates a packet to a
RUL terminates the IP-in-IP tunnel at the parent 6LR . For that
reason, it is beneficial but not necessary for a RUL to support IP-
in-IP.
7. Updated RPL Target option 7. 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 2. The Target Prefix MUST be aligned ROVR as illustrated in Figure 2. This enables the RPL Root to
to the next 4-byte boundary after the size indicated by the Prefix generate a full EDAR Message as opposed to a keep-alive EDAR that has
Length. if necessary it is padded with zeros. The size of the ROVR restricted properties. The Target Prefix MUST be aligned to the next
is indicated in a new ROVR Type field that is encoded to map the 4-byte boundary after the size indicated by the Prefix Length. if
CodePfx in the EDAR message (see section 4.2 of [RFC8505]). With necessary it is padded with zeros. The size of the ROVR is indicated
this specification the ROVR is the remainder of the RPL Target in a new ROVR Type field that is encoded to map the CodePfx in the
Option. EDAR message (see section 4.2 of [RFC8505]). With this specification
the ROVR is the remainder of the RPL Target Option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length |ROVRsz | Flags | Prefix Length | | Type = 0x05 | Option Length |ROVRsz | Flags | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Target Prefix (Variable Length) | | Target Prefix (Variable Length) |
. Aligned to 4-byte boundary . . Aligned to 4-byte boundary .
skipping to change at page 13, line 45 skipping to change at page 14, line 51
A re-registration is performed by the 6LN to maintain the NCE in the A re-registration is performed by the 6LN to maintain the NCE in the
6LR alive before lifetime expires. Upon a re-registration, as 6LR alive before lifetime expires. Upon a re-registration, as
illustrated in Figure 4, the 6LR redistributes the Registered Address illustrated in Figure 4, the 6LR redistributes the Registered Address
NS(EARO) in RPL. NS(EARO) in RPL.
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
a keep-alive EDAC message. The keep-alive EDAC lacks the a keep-alive EDAC message. The keep-alive EDAC lacks the
Registration Ownership Verifier (ROVR) information, since it is not Registration Ownership Verifier (ROVR) information, since it is not
present in RPL DAO messages, but the EDAC message sent in response by present in RPL DAO messages, but the EDAC message sent in response by
the 6LBR contains the actual value of the ROVR field for that the 6LBR contains the actual value of the ROVR field for that
registration. This enables the RPL Root to perform the proxy- registration.
registration for the Registered Address and attract traffic captured
over the backbone by the 6BBR and route it back to the device.
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 4: Next Registration Flow in Non-Storing Mode Figure 4: Next Registration Flow in Non-Storing Mode
In case of an error on the keep-alive EDAR flow, the error SHOULD be In case of an error on the keep-alive EDAR flow, the error SHOULD be
returned in the DAO-ACK - if one was requested - using the mapping of returned in the DAO-ACK - if one was requested - using the mapping of
RPL Status and 6LoWPAN Status values discussed in Section 4. RPL Status and 6LoWPAN Status values discussed in Section 4.
If the Root could not return the negative Status in the DAO-ACK then If the Root could not return the negative Status in the DAO-ACK then
it sends an asynchronous Destination Cleanup Object (DCO) message it sends an asynchronous Destination Cleanup Object (DCO) message
[I-D.ietf-roll-efficient-npdao] to the 6LR indicating the issue with [I-D.ietf-roll-efficient-npdao] to the 6LR indicating the issue with
skipping to change at page 14, line 41 skipping to change at page 15, line 43
interval of time, the DAO-ACK and DCO messages are not guaranteed to interval of time, the DAO-ACK and DCO messages are not guaranteed to
arrive in the same order at the 6LR. So the 6LR must still expect a arrive in the same order at the 6LR. So the 6LR must still expect a
DAO-ACK even if it received a DCO while it was waiting for an DAO-ACK even if it received a DCO while it was waiting for an
acknowledgement for a short period of time, but the negative status acknowledgement for a short period of time, but the negative status
in the DCO supercedes a positive status in the DAO-ACK regardless of in the DCO supercedes a positive status in the DAO-ACK regardless of
the order in which they are received. the order in which they are received.
Upon the DAO-ACK - or the DCO if it arrives first - the 6LR responds Upon the DAO-ACK - or the DCO if it arrives first - the 6LR responds
to the RUL with a NA(EARO) and the 6LoWPAN ND Status value that is to the RUL with a NA(EARO) and the 6LoWPAN ND Status value that is
mapped from the RPL status in the RPL message. An asynchronous DCO mapped from the RPL status in the RPL message. An asynchronous DCO
is also mapped in an asynchronous NA(EARO) to the RUL with a mapped is also translated in an asynchronous NA(EARO) to the RUL with a
Status value. mapped Status value. The RPL Status values that are mapped with
6LoWPAN ND are in the range 128 to 192 and listed in the same order
(see Table 1). A RPL Status Value of 128 maps to 6LoWPAN ND Status
Code of 1 and so on.
8.1.2. In RPL Storing-Mode 8.1.2. In RPL Storing-Mode
In Storing Mode, the DAO-ACK is optional. When it is used, it is In Storing Mode, the DAO-ACK is optional. When it is used, it is
generated by the RPL parent, which does not need to wait for the generated by the RPL parent, which does not need to wait for the
grand-parent to send the acknowledgement. A successful DAO-ACK is grand-parent to send the acknowledgement. A successful DAO-ACK is
not a guarantee that the DAO has yet reached the Root or that the not a guarantee that the DAO has yet reached the Root or that the
keep-alive EDAR has succeeded. keep-alive EDAR has succeeded.
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 [I-D.ietf-roll-efficient-npdao] as illustrated in a DCO message [I-D.ietf-roll-efficient-npdao] as illustrated in
Figure 5 and described in further details in Section 8.2.3. Figure 5 and described in further details in Section 8.2.3.
6LN 6LR 6LR Root 6BBR 6LN 6LR 6LR Root 6LBR
| | | | | | | | | |
| NS(EARO) | | | | | NS(EARO) | | | |
|-------------->| | | | |-------------->| | | |
| NA(EARO) | | | | | NA(EARO) | | | |
|<--------------| | | | |<--------------| | | |
| | | | | | | | | |
| | DAO | | | | | DAO | | |
| |-------------->| | | | |-------------->| | |
| | DAO-ACK | | | | | DAO-ACK | | |
| |<--------------| | | | |<--------------| | |
skipping to change at page 20, line 42 skipping to change at page 22, line 10
start receiving the flow immediately. Since multicast Layer-2 start receiving the flow immediately. Since multicast Layer-2
messages are avoided, it is important that the asynchronous messages messages are avoided, it is important that the asynchronous messages
for unsolicited Report and Done are sent reliably, for instance using for unsolicited Report and Done are sent reliably, for instance using
an Layer-2 acknoledgement, or attempted multiple times. an Layer-2 acknoledgement, or attempted multiple 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
delays. delays.
The Root proxies the MLD echange as listener with the 6BBR acting as The Root proxies the MLD echange as listener with the 6LBR acting as
the querier, so as to get packets from a source external to the RPL 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 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 is already registered as a listener for that address, and if not,
it performs its own unsolicited Report for the multicast target. it performs its own unsolicited Report for the multicast target.
6LN 6LR Root 6LBR 6LN 6LR Root 6LBR
| | | | | | | |
| unsolicited Report | | | | unsolicited Report | | |
|------------------->| | | |------------------->| | |
| <L2 ack> | | | | <L2 ack> | | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | <if not listening> | | | | <if not listening> |
| | | unsolicited Report | | | | unsolicited Report |
| | |------------------->| | | |------------------->|
| | | | | | | |
| | | | | | | |
skipping to change at page 23, line 5 skipping to change at page 25, line 5
This specification creates a new subsubregistry for the Status values This specification creates a new subsubregistry for the Status values
of the RPL DAO-ACK Message, under the ICMPv6 parameters registry. of the RPL DAO-ACK Message, under the ICMPv6 parameters registry.
o Possible values are 8-bit unsigned integers (0..255). o Possible values are 8-bit unsigned integers (0..255).
o Registration procedure is "Standards Action" [RFC8126]. o Registration procedure is "Standards Action" [RFC8126].
o Initial allocation is as indicated in Table 1: o Initial allocation is as indicated in Table 1:
+---------+--------------------------------------+----------------+ +---------+-----------------------+---------------------------------+
| Value | Meaning | Defining Spec | | Value | Meaning | Defining Spec |
+---------+--------------------------------------+----------------+ +---------+-----------------------+---------------------------------+
| 0 | Unqualified acceptance | RFC6550 | | 0 | Unqualified | [RFC6550] |
| | | | | | acceptance | |
| 1-127 | Reserved for Warning Codes | RFC6550 | | | | |
| | | | | 1-127 | Reserved for Warning | [RFC6550] |
| 128 | Duplicate Address | This RFC | | | Codes | |
| | | | | | | |
| 129 | Out of Storage | This RFC | | 128 | Duplicate Address | This RFC |
| | | | | | | |
| 130 | Moved | This RFC | | 129 | Out of Storage | This RFC |
| | | | | | | |
| 131 | Removed | This RFC | | 130 | Moved | [I-D.ietf-roll-efficient-npdao] |
| | | | | | | |
| 132 | Validation Requested | This RFC | | 131 | Removed | This RFC |
| | | | | | | |
| 133 | Duplicate Source Address | This RFC | | 132 | Validation Requested | This RFC |
| | | | | | | |
| 134 | Invalid Source Address | This RFC | | 133 | Duplicate Source | This RFC |
| | | | | | Address | |
| 135 | Address topologically incorrect | This RFC | | | | |
| | | | | 134 | Invalid Source | This RFC |
| 136 | 6LBR Registry saturated | This RFC | | | Address | |
| | | | | | | |
| 137 | Validation Failed | This RFC | | 135 | Address topologically | This RFC |
| | | | | | incorrect | |
| 138-192 | Reserved for 6LoWPAN ND code mapping | This RFC | | | | |
| | | | | 136 | 6LBR Registry | This RFC |
| 193-255 | Reserved for other Rejection Codes | RFC6550 | | | saturated | |
+---------+--------------------------------------+----------------+ | | | |
| 137 | Validation Failed | This RFC |
| | | |
| 138-192 | Reserved for 6LoWPAN | This RFC |
| | ND code mapping | |
| | | |
| 193-255 | Reserved for other | [RFC6550] |
| | Rejection Codes | |
+---------+-----------------------+---------------------------------+
Table 1: Status values of the RPL DAO-ACK Message Table 1: Status values of the RPL DAO-ACK Message
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Georgios Papadopoulos for their early The authors wish to thank Georgios Papadopoulos for their early
reviews of and contributions to this document reviews of and contributions to this document
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 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", draft-ietf-6lo-ap-nd-12 (work in Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in
progress), April 2019. progress), April 2019.
[I-D.ietf-roll-efficient-npdao] [I-D.ietf-roll-efficient-npdao]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", draft-ietf-roll-efficient-npdao-15 Route Invalidation", draft-ietf-roll-efficient-npdao-16
(work in progress), July 2019. (work in progress), September 2019.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPL
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", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-31 (work in progress), August 2019. roll-useofrplinfo-31 (work in progress), August 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 27, line 11 skipping to change at page 29, line 23
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 8: Encapsulation to Parent 6LR in Storing Mode Figure 8: Encapsulation to Parent 6LR in Storing Mode
In Figure 8, the source of the IP-in-IP encapsulation is the Root, so In Figure 8, 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 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
 End of changes. 38 change blocks. 
177 lines changed or deleted 234 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/