draft-ietf-roll-routing-dispatch-00.txt   draft-ietf-roll-routing-dispatch-01.txt 
roll P. Thubert, Ed. roll P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: September 22, 2016 Uni Bremen TZI Expires: March 20, 2017 Uni Bremen TZI
L. Toutain L. Toutain
IMT-TELECOM Bretagne IMT-TELECOM Bretagne
R. Cragie R. Cragie
ARM ARM
March 21, 2016 September 16, 2016
6LoWPAN Routing Header 6LoWPAN Routing Header
draft-ietf-roll-routing-dispatch-00 draft-ietf-roll-routing-dispatch-01
Abstract Abstract
This specification introduces a new 6LoWPAN dispatch type for use in This specification introduces a new 6LoWPAN dispatch type for use in
6LoWPAN Route-Over topologies, that initially covers the needs of RPL 6LoWPAN Route-Over topologies, that initially covers the needs of RPL
(RFC6550) data packets compression. Using this dispatch type, this (RFC6550) data packets compression. Using this dispatch type, this
specification defines a method to compress RPL Option (RFC6553) specification defines a method to compress RPL Option (RFC6553)
information and Routing Header type 3 (RFC6554), an efficient IP-in- information and Routing Header type 3 (RFC6554), an efficient IP-in-
IP technique and is extensible for more applications. IP technique and is extensible for more applications.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 22, 2016. This Internet-Draft will expire on March 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 1, line 63 skipping to change at page 1, line 63
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Using the Page Dispatch . . . . . . . . . . . . . . . . . . . 6 3. Using the Page Dispatch . . . . . . . . . . . . . . . . . . . 6
3.1. New Routing Header Dispatch (6LoRH) . . . . . . . . . . . 6 3.1. New Routing Header Dispatch (6LoRH) . . . . . . . . . . . 6
3.2. Placement Of 6LoRH headers . . . . . . . . . . . . . . . 6 3.2. Placement Of 6LoRH headers . . . . . . . . . . . . . . . 7
3.2.1. Relative To Non-6LoRH Headers . . . . . . . . . . . . 7 3.2.1. Relative To Non-6LoRH Headers . . . . . . . . . . . . 7
3.2.2. Relative To Other 6LoRH Headers . . . . . . . . . . . 7 3.2.2. Relative To Other 6LoRH Headers . . . . . . . . . . . 7
4. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 8 4. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 8
4.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 8 4.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 8
4.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 9 4.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 9
4.3. Compressing Addresses . . . . . . . . . . . . . . . . . . 9 4.3. Compressing Addresses . . . . . . . . . . . . . . . . . . 9
4.3.1. Coalescence . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Coalescence . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. DODAG Root Address Determination . . . . . . . . . . 10 4.3.2. DODAG Root Address Determination . . . . . . . . . . 10
5. The SRH 6LoRH Header . . . . . . . . . . . . . . . . . . . . 11 5. The SRH 6LoRH Header . . . . . . . . . . . . . . . . . . . . 11
5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 1, line 85 skipping to change at page 1, line 85
5.2.1. Uncompressed SRH Operation . . . . . . . . . . . . . 13 5.2.1. Uncompressed SRH Operation . . . . . . . . . . . . . 13
5.2.2. 6LoRH-Compressed SRH Operation . . . . . . . . . . . 13 5.2.2. 6LoRH-Compressed SRH Operation . . . . . . . . . . . 13
5.2.3. Inner LOWPAN_IPHC Compression . . . . . . . . . . . . 14 5.2.3. Inner LOWPAN_IPHC Compression . . . . . . . . . . . . 14
5.3. The Design Point of Popping Entries . . . . . . . . . . . 14 5.3. The Design Point of Popping Entries . . . . . . . . . . . 14
5.4. Compression Reference for SRH-6LoRH header entries . . . 15 5.4. Compression Reference for SRH-6LoRH header entries . . . 15
5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 16 5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 16
5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17
6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 17 6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 17
6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 19 6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 19
6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 19 6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 19
6.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 19 6.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 20
7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 22 7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Management Considerations . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.2. New 6LoWPAN Routing Header Type Registry . . . . . . . . 24 10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 27
A.1. Examples Compressing The RPI . . . . . . . . . . . . . . 26 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Example Of Downward Packet In Non-Storing Mode . . . . . 28 A.1. Examples Compressing The RPI . . . . . . . . . . . . . . 28
A.3. Example of SRH-6LoRH life-cycle . . . . . . . . . . . . . 30 A.2. Example Of Downward Packet In Non-Storing Mode . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 A.3. Example of SRH-6LoRH life-cycle . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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, a very constrained resource in most cases. focused on saving energy, a very constrained resource in most cases.
The other constraints, such as the memory capacity and the duty The other constraints, such as the memory capacity and the duty
cycling of the LLN devices, derive from that primary concern. Energy cycling of the LLN devices, derive from that primary concern. Energy
is often available from primary batteries that are expected to last is often available from primary batteries that are expected to last
for years, or is scavenged from the environment in very limited for years, or is scavenged from the environment in very limited
quantities. Any protocol that is intended for use in LLNs must be quantities. Any protocol that is intended for use in LLNs must be
skipping to change at page 1, line 136 skipping to change at page 1, line 137
identification, source routing information, etc. identification, source routing information, etc.
For reasons such as security and the capability to send ICMP errors For reasons such as security and the capability to send ICMP errors
back to the source, an original packet must not be tampered with, and back to the source, an original packet must not be tampered with, and
any information that must be inserted in or removed from an IPv6 any information that must be inserted in or removed from an IPv6
packet must be placed in an extra IP-in-IP encapsulation. This is packet must be placed in an extra IP-in-IP encapsulation. This is
the case when the additional routing information is inserted by a the case when the additional routing information is inserted by a
router on the path of a packet, for instance a mesh root, as opposed router on the path of a packet, for instance a mesh root, as opposed
to the source node. This is also the case when some routing to the source node. This is also the case when some routing
information must be removed from a packet that flows outside the LLN. information must be removed from a packet that flows outside the LLN.
When to use RFC 6553, 6554 and IPv6-in-IPv6 When to use RFC 6553, RFC 6554 and IPv6-in-IPv6
[I-D.robles-roll-useofrplinfo] details different cases where RFC [I-D.ietf-roll-useofrplinfo] details different cases where RFC 6553,
6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the bases
bases to help defining the compression of RPL routing information in to help defining the compression of RPL routing information in LLN
LLN environments. environments.
When using [RFC6282] the outer IP header of an IP-in-IP encapsulation When using [RFC6282] the outer IP header of an IP-in-IP encapsulation
may be compressed down to 2 octets in stateless compression and down may be compressed down to 2 octets in stateless compression and down
to 3 octets in stateful compression when context information must be to 3 octets in stateful compression when context information must be
added. added.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
skipping to change at page 1, line 276 skipping to change at page 1, line 277
3.1. New Routing Header Dispatch (6LoRH) 3.1. New Routing Header Dispatch (6LoRH)
This specification introduces a new 6LoWPAN Routing Header (6LoRH) to This specification introduces a new 6LoWPAN Routing Header (6LoRH) to
carry IPv6 routing information. The 6LoRH may contain source routing carry IPv6 routing information. The 6LoRH may contain source routing
information such as a compressed form of SRH, as well as other sorts information such as a compressed form of SRH, as well as other sorts
of routing information such as the RPI and IP-in-IP encapsulation. of routing information such as the RPI and IP-in-IP encapsulation.
The 6LoRH is expressed in a 6loWPAN packet as a Type-Length-Value The 6LoRH is expressed in a 6loWPAN packet as a Type-Length-Value
(TLV) field, which is extensible for future use. (TLV) field, which is extensible for future use.
It is expected that a router that does not recognize the 6LoRH
general format detailed in Section 4 will drop the packet when a
6LoRH is present.
This specification uses the bit pattern 10xxxxxx in Page 1 for the This specification uses the bit pattern 10xxxxxx in Page 1 for the
new 6LoRH Dispatch. Section 4 describes how RPL artifacts in data new 6LoRH Dispatch. Section 4 describes how RPL artifacts in data
packets can be compressed as 6LoRH headers. packets can be compressed as 6LoRH headers.
3.2. Placement Of 6LoRH headers 3.2. Placement Of 6LoRH headers
3.2.1. Relative To Non-6LoRH Headers 3.2.1. Relative To Non-6LoRH Headers
Paging Dispatch is parsed and no subsequent Paging Dispatch has been Paging Dispatch is parsed and no subsequent Paging Dispatch has been
parsed, the parsing of the packet MUST follow this specification if parsed, the parsing of the packet MUST follow this specification if
the 6LoRH Bit Pattern Section 3.1 is found. the 6LoRH Bit Pattern Section 3.1 is found.
With this specification, the 6LoRH Dispatch is only defined in Page With this specification, the 6LoRH Dispatch is only defined in Page
context is active. context is active.
Because a 6LoRH header requires a Page 1 context, it MUST always be Because a 6LoRH header requires a Page 1 context, it MUST always be
skipping to change at page 1, line 344 skipping to change at page 1, line 350
compressed form, it is a design point for this specification that the compressed form, it is a design point for this specification that the
SRH entries are consumed as the packet progresses down the LLN SRH entries are consumed as the packet progresses down the LLN
Section 5.3. In order to make this operation simpler in the Section 5.3. In order to make this operation simpler in the
compressed form, it is REQUIRED that the in the compressed form, the compressed form, it is REQUIRED that the in the compressed form, the
addresses along the source route path are encoded in the order of the addresses along the source route path are encoded in the order of the
path, and that the compressed SRH are placed before the compressed path, and that the compressed SRH are placed before the compressed
RPI. RPI.
4. 6LoWPAN Routing Header General Format 4. 6LoWPAN Routing Header General Format
The 6LoRH usesthe Dispatch Value Bit Pattern of 10xxxxxx in Page 1. The 6LoRH uses the Dispatch Value Bit Pattern of 10xxxxxx in Page 1.
The Dispatch Value Bit Pattern is split in two forms of 6LoRH: The Dispatch Value Bit Pattern is split in two forms of 6LoRH:
Elective (6LoRHE) that may skipped if not understood Elective (6LoRHE) that may skipped if not understood
Critical (6LoRHC) that may not be ignored Critical (6LoRHC) that may not be ignored
for each form, a Type field is used to encode the type of 6LoRH.
Note that there is a different registry for the Type field of each
form of 6LoRH, This means that that a value for the Type that is
defined for one form of 6LoRH may be redefined in the future for the
other form.
4.1. Elective Format 4.1. Elective Format
The 6LoRHE uses the Dispatch Value Bit Pattern of 101xxxxx. A 6LoRHE The 6LoRHE uses the Dispatch Value Bit Pattern of 101xxxxx. A 6LoRHE
may be ignored and skipped in parsing. If it is ignored, the 6LoRHE may be ignored and skipped in parsing. If it is ignored, the 6LoRHE
is forwarded with no change inside the LLN. is forwarded with no change inside the LLN.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | | |1|0|1| Length | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- Length --> <-- Length -->
Figure 3: Elective 6LoWPAN Routing Header. Figure 3: Elective 6LoWPAN Routing Header.
Length: Length: Length of the 6LoRHE expressed in bytes, excluding the first
Length of the 6LoRHE expressed in bytes, excluding the first 2 2 bytes. This enables a node to skip a 6LoRHE header that it
bytes. This enables a node to skip a 6LoRHE header that it
does not support and/or cannot parse, for instance if the Type does not support and/or cannot parse, for instance if the Type
is not recognized. is not recognized.
Type: Type: Type of the 6LoRHE
Type of the 6LoRHE
4.2. Critical Format 4.2. Critical Format
The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx. The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx.
A node which does not support the 6LoRHC Type MUST silently discard A node which does not support the 6LoRHC Type MUST silently discard
the packet. the packet.
Note: The situation where a node receives a message with a Critical Note: the situation where a node receives a message with a Critical
6LoWPAN Routing Header that it does not understand is a critical 6LoWPAN Routing Header that it does not understand should not occur
administrative error whereby the wrong device is placed in a network. and is an administrative error, see Section 8.
It makes no sense to overburden the constrained device with code that
would send an ICMP error to the source. Rather, it is expected that
the device will raise some management alert indicating that it cannot
operate in this network for that reason. As a result, there is no
provision for the exchange of error messages for this situation, so
it should be avoided by judicious use of administrative control and/
or capability indications by the device manufacturer.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|0| TSE | Type | | |1|0|0| TSE | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- Length implied by Type/TSE --> <-- Length implied by Type/TSE -->
Figure 4: Critical 6LoWPAN Routing Header. Figure 4: Critical 6LoWPAN Routing Header.
TSE: TSE: Type Specific Extension. The meaning depends on the Type,
Type Specific Extension. The meaning depends on the Type,
which must be known in all of the nodes. The interpretation of which must be known in all of the nodes. The interpretation of
the TSE depends on the Type field that follows. For instance, the TSE depends on the Type field that follows. For instance,
it may be used to transport control bits, the number of it may be used to transport control bits, the number of
elements in an array, or the length of the remainder of the elements in an array, or the length of the remainder of the
6LoRHC expressed in a unit other than bytes. 6LoRHC expressed in a unit other than bytes.
Type: Type: Type of the 6LoRHC
Type of the 6LoRHC
4.3. Compressing Addresses 4.3. Compressing Addresses
The general technique used in this draft to compress an address is The general technique used in this draft to compress an address is
first to determine a reference that as a long prefix match with this first to determine a reference that as a long prefix match with this
address, and then elide that matching piece. In order to reconstruct address, and then elide that matching piece. In order to reconstruct
the compress address, the receiving node will perform the process of the compress address, the receiving node will perform the process of
coalescence described in section Section 4.3.1. coalescence described in section Section 4.3.1.
One possible reference is the root of the RPL DODAG that is being One possible reference is the root of the RPL DODAG that is being
skipping to change at page 1, line 511 skipping to change at page 1, line 512
It is expected that the RPL implementation maintains an abstract It is expected that the RPL implementation maintains an abstract
context table, indexed by Global RPLInstanceID, that provides the context table, indexed by Global RPLInstanceID, that provides the
address of the root of the DODAG that this nodes participates to for address of the root of the DODAG that this nodes participates to for
that particular RPL Instance. that particular RPL Instance.
5. The SRH 6LoRH Header 5. The SRH 6LoRH Header
5.1. Encoding 5.1. Encoding
The Source Routing Header 6LoRH (SRH-6LoRH) header is a Critical A Source Routing Header 6LoRH (SRH-6LoRH) header provides a
6LoWPAN Routing Header that provides a compressed form for the SRH, compressed form for the SRH, as defined in [RFC6554] for use by RPL
as defined in [RFC6554] for use by RPL routers. Routers that need to routers.
forward a packet with a SRH-6LoRH are expected to be RPL routers and
are expected to support this specification. If a non-RPL router One or more SRH-6LoRH header(s) MAY be placed in a 6LoWPAN packet.
receives a packet with a SRH-6LoRH, this means that there was a
routing error and the packet should be dropped so the Type cannot be If a non-RPL router receives a packet with a SRH-6LoRH header, there
ignored. was a routing or a configuration error (see Section 8).
The desired reaction for the non-RPL router is to drop the packet as
opposed to skip the header and forward the packet.
The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates
Critical. Routers that understand the 6LoRH general format detailed
in Section 4 cannot ignore a 6LoRH header of this type, and will drop
the packet if it is unknown to them.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Size indicates the number of compressed addresses Where N = Size + 1
Figure 6: The SRH-6LoRH. Figure 6: The SRH-6LoRH.
The 6LoRH Type indicates the compression level used in a given SRH- The 6LoRH Type of a SRH-6LoRH header indicates the compression level
6LoRH header. used for that header.
One or more 6LoRH header(s) MAY be placed in a 6LoWPAN packet.
It results that all addresses in a given SRH-6LoRH header MUST be It results that all addresses in a given SRH-6LoRH header MUST be
compressed in an identical fashion, down to using the identical compressed in an identical fashion, down to using the identical
number of bytes per address. In order to get different degrees of number of bytes per address. In order to get different degrees of
compression, multiple consecutive SRH-6LoRH headers MUST be used. compression, multiple consecutive SRH-6LoRH headers MUST be used.
Type 0 means that the address is compressed down to one byte, whereas Type 0 means that the address is compressed down to one byte, whereas
Type 4 means that the address is provided in full in the SRH-6LoRH Type 4 means that the address is provided in full in the SRH-6LoRH
with no compression. The complete list of Types of SRH-6LoRH and the with no compression. The complete list of Types of SRH-6LoRH and the
corresponding compression level are provided in Figure 7: corresponding compression level are provided in Figure 7:
skipping to change at page 1, line 765 skipping to change at page 1, line 773
At the end of the process, if there is no more SRH-6LoRH in the At the end of the process, if there is no more SRH-6LoRH in the
packet, then the processing node is the last router along the source packet, then the processing node is the last router along the source
route path. route path.
5.6. Forwarding 5.6. Forwarding
When receiving a packet with a SRH-6LoRH, a router determines the When receiving a packet with a SRH-6LoRH, a router determines the
IPv6 address of the current segment endpoint. IPv6 address of the current segment endpoint.
If strict source routing is enforced and thus router is not the If strict source routing is enforced and this router is not the
segment endpoint for the packet then this router MUST drop the segment endpoint for the packet then this router MUST drop the
packet. packet.
If this router is the current segment endpoint, then the router pops If this router is the current segment endpoint, then the router pops
its address as described in Section 5.5 and continues processing the its address as described in Section 5.5 and continues processing the
packet. packet.
If there is still a SRH-6LoRH, then the router determines the new If there is still a SRH-6LoRH, then the router determines the new
segment endpoint and routes the packet towards that endpoint. segment endpoint and routes the packet towards that endpoint.
skipping to change at page 1, line 842 skipping to change at page 1, line 850
For that reason, this specification defines an IP-in-IP-6LoRH header For that reason, this specification defines an IP-in-IP-6LoRH header
in Section 7, but it must be noted that removal of a 6LoRH header in Section 7, but it must be noted that removal of a 6LoRH header
does not require manipulation of the packet in the LOWPAN_IPHC, and does not require manipulation of the packet in the LOWPAN_IPHC, and
thus, if the source address in the LOWPAN_IPHC is the node that thus, if the source address in the LOWPAN_IPHC is the node that
inserted the IP-in-IP-6LoRH header then this situation alone does not inserted the IP-in-IP-6LoRH header then this situation alone does not
mandate an IP-in-IP-6LoRH header. mandate an IP-in-IP-6LoRH header.
Note: A typical packet in RPL non-storing mode going down the RPL Note: A typical packet in RPL non-storing mode going down the RPL
graph requires an IP-in-IP encapsulation of the SRH, whereas the RPI graph requires an IP-in-IP encapsulation of the SRH, whereas the RPI
is usually (and quite illegally) omitted, unless it is important to is usually (and quite illegally) omitted. With this specification,
indicate the RPLInstanceID. To match this structure, an optimized the RPI is important to indicate the RPLInstanceID so the RPI should
IP-in-IP 6LoRH header is defined in Section 7. not be omitted. To impact of placing an IP-in-IP encapsulation and
an RPI in the packet, an optimized IP-in-IP 6LoRH header is defined
in Section 7.
As a result, a RPL packet may bear only an RPI-6LoRH header and no As a result, a RPL packet may bear only an RPI-6LoRH header and no
IP-in-IP-6LoRH header. In that case, the source and destination of IP-in-IP-6LoRH header. In that case, the source and destination of
the packet are specified by the LOWPAN_IPHC. the packet are specified by the LOWPAN_IPHC.
As with [RFC6553], the fields in the RPI include an 'O', an 'R', and As with [RFC6553], the fields in the RPI include an 'O', an 'R', and
an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), an 'F' bit, an 8-bit RPLInstanceID (with some internal structure),
and a 16-bit SenderRank. and a 16-bit SenderRank.
The remainder of this section defines the RPI-6LoRH header, which is The remainder of this section defines the RPI-6LoRH header, which is
skipping to change at page 1, line 901 skipping to change at page 1, line 911
DEFAULT_MIN_HOP_RANK_INCREASE. DEFAULT_MIN_HOP_RANK_INCREASE.
This specification allows to encode the SenderRank as either one or This specification allows to encode the SenderRank as either one or
two bytes, and defines a K flag that, when set, signals that a single two bytes, and defines a K flag that, when set, signals that a single
byte is used. byte is used.
6.3. The Overall RPI-6LoRH encoding 6.3. The Overall RPI-6LoRH encoding
The RPI-6LoRH header provides a compressed form for the RPL RPI. The RPI-6LoRH header provides a compressed form for the RPL RPI.
Routers that need to forward a packet with a RPI-6LoRH header are Routers that need to forward a packet with a RPI-6LoRH header are
expected to be RPL routers that support this specification. If a expected to be RPL routers that support this specification.
non-RPL router receives a packet with a RPI-6LoRH header, there was a
routing error and the packet should be dropped. Thus the Type field
MUST NOT be ignored.
Since the I flag is not set, the TSE field does not need to be a If a non-RPL router receives a packet with a RPI-6LoRH header, there
length expressed in bytes. In that case the field is fully reused was a routing or a configuration error (see Section 8).
for control bits that encode the O, R and F flags from the RPI, as
well as the I and K flags that indicate the compression format. The desired reaction for the non-RPL router is to drop the packet as
opposed to skip the header and forward the packet, which could end up
forming loops by reinjecting the packet in the wrong RPL Instance.
The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates
Critical. Routers that understand the 6LoRH general format detailed
in Section 4 cannot ignore a 6LoRH header of this type, and will drop
the packet if it is unknown to them.
Since the RPI-6LoRH header is a critical header, the TSE field does
not need to be a length expressed in bytes. In that case the field
is fully reused for control bits that encode the O, R and F flags
from the RPI, as well as the I and K flags that indicate the
compression format.
The Type for the RPI-6LoRH is 5. The Type for the RPI-6LoRH is 5.
The RPI-6LoRH header is immediately followed by the RPLInstanceID The RPI-6LoRH header is immediately followed by the RPLInstanceID
field, unless that field is fully elided, and then the SenderRank, field, unless that field is fully elided, and then the SenderRank,
which is either compressed into one byte or fully in-lined as two which is either compressed into one byte or fully in-lined as two
bytes. The I and K flags in the RPI-6LoRH header indicate whether bytes. The I and K flags in the RPI-6LoRH header indicate whether
the RPLInstanceID is elided and/or the SenderRank is compressed. the RPLInstanceID is elided and/or the SenderRank is compressed.
Depending on these bits, the Length of the RPI-6LoRH may vary as Depending on these bits, the Length of the RPI-6LoRH may vary as
described hereafter. described hereafter.
skipping to change at page 1, line 932 skipping to change at page 1, line 952
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
|1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields | |1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
Figure 9: The Generic RPI-6LoRH Format. Figure 9: The Generic RPI-6LoRH Format.
O, R, and F bits: The O, R, and F bits are defined in [RFC6550], O, R, and F bits: The O, R, and F bits are defined in [RFC6550],
section 11.2. section 11.2.
I bit: If it is set, the RPLInstanceID is elided and the I flag: If it is set, the RPLInstanceID is elided and the
RPLInstanceID is the Global RPLInstanceID 0. If it is not set, RPLInstanceID is the Global RPLInstanceID 0. If it is not set,
the octet immediately following the type field contains the the octet immediately following the type field contains the
RPLInstanceID as specified in [RFC6550], section 5.1. RPLInstanceID as specified in [RFC6550], section 5.1.
K bit: If it is set, the SenderRank is compressed into one octet, K flag: If it is set, the SenderRank is compressed into one octet,
with the least significant octet elided. If it is not set, the with the least significant octet elided. If it is not set, the
SenderRank, is fully inlined as two octets. SenderRank, is fully inlined as two octets.
In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and
the MinHopRankIncrease is a multiple of 256 so the least significant the MinHopRankIncrease is a multiple of 256 so the least significant
byte is all zeros and can be elided: byte is all zeros and can be elided:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 1, line 1009 skipping to change at page 1, line 1029
An IP-in-IP encapsulation is used to insert a field such as a Routing An IP-in-IP encapsulation is used to insert a field such as a Routing
Header or an RPI at a router that is not the source of the packet. Header or an RPI at a router that is not the source of the packet.
In order to send an error back regarding the inserted field, the In order to send an error back regarding the inserted field, the
address of the router that performs the insertion must be provided. address of the router that performs the insertion must be provided.
The encapsulation can also enable the last router prior to The encapsulation can also enable the last router prior to
Destination to remove a field such as the RPI, but this can be done Destination to remove a field such as the RPI, but this can be done
in the compressed form by removing the RPI-6LoRH, so an IP-in-IP- in the compressed form by removing the RPI-6LoRH, so an IP-in-IP-
6LoRH encapsulation is not required for that sole purpose. 6LoRH encapsulation is not required for that sole purpose.
This field is not critical for routing so the Type can be ignored, The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates
and the TSE field contains the Length in bytes. Elective. This field is not critical for routing since it does not
indicate the destination of the packet, which is either encoded in a
SRH-6LoRH header or in the inner IP header. A 6LoRH header of this
type can be skipped if not understood (per Section 4), and the 6LoRH
header indicates the Length in bytes.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address | |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 14: The IP-in-IP-6LoRH. Figure 14: The IP-in-IP-6LoRH.
The Length of an IP-in-IP-6LoRH header is expressed in bytes and MUST The Length of an IP-in-IP-6LoRH header is expressed in bytes and MUST
skipping to change at page 1, line 1039 skipping to change at page 1, line 1063
The most efficient compression of an IP-in-IP encapsulation that can The most efficient compression of an IP-in-IP encapsulation that can
be achieved with this specification is obtained when an endpoint of be achieved with this specification is obtained when an endpoint of
the packet is the root of the RPL DODAG associated to the RPL the packet is the root of the RPL DODAG associated to the RPL
Instance that is used to forward the packet, and the root address is Instance that is used to forward the packet, and the root address is
known implicitly as opposed to signaled explicitly in the data known implicitly as opposed to signaled explicitly in the data
packets. packets.
If the Length of an IP-in-IP-6LoRH header is greater than 1, then an If the Length of an IP-in-IP-6LoRH header is greater than 1, then an
Encapsulator Address is placed in a compressed form after the Hop Encapsulator Address is placed in a compressed form after the Hop
Limit field. The value of the Length indicates which compression is Limit field. The value of the Length indicates which compression is
performed on the Encapsulator Address. For instance, a Size of 3 performed on the Encapsulator Address. For instance, a Length of 3
indicates that the Encapsulator Address is compressed to 2 bytes. indicates that the Encapsulator Address is compressed to 2 bytes.
The reference for the compression is the address of the root of the The reference for the compression is the address of the root of the
DODAG. The way the address of the root is determined is discussed in DODAG. The way the address of the root is determined is discussed in
Section 4.3.2. Section 4.3.2.
With RPL, the destination address in the IP-in-IP header is With RPL, the destination address in the IP-in-IP header is
implicitly the root in the RPL graph for packets going upwards, and, implicitly the root in the RPL graph for packets going upwards, and,
in storing mode, it is the destination address in the IPHC for in storing mode, it is the destination address in the IPHC for
packets going downwards. In non-storing mode, there is no implicit packets going downwards. In non-storing mode, there is no implicit
value for packets going downwards. value for packets going downwards.
skipping to change at page 1, line 1067 skipping to change at page 1, line 1091
support this specification, then the chain of 6LoRH headers must be support this specification, then the chain of 6LoRH headers must be
stripped by the RPL/6LR router to which the leaf is attached. In stripped by the RPL/6LR router to which the leaf is attached. In
that example, the destination IP address of the IP-in-IP header that example, the destination IP address of the IP-in-IP header
cannot be elided. cannot be elided.
In the special case where a 6LoRH header is used to route 6LoWPAN In the special case where a 6LoRH header is used to route 6LoWPAN
fragments, the destination address is not accessible in the IPHC on fragments, the destination address is not accessible in the IPHC on
all fragments and can be elided only for the first fragment and for all fragments and can be elided only for the first fragment and for
packets going upwards. packets going upwards.
8. Security Considerations 8. Management Considerations
Though it is possible to decompress a packet at any hop, this
specification is optimized to enable that a packet is forwarded in
its compressed form all the way, and it makes sense to deploy
homogeneous networks, where all nodes, or no node at all, use the
compression technique detailed therein.
This specification does not provide a method to discover the
capability by a next-hop device to support the compression technique,
or the incremental addition of 6LoWPAN Routing Header as new
specifications are published, considering that such extraneous code
would overburden many constrained devices. This specification does
not require extraneous code to exchange and handle error messages for
mismatch situations, either.
It is thus critical to keep the network homogeneous, or at least
provide in forwarding nodes the knowledge of the support by the next
hops. This is either a deployment issue, by deploying only devices
with a same capability, or a management issue, by configuring all
devices to either use, or not use, a certain level of this
compression technique and its future additions.
In particular, the situation where a node receives a message with a
Critical 6LoWPAN Routing Header that it does not understand is an
administrative error whereby the wrong device is placed in a network,
or the device is mis-configured.
When a mismatch situation is detected, it is expected that the device
raises some management alert, indicating the issue, e.g. that it has
to drop a packet with a Critical 6LoRH.
9. Security Considerations
The security considerations of [RFC4944], [RFC6282], and [RFC6553] The security considerations of [RFC4944], [RFC6282], and [RFC6553]
apply. apply.
Using a compressed format as opposed to the full in-line format is Using a compressed format as opposed to the full in-line format is
logically equivalent and is believed to not create an opening for a logically equivalent and is believed to not create an opening for a
new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. new threat when compared to [RFC6550], [RFC6553] and [RFC6554],
noting that, even though intermediate hops are removed from the SRH
9. IANA Considerations header as they are consumed, a node may still identify that the rest
of the source routed path includes a loop or not (see Security
section of [RFC6554]. It must be noted that if the attacker is not
part of the loop, then there is always a node at the beginning of the
loop that can detect it and remove it.
10. IANA Considerations
This specification reserves Dispatch Value Bit Patterns within the This specification reserves Dispatch Value Bit Patterns within the
6LoWPAN Dispatch Page 1 as follows: 6LoWPAN Dispatch Page 1 as follows:
101xxxxx: for Elective 6LoWPAN Routing Headers 101xxxxx: for Elective 6LoWPAN Routing Headers
100xxxxx: for Critical 6LoWPAN Routing Headers. 100xxxxx: for Critical 6LoWPAN Routing Headers.
9.2. New 6LoWPAN Routing Header Type Registry Additionally this document creates two IANA registries, one for the
Critical 6LoWPAN Routing Header Type and one for the Elective 6LoWPAN
Routing Header Type, each with 32 possible values from 0 to 31, as
described below.
This document creates an IANA registry for the 6LoWPAN Routing Header Future assignments in these registries are to be coordinated via IANA
Type, and assigns the following values: under the policy of "RFC Required" [RFC5226] to enable any type of
RFC to obtain a value in the registry.
10.2. New Critical 6LoWPAN Routing Header Type Registry
This document creates an IANA registry for the Critical 6LoWPAN
Routing Header Type, and assigns the following values:
0..4: SRH-6LoRH [RFCthis] 0..4: SRH-6LoRH [RFCthis]
5: RPI-6LoRH [RFCthis] 5: RPI-6LoRH [RFCthis]
<- under the policy of "IETF Review" [RFC5226] to ensure adequate
community review. -> ## New Elective 6LoWPAN Routing Header Type
Registry
This document creates an IANA registry for the Elective 6LoWPAN
Routing Header Type, and assigns the following value:
6: IP-in-IP-6LoRH [RFCthis] 6: IP-in-IP-6LoRH [RFCthis]
10. Acknowledgments <- under the policy of "IETF Review" [RFC5226] to ensure adequate
community review. ->
11. Acknowledgments
The authors wish to thank Tom Phinney, Thomas Watteyne, Tengfei The authors wish to thank Tom Phinney, Thomas Watteyne, Tengfei
Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan
Hui, Gabriel Montenegro and Ralph Droms for constructive reviews to Hui, Gabriel Montenegro and Ralph Droms for constructive reviews to
the design in the 6lo Working Group. The overall discussion involved the design in the 6lo Working Group. The overall discussion involved
participants to the 6MAN, 6TiSCH and ROLL WGs, thank you all. participants to the 6MAN, 6TiSCH and ROLL WGs, thank you all.
Special thanks to the chairs of the ROLL WG, Michael Richardson and Special thanks to the chairs of the ROLL WG, Michael Richardson and
Ines Robles, and Brian Haberman, Internet Area A-D, and Adrian Ines Robles, Brian Haberman, Internet Area A-D, and Alvaro Retana and
Farrel, Routing Area A-D, for driving this complex effort across Adrian Farrel, Routing Area A-Ds, for driving this complex effort
Working Groups and Areas. across Working Groups and Areas.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-6lo-paging-dispatch] [I-D.ietf-6lo-paging-dispatch]
Thubert, P., "6LoWPAN Paging Dispatch", draft-ietf-6lo- Thubert, P. and R. Cragie, "6LoWPAN Paging Dispatch",
paging-dispatch-01 (work in progress), January 2016. draft-ietf-6lo-paging-dispatch-04 (work in progress),
September 2016.
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks", 2015. Wireless Personal Area Networks", 2015.
[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 25, line 10 skipping to change at page 26, line 36
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>. <http://www.rfc-editor.org/info/rfc4944>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <http://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
skipping to change at page 25, line 39 skipping to change at page 27, line 22
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,
<http://www.rfc-editor.org/info/rfc6553>. <http://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>. <http://www.rfc-editor.org/info/rfc6554>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 12.2. Informative References
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
11.2. Informative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), November 2015. in progress), June 2016.
[I-D.robles-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-robles-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-02 (work in progress), October 2015. useofrplinfo-08 (work in progress), September 2016.
[I-D.thubert-6lo-forwarding-fragments] [I-D.thubert-6lo-forwarding-fragments]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-6lo-forwarding-fragments-02 (work Recovery", draft-thubert-6lo-forwarding-fragments-02 (work
in progress), November 2014. in progress), November 2014.
[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,
<http://www.rfc-editor.org/info/rfc6775>. <http://www.rfc-editor.org/info/rfc6775>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>. <http://www.rfc-editor.org/info/rfc7554>.
Appendix A. Examples Appendix A. Examples
A.1. Examples Compressing The RPI A.1. Examples Compressing The RPI
 End of changes. 45 change blocks. 
104 lines changed or deleted 189 lines changed or added

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