diff options
Diffstat (limited to 'doc/rfc/rfc8138.txt')
| -rw-r--r-- | doc/rfc/rfc8138.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc8138.txt b/doc/rfc/rfc8138.txt new file mode 100644 index 0000000..da4db5b --- /dev/null +++ b/doc/rfc/rfc8138.txt @@ -0,0 +1,2075 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Thubert, Ed. +Request for Comments: 8138 Cisco +Category: Standards Track C. Bormann +ISSN: 2070-1721 Uni Bremen TZI + L. Toutain + IMT Atlantique + R. Cragie + ARM + April 2017 + + + IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) + Routing Header + +Abstract + + This specification introduces a new IPv6 over Low-Power Wireless + Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN + route-over topologies, which initially covers the needs of Routing + Protocol for Low-Power and Lossy Networks (RPL) data packet + compression (RFC 6550). Using this dispatch type, this specification + defines a method to compress the RPL Option (RFC 6553) information + and Routing Header type 3 (RFC 6554), an efficient IP-in-IP + technique, and is extensible for more applications. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8138. + + + + + + + + + + + + + +Thubert, et al. Standards Track [Page 1] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thubert, et al. Standards Track [Page 2] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Using the Page Dispatch . . . . . . . . . . . . . . . . . . . 7 + 3.1. New Routing Header Dispatch (6LoRH) . . . . . . . . . . . 7 + 3.2. Placement of 6LoRH Headers . . . . . . . . . . . . . . . 8 + 3.2.1. Relative to Non-6LoRH Headers . . . . . . . . . . . . 8 + 3.2.2. Relative to Other 6LoRH Headers . . . . . . . . . . . 8 + 4. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 9 + 4.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 10 + 4.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Compressing Addresses . . . . . . . . . . . . . . . . . . 11 + 4.3.1. Coalescence . . . . . . . . . . . . . . . . . . . . . 11 + 4.3.2. DODAG Root Address Determination . . . . . . . . . . 12 + 5. The SRH-6LoRH Header . . . . . . . . . . . . . . . . . . . . 13 + 5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.2. SRH-6LoRH General Operation . . . . . . . . . . . . . . . 14 + 5.2.1. Uncompressed SRH Operation . . . . . . . . . . . . . 14 + 5.2.2. 6LoRH-Compressed SRH Operation . . . . . . . . . . . 15 + 5.2.3. Inner LOWPAN_IPHC Compression . . . . . . . . . . . . 15 + 5.3. The Design Point of Popping Entries . . . . . . . . . . . 16 + 5.4. Compression Reference for SRH-6LoRH Header Entries . . . 17 + 5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 18 + 5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 19 + 6. The RPL Packet Information 6LoRH (RPI-6LoRH) . . . . . . . . 19 + 6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 21 + 6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 21 + 6.3. The Overall RPI-6LoRH Encoding . . . . . . . . . . . . . 21 + 7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 24 + 8. Management Considerations . . . . . . . . . . . . . . . . . . 26 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 27 + 10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 28 + 10.3. New Elective 6LoWPAN Routing Header Type Registry . . . 28 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 11.2. Informative References . . . . . . . . . . . . . . . . . 29 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 31 + A.1. Examples Compressing the RPI . . . . . . . . . . . . . . 31 + A.2. Example of a Downward Packet in Non-Storing Mode . . . . 32 + A.3. Example of SRH-6LoRH Life Cycle . . . . . . . . . . . . . 34 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + + + + + + +Thubert, et al. Standards Track [Page 3] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +1. Introduction + + The design of Low-Power and Lossy Networks (LLNs) is generally + focused on saving energy, a very constrained resource in most cases. + The other constraints, such as the memory capacity and the duty + cycling of the LLN devices, derive from that primary concern. Energy + is often available from primary batteries that are expected to last + for years, or it is scavenged from the environment in very limited + quantities. Any protocol that is intended for use in LLNs must be + designed with the primary concern of saving energy as a strict + requirement. + + Controlling the amount of data transmission is one possible venue to + save energy. In a number of LLN standards, the frame size is limited + to much smaller values than the guaranteed IPv6 Maximum Transmission + Unit (MTU) of 1280 bytes. In particular, an LLN that relies on the + classical Physical Layer (PHY) of IEEE 802.15.4 [IEEE.802.15.4] is + limited to 127 bytes per frame. The need to compress IPv6 packets + over IEEE 802.15.4 led to the writing of "Compression Format for IPv6 + Datagrams over IEEE 802.15.4-Based Networks" [RFC6282]. + + Innovative route-over techniques have been and still are being + developed for routing inside an LLN. Generally, such techniques + require additional information in the packet to provide loop + prevention and to indicate information such as flow identification, + source routing information, etc. + + For reasons such as security and the capability to send ICMPv6 errors + (see "Internet Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification" [RFC4443]) 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 packet + must be placed in an extra IP-in-IP encapsulation. + + This is the case when the additional routing information is inserted + by a router on the path of a packet, for instance, the root of a + mesh, as opposed to the source node, with the Non-Storing mode of the + "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" + [RFC6550]. + + This is also the case when some routing information must be removed + from a packet that flows outside the LLN. + + + + + + + + + +Thubert, et al. Standards Track [Page 4] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + "When to use RFC 6553, RFC 6554 and IPv6-in-IPv6" [RPL-INFO] details + different cases where IPv6 headers defined in the RPL Option for + Carrying RPL Information in Data-Plane Datagrams [RFC6553], Header + for Source Routes with RPL [RFC6554], and IPv6-in-IPv6 encapsulation, + are inserted or removed from packets in LLN environments operating + RPL. + + When using RFC 6282 [RFC6282], the outer IP header of an IP-in-IP + encapsulation may be compressed down to 2 octets in stateless + compression and down to 3 octets in stateful compression when context + information must be added. + + 0 1 + 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 | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + Figure 1: LOWPAN_IPHC Base Encoding (RFC 6282) + + The stateless compression of an IPv6 address can only happen if the + IPv6 address can de deduced from the Media Access Control (MAC) + addresses, meaning that the IP endpoint is also the MAC-layer + endpoint. This is usually not the case in a RPL network, which is + generally a multi-hop route-over (i.e., operated at Layer 3) network. + A better compression, which does not involve variable compressions + depending on the hop in the mesh, can be achieved based on the fact + that the outer encapsulation is usually between the source (or + destination) of the inner packet and the root. Also, the inner IP + header can only be compressed by RFC 6282 [RFC6282] if all the fields + preceding it are also compressed. This specification makes the inner + IP header the first header to be compressed by RFC 6282 [RFC6282], + and it keeps the inner packet encoded the same way whether or not it + is encapsulated, thus preserving existing implementations. + + As an example, RPL [RFC6550] is designed to optimize the routing + operations in constrained LLNs. As part of this optimization, RPL + requires the addition of RPL Packet Information (RPI) in every + packet, as defined in Section 11.2 of RFC 6550 [RFC6550]. + + "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option + for Carrying RPL Information in Data-Plane Datagrams" [RFC6553] + specification indicates how the RPI can be placed in a RPL Option + (RPL-OPT) that is placed in an IPv6 Hop-by-Hop header. + + This representation demands a total of 8 bytes, while, in most cases, + the actual RPI payload requires only 19 bits. Since the Hop-by-Hop + header must not flow outside of the RPL domain, it must be inserted + + + +Thubert, et al. Standards Track [Page 5] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + in packets entering the domain and be removed from packets that leave + the domain. In both cases, this operation implies an IP-in-IP + encapsulation. + + Additionally, in the case of the Non-Storing Mode of Operation (MOP), + RPL requires a Source Routing Header (SRH) in all packets that are + routed down a RPL graph. For that purpose, "An IPv6 Routing Header + for Source Routes with the Routing Protocol for Low-Power and Lossy + Networks (RPL)" [RFC6554] defines the type 3 Routing Header for IPv6 + (RH3). + + ------+--------- ^ + | Internet | + | | Native IPv6 + +-----+ | + | | Border Router (RPL Root) + | + + | | | | | + +-----+ | | | tunneled + | | | | using + o o o o | | | IPv6-in- + o o o o o o o o o | | | IPv6 and + o o o o o o o o o o | | | RPL SRH + o o o o o o o o o | | | + o o o o o o o o | | | + o o o o + v + + LLN + + Figure 2: IP-in-IP Encapsulation within the LLN + + With Non-Storing RPL, even if the source is a node in the same LLN, + the packet must first reach up the graph to the root so that the root + can insert the SRH to go down the graph. In any fashion, whether the + packet was originated in a node in the LLN or outside the LLN, and + regardless of whether or not the packet stays within the LLN, as long + as the source of the packet is not the root itself, the source- + routing operation also implies an IP-in-IP encapsulation at the root + in order to insert the SRH. + + "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4" + [IPv6-ARCH] specifies the operation of IPv6 over the mode of + operation described in "Using IEEE 802.15.4e Time-Slotted Channel + Hopping (TSCH) in the Internet of Things (IoT): Problem Statement" + [RFC7554]. The architecture requires the use of both RPL and the 6lo + adaptation layer over IEEE 802.15.4. Because it inherits the + constraints on frame size from the MAC layer, 6TiSCH cannot afford to + allocate 8 bytes per packet on the RPI, hence the requirement for + 6LoWPAN header compression of the RPI. + + + + +Thubert, et al. Standards Track [Page 6] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + An extensible compression technique is required that simplifies + IP-in-IP encapsulation when it is needed and optimally compresses + existing routing artifacts found in RPL LLNs. + + This specification extends the 6lo adaptation layer framework + ([RFC4944] [RFC6282]) so as to carry routing information for route- + over networks based on RPL. It includes the formats necessary for + RPL and is extensible for additional formats. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + + This document uses the terms from, and is consistent with, "Terms + Used in Routing for Low-Power and Lossy Networks" [RFC7102] and RPL + [RFC6550]. + + The terms "route-over" and "mesh-under" are defined in RFC 6775 + [RFC6775]. + + Other terms in use in LLNs are found in "Terminology for Constrained- + Node Networks" [RFC7228]. + + The term "byte" is used in its now customary sense as a synonym for + "octet". + +3. Using the Page Dispatch + + The "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) + Paging Dispatch" [RFC8025] specification extends the 6lo adaptation + layer framework ([RFC4944] [RFC6282]) by introducing a concept of + "context" in the 6LoWPAN parser, a context being identified by a Page + number. The specification defines 16 Pages. + + This document operates within Page 1, which is indicated by a + dispatch value of binary 11110001. + +3.1. New Routing Header Dispatch (6LoRH) + + This specification introduces a new 6LoWPAN Routing Header (6LoRH) to + carry IPv6 routing information. The 6LoRH may contain source routing + 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. + + + + + +Thubert, et al. Standards Track [Page 7] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + The 6LoRH is expressed in a 6loWPAN packet as a Type-Length-Value + (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 + new 6LoRH Dispatch. Section 4 describes how RPL artifacts in data + packets can be compressed as 6LoRH headers. + +3.2. Placement of 6LoRH Headers + +3.2.1. Relative to Non-6LoRH Headers + + In a zone of a packet where Page 1 is active (that is, once the Page + 1 Paging Dispatch is parsed, and until another Paging Dispatch is + parsed as described in the 6LoWPAN Paging Dispatch specification + [RFC8025]), the parsing of the packet MUST follow this specification + if the 6LoRH Bit Pattern (see Section 3.1) is found. + + With this specification, the 6LoRH Dispatch is only defined in + Page 1, so it MUST be placed in the packet in a zone where the Page 1 + context is active. + + Because a 6LoRH header requires a Page 1 context, it MUST always be + placed after any Fragmentation Header and/or Mesh Header as defined + in RFC 4944 [RFC4944]. + + A 6LoRH header MUST always be placed before the LOWPAN_IPHC as + defined in RFC 6282 [RFC6282]. It is designed in such a fashion that + placing or removing a header that is encoded with 6LoRH does not + modify the part of the packet that is encoded with LOWPAN_IPHC, + whether or not there is an IP-in-IP encapsulation. For instance, the + final destination of the packet is always the one in the LOWPAN_IPHC, + whether or not there is a Routing Header. + +3.2.2. Relative to Other 6LoRH Headers + + The "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460] + defines chains of headers that are introduced by an IPv6 header and + terminated by either another IPv6 header (IP-in-IP) or an Upper-Layer + Protocol (ULP) header. When an outer header is stripped from the + packet, the whole chain goes with it. When one or more headers are + inserted by an intermediate router, that router normally chains the + headers and encapsulates the result in IP-in-IP. + + + + + +Thubert, et al. Standards Track [Page 8] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + With this specification, the chains of headers MUST be compressed in + the same order as they appear in the uncompressed form of the packet. + This means that if there is more than one nested IP-in-IP + encapsulation, the first IP-in-IP encapsulation, with all its chain + of headers, is encoded first in the compressed form. + + In the compressed form of a packet that has a Source Route or a Hop- + by-Hop (HbH) Options Header [RFC2460] after the inner IPv6 header + (e.g., if there is no IP-in-IP encapsulation), these headers are + placed in the 6LoRH form before the 6LOWPAN_IPHC that represents the + IPv6 header (see Section 3.2.1). If this packet gets encapsulated + and some other SRH or HbH Options Headers are added as part of the + encapsulation, placing the 6LoRH headers next to one another may + present an ambiguity on which header belongs to which chain in the + uncompressed form. + + In order to disambiguate the headers that follow the inner IPv6 + header in the uncompressed form from the headers that follow the + outer IP-in-IP header, it is REQUIRED that the compressed IP-in-IP + header is placed last in the encoded chain. This means that the + 6LoRH headers that are found after the last compressed IP-in-IP + header are to be inserted after the IPv6 header that is encoded with + the 6LOWPAN_IPHC when decompressing the packet. + + With regard to the relative placement of the SRH and the RPI in the + compressed form, it is a design point for this specification that the + SRH entries are consumed as the packet progresses down the LLN (see + Section 5.3). In order to make this operation simpler in the + compressed form, it is REQUIRED that in the compressed form, 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 + RPI. + +4. 6LoWPAN Routing Header General Format + + 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: + + Elective (6LoRHE), which may skipped if not understood + + Critical (6LoRHC), which 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. + + + + +Thubert, et al. Standards Track [Page 9] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + This means 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 + + 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 + is forwarded with no change inside the LLN. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ + |1|0|1| Length | Type | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ + <-- Length --> + + Figure 3: Elective 6LoWPAN Routing Header + + Length: Length of the 6LoRHE expressed in bytes, excluding the first + 2 bytes. This enables a node to skip a 6LoRHE header that it + does not support and/or cannot parse, for instance, if the Type + is not recognized. + + Type: Type of the 6LoRHE + +4.2. Critical Format + + The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx. + + A node that does not support the 6LoRHC Type MUST silently discard + the packet. + + Note: A situation where a node receives a message with a Critical + 6LoWPAN Routing Header that it does not understand should not occur + and is an administrative error, see Section 8. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ + |1|0|0| TSE | Type | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ + <-- Length implied by Type/TSE --> + + Figure 4: Critical 6LoWPAN Routing Header + + + + + + + +Thubert, et al. Standards Track [Page 10] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Type-Specific Extension (TSE): The meaning depends on the Type, + which must be known in all of the nodes. The interpretation of + the TSE depends on the Type field that follows. For instance, + it may be used to transport control bits, the number of + elements in an array, or the length of the remainder of the + 6LoRHC expressed in a unit other than bytes. + + Type: Type of the 6LoRHC + +4.3. Compressing Addresses + + The general technique used in this document to compress an address is + first to determine a reference that has a long prefix match with this + address and then elide that matching piece. In order to reconstruct + the compressed address, the receiving node will perform the process + of coalescence described in Section 4.3.1. + + One possible reference is the root of the RPL Destination-Oriented + Directed Acyclic Graph (DODAG) that is being traversed. It is used + by 6LoRH as the reference to compress an outer IP header in case of + an IP-in-IP encapsulation. If the root is the source of the packet, + this technique allows one to fully elide the source address in the + compressed form of the IP header. If the root is not the + encapsulator, then the Encapsulator Address may still be compressed + using the root as a reference. How the address of the root is + determined is discussed in Section 4.3.2. + + Once the address of the source of the packet is determined, it + becomes the reference for the compression of the addresses that are + located in compressed SRH headers that are present inside the IP-in- + IP encapsulation in the uncompressed form. + +4.3.1. Coalescence + + An IPv6 compressed address is coalesced with a reference address by + overriding the N rightmost bytes of the reference address with the + compressed address, where N is the length of the compressed address, + as indicated by the Type of the SRH-6LoRH header in Figure 7. + + The reference address MAY be a compressed address as well, in which + case, it MUST be compressed in a form that is of an equal or greater + length than the address that is being coalesced. + + A compressed address is expanded by coalescing it with a reference + address. In the particular case of a Type 4 SRH-6LoRH, the address + is expressed in full and the coalescence is a complete override as + illustrated in Figure 5. + + + + +Thubert, et al. Standards Track [Page 11] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + RRRRRRRRRRRRRRRRRRR A reference address, which may be + compressed or not + + CCCCCCC A compressed address, which may be + shorter or the same as the reference + + RRRRRRRRRRRRCCCCCCC A coalesced address, which may be the + same compression as the reference + + Figure 5: Coalescing Addresses + +4.3.2. DODAG Root Address Determination + + Stateful address compression requires that some state is installed in + the devices to store the compression information that is elided from + the packet. That state is stored in an abstract context table, and + some form of index is found in the packet to obtain the compression + information from the context table. + + With RFC 6282 [RFC6282], the state is provided to the stack by the + 6LoWPAN Neighbor Discovery Protocol (NDP) [RFC6775]. NDP exchanges + the context through the 6LoWPAN Context Option in Router + Advertisement (RA) messages. In the compressed form of the packet, + the context can be signaled in a Context Identifier Extension. + + With this specification, the compression information is provided to + the stack by RPL, and RPL exchanges it through the DODAGID field in + the DAG Information Object (DIO) messages, as described in more + detail below. In the compressed form of the packet, the context can + be signaled by the RPLInstanceID in the RPI. + + With RPL [RFC6550], the address of the DODAG root is known from the + DODAGID field of the DIO messages. For a Global Instance, the + RPLInstanceID that is present in the RPI is enough information to + identify the DODAG that this node participates with and its + associated root. But, for a Local Instance, the address of the root + MUST be explicit, either in some device configuration or signaled in + the packet, as the source or the destination address, respectively. + + When implicit, the address of the DODAG root MUST be determined as + follows: + + If the whole network is a single DODAG, then the root can be well- + known and does not need to be signaled in the packets. But, since + RPL does not expose that property, it can only be known by a + configuration applied to all nodes. + + + + + +Thubert, et al. Standards Track [Page 12] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Else, the router that encapsulates the packet and compresses it + with this specification MUST also place an RPI in the packet as + prescribed by RPL to enable the identification of the DODAG. The + RPI must be present even in the case when the router also places + an SRH header in the packet. + + It is expected that the RPL implementation maintains an abstract + context table, indexed by Global RPLInstanceID, that provides the + address of the root of the DODAG that this node participates in for + that particular RPL Instance. + +5. The SRH-6LoRH Header + +5.1. Encoding + + A Source Routing Header 6LoRH (SRH-6LoRH) provides a compressed form + for the SRH, as defined in RFC 6554 [RFC6554], for use by RPL + routers. + + One or more SRH-6LoRH header(s) MAY be placed in a 6LoWPAN packet. + + If a non-RPL router receives a packet with an SRH-6LoRH header, there + 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 skipping the header and forwarding the packet. + + The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates it + is 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 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ + + Where N = Size + 1 + + Figure 6: The SRH-6LoRH + + The 6LoRH Type of an SRH-6LoRH header indicates the compression level + used for that header. + + The fields following the 6LoRH Type are compressed addresses + indicating the consecutive hops and are ordered from the first to the + last hop. + + + +Thubert, et al. Standards Track [Page 13] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + All the addresses in a given SRH-6LoRH header MUST be compressed in + an identical fashion, so the Length of the compressed form is the + same for all. + + In order to get different degrees of compression, multiple + consecutive SRH-6LoRH headers MUST be used. + + 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 + with no compression. The complete list of Types of SRH-6LoRH and the + corresponding compression level are provided in Figure 7: + + +-----------+----------------------+ + | 6LoRH | Length of compressed | + | Type | IPv6 address (bytes) | + +-----------+----------------------+ + | 0 | 1 | + | 1 | 2 | + | 2 | 4 | + | 3 | 8 | + | 4 | 16 | + +-----------+----------------------+ + + Figure 7: The SRH-6LoRH Types + + In the case of an SRH-6LoRH header, the TSE field is used as a Size, + which encodes the number of hops minus 1; so a Size of 0 means one + hop, and the maximum that can be encoded is 32 hops. (If more than + 32 hops need to be expressed, a sequence of SRH-6LoRH elements can be + employed.) The result is that the Length, in bytes, of an SRH-6LoRH + header is: + + 2 + Length_of_compressed_IPv6_address * (Size + 1) + +5.2. SRH-6LoRH General Operation + +5.2.1. Uncompressed SRH Operation + + In the uncompressed form, when the root generates or forwards a + packet in Non-Storing mode, it needs to include a Source Routing + Header [RFC6554] to signal a strict source route path to a final + destination down the DODAG. + + All the hops along the path, except the first one, are encoded in + order in the SRH. The last entry in the SRH is the final + destination; the destination in the IPv6 header is the first hop + along the source route path. The intermediate hops perform a swap + + + + +Thubert, et al. Standards Track [Page 14] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + and the Segments Left field indicates the active entry in the Routing + Header [RFC2460]. + + The current destination of the packet, which is the termination of + the current segment, is indicated at all times by the destination + address of the IPv6 header. + +5.2.2. 6LoRH-Compressed SRH Operation + + The handling of the SRH-6LoRH is different: there is no swap, and a + forwarding router that corresponds to the first entry in the first + SRH-6LoRH, upon reception of a packet, effectively consumes that + entry when forwarding. This means that the size of a compressed + source-routed packet decreases as the packet progresses along its + path and that the routing information is lost along the way. This + also means that an SRH encoded with 6LoRH is not recoverable and + cannot be protected. + + When compressed with this specification, all the remaining hops MUST + be encoded in order in one or more consecutive SRH-6LoRH headers. + Whether or not there is an SRH-6LoRH header present, the address of + the final destination is indicated in the LOWPAN_IPHC at all times + along the path. Examples of this are provided in Appendix A. + + The current destination (termination of the current segment) for a + compressed source-routed packet is indicated in the first entry of + the first SRH-6LoRH. In strict source routing, that entry MUST match + an address of the router that receives the packet. + + The last entry in the last SRH-6LoRH is the last router on the way to + the final destination in the LLN. This router can be the final + destination if it is found desirable to carry a whole IP-in-IP + encapsulation all the way. Else, it is the RPL parent of the final + destination, or a router acting at 6LoWPAN Router (6LR) [RFC6775] for + the destination host, and it is advertising the host as an external + route to RPL. + + If the SRH-6LoRH header is contained in an IP-in-IP encapsulation, + the last router removes the whole chain of headers. Otherwise, it + removes the SRH-6LoRH header only. + +5.2.3. Inner LOWPAN_IPHC Compression + + 6LoWPAN ND [RFC6282] is designed to support more than one IPv6 + address per node and per Interface Identifier (IID); an IID is + typically derived from a MAC address to optimize the LOWPAN_IPHC + compression. + + + + +Thubert, et al. Standards Track [Page 15] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Link-local addresses are compressed with stateless address + compression (S/DAC=0). The other addresses are derived from + different prefixes, and they can be compressed with stateful address + compression based on a context (S/DAC=1). + + But, stateless compression is only defined for the specific link- + local prefix as opposed to the prefix in an encapsulating header. + And with stateful compression, the compression reference is found in + a context, as opposed to an encapsulating header. + + The result is that, in the case of an IP-in-IP encapsulation, it is + possible to compress an inner source (respective destination) IP + address in a LOWPAN_IPHC based on the encapsulating IP header only if + stateful (context-based) compression is used. The compression will + operate only if the IID in the source (respective destination) IP + address in the outer and inner headers match, which usually means + that they refer to the same node. This is encoded as S/DAC = 1 and + S/AM=11. It must be noted that the outer destination address that is + used to compress the inner destination address is the last entry in + the last SRH-6LoRH header. + +5.3. The Design Point of Popping Entries + + In order to save energy and to optimize the chances of transmission + success on lossy media, it is a design point for this specification + that the entries in the SRH that have been used are removed from the + packet. This creates a discrepancy from the art of IPv6, where + Routing Headers are mutable but recoverable. + + With this specification, the packet can be expanded at any hop into a + valid IPv6 packet, including an SRH, and compressed back. But the + packet, as decompressed along the way, will not carry all the + consumed addresses that packet would have if it had been forwarded in + the uncompressed form. + + It is noted that: + + The value of keeping the whole RH in an IPv6 header is for the + receiver to reverse it to use the symmetrical path on the way + back. + + It is generally not a good idea to reverse a Routing Header. The + RH may have been used to stay away from the shortest path for some + reason that is only valid on the way in (segment routing). + + There is no use in reversing an RH in the present RPL + specifications. + + + + +Thubert, et al. Standards Track [Page 16] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Point-to-Point (P2P) RPL reverses a path that was learned + reactively as a part of the protocol operation, which is probably + a cleaner way than a reversed echo on the data path. + + Reversing a header is discouraged (by RFC 2460 [RFC2460]) for + Redirected Header Option (RHO) unless it is authenticated, which + requires an Authentication Header (AH). There is no definition of + an AH operation for SRH, and there is no indication that the need + exists in LLNs. + + AH does not protect the RH on the way. AH is a validation at the + receiver with the sole value of enabling the receiver to reverse + it. + + A RPL domain is usually protected by L2 security, which secures + both RPL itself and the RH in the packets at every hop. This is a + better security than that provided by AH. + + In summary, the benefit of saving energy and lowering the chances of + loss by sending smaller frames over the LLN are seen as overwhelming + compared to the value of possibly reversing the header. + +5.4. Compression Reference for SRH-6LoRH Header Entries + + In order to optimize the compression of IP addresses present in the + SRH headers, this specification requires that the 6LoWPAN layer + identifies an address that is used as a reference for the + compression. + + With this specification, the Compression Reference for the first + address found in an SRH header is the source of the IPv6 packet, and + then the reference for each subsequent entry is the address of its + predecessor once it is uncompressed. + + With RPL [RFC6550], an SRH header may only be present in Non-Storing + mode, and it may only be placed in the packet by the root of the + DODAG, which must be the source of the resulting IPv6 packet + [RFC2460]. In this case, the address used as Compression Reference + is the address of the root. + + The Compression Reference MUST be determined as follows: + + The reference address may be obtained by configuration. The + configuration may indicate either the address in full or the + identifier of a 6LoWPAN Context that carries the address + [RFC6775], for instance, one of the 16 Context Identifiers used in + LOWPAN_IPHC [RFC6282]. + + + + +Thubert, et al. Standards Track [Page 17] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Else, if there is no IP-in-IP encapsulation, the source address in + the IPv6 header that is compressed with LOWPAN_IPHC is the + reference for the compression. + + Else, if the IP-in-IP compression specified in this document is + used and the Encapsulator Address is provided, then the + Encapsulator Address is the reference. + + Else, meaning that the IP-in-IP compression specified in this + document is used and the encapsulator is implicitly the root, the + address of the root is the reference. + +5.5. Popping Headers + + Upon reception, the router checks whether the address in the first + entry of the first SRH-6LoRH is one of its own addresses. If that is + the case, the router MUST consume that entry before forwarding, which + is an action of popping from a stack, where the stack is effectively + the sequence of entries in consecutive SRH-6LoRH headers. + + Popping an entry of an SRH-6LoRH header is a recursive action + performed as follows: + + If the Size of the current SRH-6LoRH header is 1 or more + (indicating that there are at least 2 entries in the header), the + router removes the first entry and decrements the Size by 1. + + If the Size of the current SRH-6LoRH header is 0 (indicating that + there is only 1 entry in the header) and there is no subsequent + SRH-6LoRH after this, then the current SRH-6LoRH is removed. + + If the Size of the current SRH-6LoRH header is 0 and there is a + subsequent SRH-6LoRH and the Type of the subsequent SRH-6LoRH is + equal to or greater than the Type of the current SRH-6LoRH header + (indicating the same or lesser compression yielding the same or + larger compressed forms), then the current SRH-6LoRH is removed. + + If the Size of the current SRH-6LoRH header is 0 and there is a + subsequent SRH-6LoRH and the Type of the subsequent SRH-6LoRH is + less the Type of the current SRH-6LoRH header, the first entry of + the subsequent SRH-6LoRH is removed and coalesced with the first + entry of the current SRH-6LoRH. + + At the end of the process, if there are no more SRH-6LoRH in the + packet, then the processing node is the last router along the + source route path. + + An example of this operation is provided in Appendix A.3. + + + +Thubert, et al. Standards Track [Page 18] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +5.6. Forwarding + + When receiving a packet with an SRH-6LoRH, a router determines the + IPv6 address of the current segment endpoint. + + If strict source routing is enforced and this router is not the + segment endpoint for the packet, then this router MUST drop the + packet. + + If this router is the current segment endpoint, then the router pops + its address as described in Section 5.5 and continues processing the + packet. + + If there is still an SRH-6LoRH, then the router determines the new + segment endpoint and routes the packet towards that endpoint. + + Otherwise, the router uses the destination in the inner IP header to + forward or accept the packet. + + The segment endpoint of a packet MUST be determined as follows: + + The router first determines the Compression Reference as discussed + in Section 4.3.1. + + The router then coalesces the Compression Reference with the first + entry of the first SRH-6LoRH header as discussed in Section 5.4. + If the SRH-6LoRH header is Type 4, then the coalescence is a full + override. + + Since the Compression Reference is an uncompressed address, the + coalesced IPv6 address is also expressed in the full 128 bits. + +6. The RPL Packet Information 6LoRH (RPI-6LoRH) + + Section 11.2 of the RPL document [RFC6550] specifies the RPL Packet + Information (RPI) as a set of fields that are placed by RPL routers + in IP packets to identify the RPL Instance, detect anomalies, and + trigger corrective actions. + + In particular, the SenderRank, which is the scalar metric computed by + a specialized Objective Function such as described in RFC 6552 + [RFC6552], indicates the Rank of the sender and is modified at each + hop. The SenderRank field is used to validate that the packet + progresses in the expected direction, either upwards or downwards, + along the DODAG. + + + + + + +Thubert, et al. Standards Track [Page 19] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + RPL defines the "The Routing Protocol for Low-Power and Lossy + Networks (RPL) Option for Carrying RPL Information in Data-Plane + Datagrams" [RFC6553] to transport the RPI, which is carried in an + IPv6 Hop-by-Hop Options Header [RFC2460], typically consuming 8 bytes + per packet. + + With RFC 6553 [RFC6553], the RPL Option is encoded as 6 octets, which + must be placed in a Hop-by-Hop header that consumes two additional + octets for a total of 8 octets. To limit the header's range to just + the RPL domain, the Hop-by-Hop header must be added to (or removed + from) packets that cross the border of the RPL domain. + + The 8-byte overhead is detrimental to LLN operation, particularly + with regard to bandwidth and battery constraints. These bytes may + cause a containing frame to grow above maximum frame size, leading to + Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn leads to + even more energy expenditure and issues discussed in "LLN Fragment + Forwarding and Recovery" [FORWARD-FRAG]. + + An additional overhead comes from the need, in certain cases, to add + an IP-in-IP encapsulation to carry the Hop-by-Hop header. This is + needed when the router that inserts the Hop-by-Hop header is not the + source of the packet so that an error can be returned to the router. + This is also the case when a packet originated by a RPL node must be + stripped from the Hop-by-Hop header to be routed outside the RPL + domain. + + 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 + 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 + inserted the IP-in-IP-6LoRH header, then this situation alone does + not mandate an IP-in-IP-6LoRH header. + + Note: It was found that some implementations omit the RPI for packets + going down the RPL graph in Non-Storing mode, even though RPL + indicates that the RPI should be placed in the packet. With this + specification, the RPI is important to indicate the RPLInstanceID, so + the RPI should not be omitted. + + 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 + the packet are specified by the LOWPAN_IPHC. + + As with RFC 6553 [RFC6553], the fields in the RPI include an 'O', an + 'R', and an 'F' bit, an 8-bit RPLInstanceID (with some internal + structure), and a 16-bit SenderRank. + + + + +Thubert, et al. Standards Track [Page 20] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + The remainder of this section defines the RPI-6LoRH header, which is + a Critical 6LoWPAN Routing Header that is designed to transport the + RPI in 6LoWPAN LLNs. + +6.1. Compressing the RPLInstanceID + + RPL Instances are discussed in Section 5 of the RPL specification + [RFC6550]. A number of simple use cases do not require more than one + RPL Instance, and in such cases, the RPL Instance is expected to be + the Global Instance 0. A global RPLInstanceID is encoded in a + RPLInstanceID field as follows: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |0| ID | Global RPLInstanceID in 0..127 + +-+-+-+-+-+-+-+-+ + + Figure 8: RPLInstanceID Field Format for Global Instances + + For the particular case of the Global Instance 0, the RPLInstanceID + field is all zeros. This specification allows the compressor to + elide a RPLInstanceID field that is all zeros and defines an I flag + that, when set, signals that the field is elided. + +6.2. Compressing the SenderRank + + The SenderRank is the result of the DAGRank operation on the Rank of + the sender; here, the DAGRank operation is defined in Section 3.5.1 + of the RPL specification [RFC6550] as: + + DAGRank(rank) = floor(rank/MinHopRankIncrease) + + If MinHopRankIncrease is set to a multiple of 256, the least + significant eight bits of the SenderRank will be all zeroes; by + eliding those, the SenderRank can be compressed into a single byte. + This idea is used in RFC 6550 [RFC6550], by defining + DEFAULT_MIN_HOP_RANK_INCREASE as 256, and in RFC 6552 [RFC6552], + which defaults MinHopRankIncrease to DEFAULT_MIN_HOP_RANK_INCREASE. + + This specification allows for the SenderRank to be encoded as either + 1 or 2 bytes and defines a K flag that, when set, signals that a + single byte is used. + +6.3. The Overall RPI-6LoRH Encoding + + 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 + expected to be RPL routers that support this specification. + + + +Thubert, et al. Standards Track [Page 21] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + If a non-RPL router receives a packet with a RPI-6LoRH header, there + 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, 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 it + is 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. Here, 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 RPI-6LoRH is Type 5. + + The RPI-6LoRH header is immediately followed by the RPLInstanceID + field, unless that field is fully elided, and then the SenderRank, + which is either compressed into one byte or fully in-lined as 2 + bytes. The I and K flags in the RPI-6LoRH header indicate whether + the RPLInstanceID is elided and/or the SenderRank is compressed. + Depending on these bits, the Length of the RPI-6LoRH may vary as + described hereafter. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ + |1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ + + Figure 9: The Generic RPI-6LoRH Format + + O, R, and F bits: The O, R, and F bits are defined in Section 11.2 + of RFC 6550 [RFC6550]. + + I flag: If it is set, the RPLInstanceID is elided and the + RPLInstanceID is the Global RPLInstanceID 0. If it is not set, + the octet immediately following the Type field contains the + RPLInstanceID as specified in Section 5.1 of RFC 6550 + [RFC6550]. + + K flag: If it is set, the SenderRank is compressed into 1 octet, + with the least significant octet elided. If it is not set, the + SenderRank is fully inlined as 2 octets. + + + +Thubert, et al. Standards Track [Page 22] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and + the MinHopRankIncrease is a multiple of 256, so the least significant + byte is all zeros and can be elided: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + I=1, K=1 + + Figure 10: The Most Compressed RPI-6LoRH + + In Figure 11, the RPLInstanceID is the Global RPLInstanceID 0, but + both bytes of the SenderRank are significant so it cannot be + compressed: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + I=1, K=0 + + Figure 11: Eliding the RPLInstanceID + + In Figure 12, the RPLInstanceID is not the Global RPLInstanceID 0, + and the MinHopRankIncrease is a multiple of 256: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + I=0, K=1 + + Figure 12: Compressing SenderRank + + + + + + + + + + + + + + +Thubert, et al. Standards Track [Page 23] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + In Figure 13, the RPLInstanceID is not the Global RPLInstanceID 0, + and both bytes of the SenderRank are significant: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ...-Rank | + +-+-+-+-+-+-+-+-+ + I=0, K=0 + + Figure 13: The Least Compressed Form of RPI-6LoRH + +7. The IP-in-IP 6LoRH Header + + The IP-in-IP 6LoRH (IP-in-IP-6LoRH) header is an Elective 6LoWPAN + Routing Header that provides a compressed form for the encapsulating + IPv6 Header in the case of an IP-in-IP encapsulation. + + 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. + In order to send an error back regarding the inserted field, the + address of the router that performs the insertion must be provided. + + The encapsulation can also enable the last router prior to the + 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- + 6LoRH encapsulation is not required for that sole purpose. + + The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates it + is Elective. This field is not Critical for routing since it does + not indicate the destination of the packet, which is either encoded + in an 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 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ + + Figure 14: The IP-in-IP-6LoRH + + + + + + + +Thubert, et al. Standards Track [Page 24] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + The Length of an IP-in-IP-6LoRH header is expressed in bytes and MUST + be at least 1, to indicate a Hop Limit (HL) that is decremented at + each hop. When the HL reaches 0, the packet is dropped per RFC 2460 + [RFC2460]. + + If the Length of an IP-in-IP-6LoRH header is exactly 1, then the + Encapsulator Address is elided, which means that the encapsulator is + a well-known router, for instance, the root in a RPL graph. + + The most efficient compression of an IP-in-IP encapsulation that can + be achieved with this specification is obtained when an endpoint of + 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 + known implicitly as opposed to signaled explicitly in the data + packets. + + 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 + Limit field. The value of the Length indicates which compression is + performed on the Encapsulator Address. For instance, a Length of 3 + indicates that the Encapsulator Address is compressed to 2 bytes. + 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 + Section 4.3.2. + + With RPL, the destination address in the IP-in-IP header is + implicitly the root in the RPL graph for packets going upwards; in + Storing mode, it is the destination address in the LOWPAN_IPHC for + packets going downwards. In Non-Storing mode, there is no implicit + value for packets going downwards. + + If the implicit value is correct, the destination IP address of the + IP-in-IP encapsulation can be elided. Else, the destination IP + address of the IP-in-IP header is transported in an SRH-6LoRH header + as the first entry of the first of these headers. + + If the final destination of the packet is a leaf that does not + support this specification, then the chain of 6LoRH headers must be + 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 + cannot be elided. + + In the special case where a 6LoRH header is used to route 6LoWPAN + fragments, the destination address is not accessible in the + LOWPAN_IPHC on all fragments and can be elided only for the first + fragment and for packets going upwards. + + + + + +Thubert, et al. Standards Track [Page 25] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +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 nodes at all, use the + compression technique detailed therein. + + This specification aims at a simple implementation running in + constrained nodes, so it does indeed expect a homogeneous network + and, as a consequence, it does not provide a method to determine the + level of support by the next hops at forwarding time. + + Should an extension to this specification provide such a method, + forwarding nodes could compress or decompress the RPL artifacts + appropriately and enable a backward compatibility between nodes that + support this specification and nodes that do not. + + It results that this specification does not attempt to enable such + backwards compatibility. It does not require extraneous code to + exchange and handle error messages to automatically correct mismatch + situations either. + + When a packet is expected to carry a 6LoRH header but does not, the + node that discovers the issue is expected to send an ICMPv6 error + message to the root. It should be sent at an adapted rate-limitation + and with a type 4 (indicating a "Parameter Problem") and a code 0 + (indicating an "Unrecognized Next Header field encountered"). The + relevant portion of the received packet should be embedded and the + offset therein where the 6LoRH header was expected should be pointed + out. + + When a packet is received with a 6LoRH header that is not recognized, + the node that discovers the issue is expected to send an ICMPv6 error + message to the root. It should be sent at an adapted rate-limitation + and with a type 4 (indicating a "Parameter Problem") and a code 1 + (indicating an "Unrecognized Next Header type encountered"). The + relevant portion of the received packet should be embedded and the + offset therein where the 6LoRH header was expected should be pointed + out. + + In both cases, the node SHOULD NOT place a 6LoRH header as defined in + this specification in the resulting message, and the node should + either omit the RPI or place it uncompressed after the IPv6 header. + + Additionally, in both cases, an alternate management method may be + preferred in order to notify the network administrator that there is + a configuration error. + + + +Thubert, et al. Standards Track [Page 26] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Keeping the network homogeneous 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 misconfigured. + + 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 RFC 4944 [RFC4944], RFC 6282 + [RFC6282], and RFC 6553 [RFC6553] apply. + + Using a compressed format as opposed to the full in-line format is + logically equivalent and is believed not to create an opening for a + new threat when compared to RFC 6550 [RFC6550], RFC 6553 [RFC6553], + and RFC 6554 [RFC6554], noting that, even though intermediate hops + are removed from the SRH header as they are consumed, a node may + still identify that the rest of the source-routed path includes a + loop or not (see the "Security" section of RFC 6554). 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 + +10.1. Reserving Space in 6LoWPAN Dispatch Page 1 + + This specification reserves Dispatch Value Bit Patterns within the + 6LoWPAN Dispatch Page 1 as follows: + + 10 1xxxxx: for Elective 6LoWPAN Routing Headers + + 10 0xxxxx: for Critical 6LoWPAN Routing Headers + + 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 256 possible values, from 0 to 255, as + described below. + + Future assignments are made by IANA using the "RFC Required" + procedure [RFC5226]. + + + +Thubert, et al. Standards Track [Page 27] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +10.2. New Critical 6LoWPAN Routing Header Type Registry + + This document creates an IANA registry titled "Critical 6LoWPAN + Routing Header Type" and assigns the following values: + + 0-4: SRH-6LoRH [RFC8138] + + 5: RPI-6LoRH [RFC8138] + +10.3. New Elective 6LoWPAN Routing Header Type Registry + + This document creates an IANA registry titled "Elective 6LoWPAN + Routing Header Type" and assigns the following value: + + 6: IP-in-IP-6LoRH [RFC8138] + +11. References + +11.1. Normative References + + [IEEE.802.15.4] + IEEE, "IEEE Standard for Low-Rate Wireless Networks", + IEEE 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, + <http://ieeexplore.ieee.org/document/7460875/>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, <http://www.rfc-editor.org/info/rfc2460>. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", RFC 4443, + DOI 10.17487/RFC4443, March 2006, + <http://www.rfc-editor.org/info/rfc4443>. + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, + <http://www.rfc-editor.org/info/rfc4944>. + + + + + + + +Thubert, et al. Standards Track [Page 28] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + [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 + Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, + DOI 10.17487/RFC6282, September 2011, + <http://www.rfc-editor.org/info/rfc6282>. + + [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., + Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, + JP., and R. Alexander, "RPL: IPv6 Routing Protocol for + Low-Power and Lossy Networks", RFC 6550, + DOI 10.17487/RFC6550, March 2012, + <http://www.rfc-editor.org/info/rfc6550>. + + [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing + Protocol for Low-Power and Lossy Networks (RPL)", + RFC 6552, DOI 10.17487/RFC6552, March 2012, + <http://www.rfc-editor.org/info/rfc6552>. + + [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- + Power and Lossy Networks (RPL) Option for Carrying RPL + Information in Data-Plane Datagrams", RFC 6553, + DOI 10.17487/RFC6553, March 2012, + <http://www.rfc-editor.org/info/rfc6553>. + + [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 + Routing Header for Source Routes with the Routing Protocol + for Low-Power and Lossy Networks (RPL)", RFC 6554, + DOI 10.17487/RFC6554, March 2012, + <http://www.rfc-editor.org/info/rfc6554>. + + [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power + Wireless Personal Area Network (6LoWPAN) Paging Dispatch", + RFC 8025, DOI 10.17487/RFC8025, November 2016, + <http://www.rfc-editor.org/info/rfc8025>. + +11.2. Informative References + + [FORWARD-FRAG] + Thubert, P., Ed. and J. Hui, "LLN Fragment Forwarding and + Recovery", Work in Progress, draft-thubert-6lo-forwarding- + fragments-05, April 2017. + + + + + + +Thubert, et al. Standards Track [Page 29] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + [IPv6-ARCH] + Thubert, P., Ed., "An Architecture for IPv6 over the TSCH + mode of IEEE 802.15.4", Work in Progress, + draft-ietf-6tisch-architecture-11, January 2017. + + [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. + Bormann, "Neighbor Discovery Optimization for IPv6 over + Low-Power Wireless Personal Area Networks (6LoWPANs)", + RFC 6775, DOI 10.17487/RFC6775, November 2012, + <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 + IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the + Internet of Things (IoT): Problem Statement", RFC 7554, + DOI 10.17487/RFC7554, May 2015, + <http://www.rfc-editor.org/info/rfc7554>. + + [RPL-INFO] Robles, M., Richardson, M., and P. Thubert, "When to use + RFC 6553, 6554 and IPv6-in-IPv6", Work in Progress, + draft-ietf-roll-useofrplinfo-14, April 2017. + + + + + + + + + + + + + + + + + + + + + + +Thubert, et al. Standards Track [Page 30] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +Appendix A. Examples + +A.1. Examples Compressing the RPI + + The example in Figure 15 illustrates the 6LoRH compression of a + classical packet in Storing mode in all directions, as well as in + Non-Storing mode for a packet going up the DODAG following the + default route to the root. In this particular example, a + fragmentation process takes place per RFC 4944 [RFC4944], and the + fragment headers must be placed in Page 0 before switching to Page 1: + + +- ... -+- ... -+-+ ... -+- ... +-+-+ ... -+-+-+-+-+-+-+-+-+-+... + |Frag type|Frag hdr |11110001| RPI- |IP-in-IP| LOWPAN_IPHC | ... + |RFC 4944 |RFC 4944 | Page 1 | 6LoRH | 6LoRH | | + +- ... -+- ... -+-+ ... -+- ... +-+-+ ... -+-+-+-+-+-+-+-+-+-+... + <- RFC 6282 -> + No RPL artifact + + +- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... + |Frag type|Frag hdr | + |RFC 4944 |RFC 4944 | Payload (cont) + +- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... + + +- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... + |Frag type|Frag hdr | + |RFC 4944 |RFC 4944 | Payload (cont) + +- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... + + Figure 15: Example Compressed Packet with RPI + + In Storing mode, if the packet stays within the RPL domain, then it + is possible to save the IP-in-IP encapsulation, in which case, only + the RPI is compressed with a 6LoRH, as illustrated in Figure 16 in + the case of a non-fragmented ICMP packet: + + +- ... -+-+- ... -+-+-+-+ ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... + |11110001| RPI-6LoRH | NH = 0 | NH = 58 | ICMP message ... + |Page 1 | Type 5 | 6LOWPAN_IPHC | (ICMP) | (no compression) + +- ... -+-+- ... -+-+-+-+ ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... + <- RFC 6282 -> + No RPL artifact + + Figure 16: Example ICMP Packet with RPI in Storing Mode + + + + + + + + +Thubert, et al. Standards Track [Page 31] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + The format in Figure 16 is logically equivalent to the uncompressed + format illustrated in Figure 17: + + +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + | IPv6 Header | Hop-by-Hop | RPI in | ICMP message ... + | NH = 58 | Header | RPL Option | + +-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + + Figure 17: Uncompressed ICMP Packet with RPI + + For a UDP packet, the transport header can be compressed with 6LoWPAN + HC [RFC6282] as illustrated in Figure 18: + + +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+... + |11110001| RPI- | NH=1 |11110CPP| Compressed | UDP + |Page 1 | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payload + +-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+... + <- RFC 6282 -> + No RPL artifact + + Figure 18: Uncompressed ICMP Packet with RPI + + If the packet is received from the Internet in Storing mode, then the + root is supposed to encapsulate the packet to insert the RPI. The + resulting format would be as represented in Figure 19: + + +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... + |11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP + |Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld + +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... + <- RFC 6282 -> + No RPL artifact + + Figure 19: RPI Inserted by the Root in Storing Mode + +A.2. Example of a Downward Packet in Non-Storing Mode + + The example illustrated in Figure 20 is a classical packet in Non- + Storing mode for a packet going down the DODAG following a source- + routed path from the root. Say that we have four forwarding hops to + reach a destination. In the uncompressed form, when the root + generates the packet, the last 3 hops are encoded in a Routing Header + Type 3 (SRH) and the first hop is the destination of the packet. The + intermediate hops perform a swap; the hop count indicates the current + active hop as defined in RFC 2460 [RFC2460] and RFC 6554 [RFC6554]. + + + + + + +Thubert, et al. Standards Track [Page 32] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + When compressed with this specification, the 4 hops are encoded in + SRH-6LoRH when the root generates the packet, and the final + destination is left in the LOWPAN_IPHC. There is no swap; the + forwarding node that corresponds to the first entry effectively + consumes it when forwarding, which means that the size of the encoded + packet decreases and that the hop information is lost. + + If the last hop in an SRH-6LoRH is not the final destination, then it + removes the SRH-6LoRH before forwarding. + + In the particular example illustrated in Figure 20, all addresses in + the DODAG are assigned from the same /112 prefix and the last 2 + octets encoding an identifier such as an IEEE 802.15.4 short address. + In that case, all addresses can be compressed to 2 octets, using the + root address as reference. There will be one SRH_6LoRH header with, + in this example, three compressed addresses: + + +-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... + |11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP + |Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld + +-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-... + <-8bytes-> <- RFC 6282 -> + No RPL artifact + + Figure 20: Example Compressed Packet with SRH + + One may note that the RPI is provided. This is because the address + of the root that is the source of the IP-in-IP header is elided and + inferred from the RPLInstanceID in the RPI. Once found from a local + context, that address is used as a Compression Reference to expand + addresses in the SRH-6LoRH. + + With the RPL specifications available at the time of writing, the + root is the only node that may incorporate an SRH in an IP packet. + When the root forwards a packet that it did not generate, it has to + encapsulate the packet with IP-in-IP. + + But, if the root generates the packet towards a node in its DODAG, + then it should avoid the extra IP-in-IP as illustrated in Figure 21: + + +- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+... + |11110001| SRH-6LoRH | NH=1 | 11110CPP | Compressed | UDP + |Page 1 | Type1 S=3 | LOWPAN_IPHC| LOWPAN-NHC| UDP header | Payload + +- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+... + <- RFC 6282 -> + + Figure 21: Compressed SRH 4*2bytes Entries Sourced by Root + + + + +Thubert, et al. Standards Track [Page 33] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Note: The RPI is not represented, though RPL [RFC6550] generally + expects it. In this particular case, since the Compression Reference + for the SRH-6LoRH is the source address in the LOWPAN_IPHC, and the + routing is strict along the source route path, the RPI does not + appear to be absolutely necessary. + + In Figure 21, all the nodes along the source route path share the + same /112 prefix. This is typical of IPv6 addresses derived from an + IEEE802.15.4 short address, as long as all the nodes share the same + PAN-ID. In that case, a Type 1 SRH-6LoRH header can be used for + encoding. The IPv6 address of the root is taken as reference, and + only the last 2 octets of the address of the intermediate hops are + encoded. The Size of 3 indicates 4 hops, resulting in an SRH-6LoRH + of 10 bytes. + +A.3. Example of SRH-6LoRH Life Cycle + + This section illustrates the operation specified in Section 5.6 of + forwarding a packet with a compressed SRH along an A->B->C->D source + route path. The operation of popping addresses is exemplified at + each hop. + + Packet as received by node A + ---------------------------- + Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA AAAA + Type 1 SRH-6LoRH Size = 0 BBBB + Type 2 SRH-6LoRH Size = 1 CCCC CCCC + DDDD DDDD + + Step 1: Popping BBBB, the first entry of the next SRH-6LoRH + Step 2: If larger value (2 vs. 1), the SRH-6LoRH is removed + + Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA AAAA + Type 2 SRH-6LoRH Size = 1 CCCC CCCC + DDDD DDDD + + Step 3: Recursion ended; coalescing BBBB with the first entry + Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB + + Step 4: Routing based on next segment endpoint to B + + Figure 22: Processing at Node A + + + + + + + + + +Thubert, et al. Standards Track [Page 34] + +RFC 8138 6LoWPAN Routing Header April 2017 + + + Packet as received by node B + ---------------------------- + Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB + Type 2 SRH-6LoRH Size = 1 CCCC CCCC + DDDD DDDD + + Step 1: Popping CCCC CCCC, the first entry of the next SRH-6LoRH + Step 2: Removing the first entry and decrementing the Size (by 1) + + Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB + Type 2 SRH-6LoRH Size = 0 DDDD DDDD + + Step 3: Recursion ended; coalescing CCCC CCCC with the first entry + Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC + + Step 4: Routing based on next segment endpoint to C + + Figure 23: Processing at Node B + + + Packet as received by node C + ---------------------------- + + Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC + Type 2 SRH-6LoRH Size = 0 DDDD DDDD + + Step 1: Popping DDDD DDDD, the first entry of the next SRH-6LoRH + Step 2: The SRH-6LoRH is removed + + Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC + + Step 3: Recursion ended; coalescing DDDD DDDDD with the first entry + Type 3 SRH-6LoRH Size = 0 AAAA AAAA DDDD DDDD + + Step 4: Routing based on next segment endpoint to D + + Figure 24: Processing at Node C + + Packet as received by node D + ---------------------------- + Type 3 SRH-6LoRH Size = 0 AAAA AAAA DDDD DDDD + + Step 1: The SRH-6LoRH is removed + Step 2: No more header; routing based on inner IP header + + Figure 25: Processing at Node D + + + + + +Thubert, et al. Standards Track [Page 35] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +Acknowledgements + + The authors wish to thank Tom Phinney, Thomas Watteyne, Tengfei + Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan + Hui, Gabriel Montenegro, and Ralph Droms for constructive reviews to + the design in the 6lo working group. The overall discussion involved + participants to the 6MAN, 6TiSCH, and ROLL WGs; thank you all. + Special thanks to Michael Richardson and Ines Robles (the Chairs of + the ROLL WG), Brian Haberman (the Internet Area AD), and Alvaro + Retana and Adrian Farrel (Routing Area ADs) for driving this complex + effort across working groups and areas. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thubert, et al. Standards Track [Page 36] + +RFC 8138 6LoWPAN Routing Header April 2017 + + +Authors' Addresses + + Pascal Thubert (editor) + Cisco Systems + Building D - Regus + 45 Allee des Ormes + BP1200 + MOUGINS - Sophia Antipolis 06254 + France + + Phone: +33 4 97 23 26 34 + Email: pthubert@cisco.com + + + Carsten Bormann + Universitaet Bremen TZI + Postfach 330440 + Bremen D-28359 + Germany + + Phone: +49-421-218-63921 + Email: cabo@tzi.org + + Laurent Toutain + IMT Atlantique + 2 rue de la Chataigneraie + CS 17607 + Cesson-Sevigne Cedex 35576 + France + + Email: Laurent.Toutain@IMT-Atlantique.fr + + + Robert Cragie + ARM Ltd. + 110 Fulbourn Road + Cambridge CB1 9NJ + United Kingdom + + Email: robert.cragie@arm.com + + + + + + + + + + + +Thubert, et al. Standards Track [Page 37] + |