--- 1/draft-ietf-roll-routing-dispatch-00.txt 2016-09-16 10:15:59.028518186 -0700 +++ 2/draft-ietf-roll-routing-dispatch-01.txt 2016-09-16 10:15:59.100519996 -0700 @@ -1,23 +1,23 @@ roll P. Thubert, Ed. Internet-Draft Cisco Intended status: Standards Track C. Bormann -Expires: September 22, 2016 Uni Bremen TZI +Expires: March 20, 2017 Uni Bremen TZI L. Toutain IMT-TELECOM Bretagne R. Cragie ARM - March 21, 2016 + September 16, 2016 6LoWPAN Routing Header - draft-ietf-roll-routing-dispatch-00 + draft-ietf-roll-routing-dispatch-01 Abstract This specification introduces a new 6LoWPAN dispatch type for use in 6LoWPAN Route-Over topologies, that initially covers the needs of RPL (RFC6550) data packets compression. Using this dispatch type, this specification defines a method to compress RPL Option (RFC6553) information and Routing Header type 3 (RFC6554), an efficient IP-in- IP technique and is extensible for more applications. @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 22, 2016. + This Internet-Draft will expire on March 20, 2017. Copyright Notice Copyright (c) 2016 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 @@ -52,21 +52,21 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Using the Page Dispatch . . . . . . . . . . . . . . . . . . . 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.2. Relative To Other 6LoRH Headers . . . . . . . . . . . 7 4. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 8 4.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 8 4.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 9 4.3. Compressing Addresses . . . . . . . . . . . . . . . . . . 9 4.3.1. Coalescence . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. DODAG Root Address Determination . . . . . . . . . . 10 5. The SRH 6LoRH Header . . . . . . . . . . . . . . . . . . . . 11 5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 @@ -74,35 +74,36 @@ 5.2.1. Uncompressed SRH Operation . . . . . . . . . . . . . 13 5.2.2. 6LoRH-Compressed SRH Operation . . . . . . . . . . . 13 5.2.3. Inner LOWPAN_IPHC Compression . . . . . . . . . . . . 14 5.3. The Design Point of Popping Entries . . . . . . . . . . . 14 5.4. Compression Reference for SRH-6LoRH header entries . . . 15 5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 16 5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17 6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 17 6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 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 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 9.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 23 - 9.2. New 6LoWPAN Routing Header Type Registry . . . . . . . . 24 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 - 11.2. Informative References . . . . . . . . . . . . . . . . . 25 - Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26 - A.1. Examples Compressing The RPI . . . . . . . . . . . . . . 26 - A.2. Example Of Downward Packet In Non-Storing Mode . . . . . 28 - A.3. Example of SRH-6LoRH life-cycle . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + 8. Management Considerations . . . . . . . . . . . . . . . . . . 23 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 25 + 10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 25 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 12.2. Informative References . . . . . . . . . . . . . . . . . 27 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28 + A.1. Examples Compressing The RPI . . . . . . . . . . . . . . 28 + A.2. Example Of Downward Packet In Non-Storing Mode . . . . . 30 + A.3. Example of SRH-6LoRH life-cycle . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 is scavenged from the environment in very limited quantities. Any protocol that is intended for use in LLNs must be @@ -125,25 +126,25 @@ identification, source routing information, etc. 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 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 a mesh root, as opposed to the source node. This is also the case when some routing information must be removed from a packet that flows outside the LLN. - When to use RFC 6553, 6554 and IPv6-in-IPv6 - [I-D.robles-roll-useofrplinfo] details different cases where RFC - 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the - bases to help defining the compression of RPL routing information in - LLN environments. + When to use RFC 6553, RFC 6554 and IPv6-in-IPv6 + [I-D.ietf-roll-useofrplinfo] details different cases where RFC 6553, + RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the bases + to help defining the compression of RPL routing information in LLN + environments. 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 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 | @@ -265,25 +266,30 @@ 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. 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 Paging Dispatch is parsed and no subsequent Paging Dispatch has been parsed, the parsing of the packet MUST follow this specification if the 6LoRH Bit Pattern Section 3.1 is found. With this specification, the 6LoRH Dispatch is only defined in Page context is active. Because a 6LoRH header requires a Page 1 context, it MUST always be @@ -341,81 +347,76 @@ 4. 6LoWPAN Routing Header General Format The 6LoRH usesthe Dispatch Value Bit Pattern of 10xxxxxx in Page 1. The Dispatch Value Bit Pattern is split in two forms of 6LoRH: Elective (6LoRHE) that may skipped if not understood 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 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 + 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 + Type: Type of the 6LoRHE 4.2. Critical Format The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx. A node which does not support the 6LoRHC Type MUST silently discard the packet. - Note: The situation where a node receives a message with a Critical - 6LoWPAN Routing Header that it does not understand is a critical - administrative error whereby the wrong device is placed in a network. - 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. + Note: the 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. - TSE: - Type Specific Extension. The meaning depends on the Type, + TSE: Type Specific Extension. 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 + Type: Type of the 6LoRHC 4.3. Compressing Addresses 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 address, and then elide that matching piece. In order to reconstruct the compress address, the receiving node will perform the process of coalescence described in section Section 4.3.1. One possible reference is the root of the RPL DODAG that is being @@ -500,43 +501,49 @@ 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 nodes participates to for that particular RPL Instance. 5. The SRH 6LoRH Header 5.1. Encoding - The Source Routing Header 6LoRH (SRH-6LoRH) header is a Critical - 6LoWPAN Routing Header that provides a compressed form for the SRH, - as defined in [RFC6554] for use by RPL routers. Routers that need to - 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 - 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 - ignored. + A Source Routing Header 6LoRH (SRH-6LoRH) header provides a + compressed form for the SRH, as defined in [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 a 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 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ - Size indicates the number of compressed addresses + Where N = Size + 1 Figure 6: The SRH-6LoRH. - The 6LoRH Type indicates the compression level used in a given SRH- - 6LoRH header. - - One or more 6LoRH header(s) MAY be placed in a 6LoWPAN packet. + The 6LoRH Type of a SRH-6LoRH header indicates the compression level + used for that header. It results that all addresses in a given SRH-6LoRH header MUST be compressed in an identical fashion, down to using the identical number of bytes per address. 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: @@ -754,21 +762,21 @@ 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 route path. 5.6. Forwarding When receiving a packet with a SRH-6LoRH, a router determines the 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 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 a SRH-6LoRH, then the router determines the new segment endpoint and routes the packet towards that endpoint. @@ -831,23 +839,25 @@ 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: 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 - is usually (and quite illegally) omitted, unless it is important to - indicate the RPLInstanceID. To match this structure, an optimized - IP-in-IP 6LoRH header is defined in Section 7. + is usually (and quite illegally) omitted. With this specification, + the RPI is important to indicate the RPLInstanceID so the RPI should + 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 IP-in-IP-6LoRH header. In that case, the source and destination of the packet are specified by the LOWPAN_IPHC. 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), and a 16-bit SenderRank. The remainder of this section defines the RPI-6LoRH header, which is @@ -890,29 +900,39 @@ DEFAULT_MIN_HOP_RANK_INCREASE. 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 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. If a - 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. + expected to be RPL routers that support this specification. - Since the I flag is not set, 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. + 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 + 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 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 two 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. @@ -921,26 +941,26 @@ 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 [RFC6550], 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, the octet immediately following the type field contains the 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 SenderRank, is fully inlined as two octets. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -998,22 +1018,26 @@ 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 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. - This field is not critical for routing so the Type can be ignored, - and the TSE field contains the Length in bytes. + The Dispatch Value Bit Pattern for the SRH-6LoRH header indicates + 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 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. The Length of an IP-in-IP-6LoRH header is expressed in bytes and MUST @@ -1028,21 +1052,21 @@ 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 Size of 3 + 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, and, in storing mode, it is the destination address in the IPHC for packets going downwards. In non-storing mode, there is no implicit value for packets going downwards. @@ -1056,68 +1080,125 @@ 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 IPHC on all fragments and can be elided only for the first fragment and for 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] apply. 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 - new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. - -9. IANA Considerations + new threat when compared to [RFC6550], [RFC6553] and [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 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 6LoWPAN Dispatch Page 1 as follows: 101xxxxx: for Elective 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 - Type, and assigns the following values: + Future assignments in these registries are to be coordinated via IANA + 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] 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] -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 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 the chairs of the ROLL WG, Michael Richardson and - Ines Robles, and Brian Haberman, Internet Area A-D, and Adrian - Farrel, Routing Area A-D, for driving this complex effort across - Working Groups and Areas. + Ines Robles, Brian Haberman, Internet Area A-D, and Alvaro Retana and + Adrian Farrel, Routing Area A-Ds, for driving this complex effort + across Working Groups and Areas. -11. References +12. References -11.1. Normative References +12.1. Normative References [I-D.ietf-6lo-paging-dispatch] - Thubert, P., "6LoWPAN Paging Dispatch", draft-ietf-6lo- - paging-dispatch-01 (work in progress), January 2016. + Thubert, P. and R. Cragie, "6LoWPAN Paging Dispatch", + draft-ietf-6lo-paging-dispatch-04 (work in progress), + September 2016. [IEEE802154] IEEE standard for Information Technology, "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks", 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, @@ -1125,20 +1206,25 @@ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [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, . + [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, + . + [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, . [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, @@ -1154,52 +1240,52 @@ Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, . [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, . - [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and - Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January - 2014, . - - [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for - Constrained-Node Networks", RFC 7228, - DOI 10.17487/RFC7228, May 2014, - . - -11.2. Informative References +12.2. Informative References [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work - in progress), November 2015. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work + in progress), June 2016. - [I-D.robles-roll-useofrplinfo] + [I-D.ietf-roll-useofrplinfo] Robles, I., Richardson, M., and P. Thubert, "When to use - RFC 6553, 6554 and IPv6-in-IPv6", draft-robles-roll- - useofrplinfo-02 (work in progress), October 2015. + RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- + useofrplinfo-08 (work in progress), September 2016. [I-D.thubert-6lo-forwarding-fragments] Thubert, P. and J. Hui, "LLN Fragment Forwarding and Recovery", draft-thubert-6lo-forwarding-fragments-02 (work in progress), November 2014. [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, . + [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and + Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January + 2014, . + + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, + . + [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, . Appendix A. Examples A.1. Examples Compressing The RPI