--- 1/draft-ietf-roll-routing-dispatch-02.txt 2016-10-25 02:15:57.798253992 -0700 +++ 2/draft-ietf-roll-routing-dispatch-03.txt 2016-10-25 02:15:57.870255728 -0700 @@ -1,23 +1,23 @@ roll P. Thubert, Ed. Internet-Draft Cisco Intended status: Standards Track C. Bormann -Expires: April 22, 2017 Uni Bremen TZI +Expires: April 28, 2017 Uni Bremen TZI L. Toutain IMT-TELECOM Bretagne R. Cragie ARM - October 19, 2016 + October 25, 2016 6LoWPAN Routing Header - draft-ietf-roll-routing-dispatch-02 + draft-ietf-roll-routing-dispatch-03 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 April 22, 2017. + This Internet-Draft will expire on April 28, 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 @@ -78,33 +78,33 @@ 5.4. Compression Reference for SRH-6LoRH header entries . . . 16 5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 17 5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17 6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 18 6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 19 6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 20 6.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 20 7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 23 8. Management Considerations . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 25 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 26 10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 26 10.3. New Elective 6LoWPAN Routing Header Type Registry . . . 26 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 28 - 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 . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29 + A.1. Examples Compressing The RPI . . . . . . . . . . . . . . 29 + A.2. Example Of Downward Packet In Non-Storing Mode . . . . . 31 + A.3. Example of SRH-6LoRH life-cycle . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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 @@ -119,24 +119,25 @@ bytes per frame. The need to compress IPv6 packets over IEEE 802.15.4 led to the "6LoWPAN Header Compression" [RFC6282] work (6LoWPAN_HC). Innovative Route-over techniques have been and are still being developed for routing inside a LLN. In a general fashion, 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 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. + For reasons such as security and the capability to send ICMPv6 errors + (see "Internet Control Message Protocol (ICMPv6)" [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 "IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] (RPL). 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, RFC 6554 and IPv6-in-IPv6" @@ -554,22 +555,22 @@ Figure 6: The SRH-6LoRH. The 6LoRH Type of a 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. All the addresses in a given SRH-6LoRH header MUST be compressed in - an identical fashion, so the Length of the compressed for is the same - for all. + 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: +-----------+----------------------+ @@ -1114,34 +1115,63 @@ fragment and for packets going upwards. 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. + This specification aims at a simple implementation running in + constrained nodes, so it does indeed expect an 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. - 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. + Should an extension to this specification provide such a method, + forwarding nodes could compress or uncompress 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 correct automatically mismatch + situations, either. + + When a packet is expected to carry a 6LoRH header but it does not, + the node that discovers the issue is expected to send an ICMPv6 error + message to the root, at an adapted rate limitation and with a Type 4 + indicating a "Parameter Problem", and a Code 0 indicating an + "erroneous header field encountered", embedding the relevant portion + of the received packet and pointing at the offset therein where the + 6LoRH header was expected. + + 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, at an adapted rate limitation and with a Type 4 + indicating a "Parameter Problem", and a Code 1 indicating an + "unrecognized Next Header type", embedding the relevant portion of + the received packet and pointing at the offset therein where the + 6LoRH header was expected. + + In both cases, the node SHOULD NOT place a 6LoRH header defined in + this specification in the resulting message, and should either omit + the RPI or place it uncompressed after the IPv6 header. + + In both cases also, an alternate management method may be preferred + in order to notify the network administrator that there is a + configuration error. + + 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 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. @@ -1223,20 +1253,26 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . + [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, + . + [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, . @@ -1272,21 +1308,21 @@ 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-10 (work in progress), June 2016. [I-D.ietf-roll-useofrplinfo] Robles, I., Richardson, M., and P. Thubert, "When to use RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- - useofrplinfo-08 (work in progress), September 2016. + useofrplinfo-09 (work in progress), October 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, @@ -1408,24 +1444,24 @@ If the last hop in a 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 a same /112 prefix and the last 2 octets encoding an identifier such as a 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, 3 compressed addresses: -+-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-... -|11110001 |SRH-6LoRH | RPI-6LoRH | IP-in-IP | NH=1 |11110CPP| UDP | UDP -|Page 1 |Type1 S=2 | | 6LoRH |LOWPAN_IPHC | UDP | hdr |load -+-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-... + +-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... + |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 Compression Reference to expand addresses in the SRH-6LoRH.