idnits 2.17.1 draft-toutain-6lo-local-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2460]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Toutain 3 Internet-Draft Institut MINES TELECOM ; TELECOM Bretagne 4 Intended status: Informational June 27, 2014 5 Expires: December 29, 2014 7 6LoWPAN Local Extensions 8 draft-toutain-6lo-local-extensions-00.txt 10 Abstract 12 [RFC2460] defines an extension mechanism to add functionalities to 13 the basic IPv6 header. On LoWPAN networks, some extensions are 14 required to extend routing capabilities. These specific extensions 15 should not leak in the global internet. To optimize encapsulation, a 16 6LoWPAN dispatch to carry local extensions is defined. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 29, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. IPv6 extensions 52 [RFC2460] defines an extension mechanism to add functionalities to 53 the basic IPv6 header. Extensions are processed differently 54 regarding their nature: for Hop by Hop each router will process it 55 and for the others, routers will ignore them, only the sender and the 56 receiver will take them into account. More precisely, the [RFC2460] 57 specifies: 59 With one exception, extension headers are not examined or 60 processed by any node along a packet's delivery path, until the 61 packet reaches the node (or each of the set of nodes, in the case 62 of multicast) identified in the Destination Address field of the 63 IPv6 header. 65 In other words, only the source can create an extension and routers 66 are not allowed to remove it. 68 On LoWPAN networks, some extensions are required to extend routing 69 capabilities. For instance, RPL defines a Hop by Hop extension 70 [RFC6553] to specify a forwarding plan (RPLInstanceID) or detect 71 wrong direction packets. A routing header is also defined for non 72 storing mode [RFC6554] to specify the path to reach a leaf. 74 These specific extensions should not leak in the global internet, 75 especially for an Hop-by-Hop extension which will decrease the 76 forwarding performances. A border router cannot add routing 77 extension to incoming packets. To solve this problem tunneling is 78 required. 80 [RFC6554] defines in figure following encapsulation: 82 +--------+---------+--------+-------------//-+ 83 | Outer | Source | Inner | IPv6 | 84 | IPv6 | Routing | IPv6 | Payload | 85 | Header | Header | Header | | 86 +--------+---------+--------+-------------//-+ 87 <--- Original Packet ---> 88 <--- Tunneled Packet ---> 90 Figure 1: Packet tunneling 92 Outer header carries LoWPAN IP addresses of a LOWPAN node and a 93 border router and Inner header contains the source and destination. 94 This encapsulation is sub-optimal since two IP headers are needed and 95 the inner one cannot be compressed since Next Header in the Source 96 Routing header contains the IPv6 protocol as defined in [rfc2460]; no 97 reference to a 6LoWPAN dispatch is possible. 99 2. Local Extension Dispatch 101 To overcome this situation where the scope of an extension is local 102 to a specific area, a 6LoWPAN dispatch to carry extensions. It will 103 improve performances. This extension can be easily added or removed 104 by the border router. The work is done at the 6LoWPAN layer, so 105 there is violation of [RFC2460] extension processing rules. 107 A 8 bit dispatch called LOWPAN_LE (code TBD) is defined to carry 108 extensions inside a LoWPAN. This dispatch can be repeated several 109 times. They are located just before LOWPAN_IPHC. A single Extension 110 header follows each LOWPAN_LE dispatch. The syntax remains the same, 111 with one exception: Current Header field replaces the Next Header 112 field. Instead of giving the next protocol identifier, it will 113 describe the protocol in the structure. The length contained in the 114 extension is used to find the extension end, which is followed by 115 another dispatch either LOWPAN_LE or LOWPAN_IPHC. 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 |Current Header | Hdr Ext Len | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | | 123 . . 124 . Payload . 125 . . 126 | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 2: Extension header 131 3. Compressing/Decompressing 6LoWPAN Header 133 The conversion between the 6LoWPAN header format and the IPv6 header 134 format is quite simple. The main difficulties is to manage global 135 extensions already present in a packet, or to make the distinction 136 between global extension which must be carried end to end and those 137 local to the LoWPAN. A simple approach is to consider the scope 138 imposed by tunneling, as described in Figure 1. 140 If a packet carrying arrives from the global Internet to a 6LBR, 141 these extensions are viewed has payload by the 6LoWPAN compression 142 mechanism and do not use the LOWPAN_LE dispatch. 144 Note that this scheme remains compatible with tunneling described in 145 [RFC6554]. An outer IPHC header can be added before first LOWPAN_LE 146 DISPATCH, for instance to limit the scope of ICMP messages. 148 4. Examples 150 A border router receives traffic from outside the LoWPAN network and 151 forwards the traffic to a 6LN. The 6LBR add a Hob-by-hop and Routing 152 extensions 154 +---+ +---+ +---+ 155 | S |-------------------|LBR|--------------------|6LN| 156 +---+ IPv6 Header +---+ LOWPAN_LE +---+ 157 Destination H. [CH=0 Length Value] 158 Data LOWPAN_LE 159 [CH=41, Length, Value] 160 LOWPAN_IPHC 161 [header values] 162 Destination H. 163 Data 165 Figure 3: Adding Local extensions 167 A border router forwards traffic coming from a 6LN containing a Hop- 168 by-Hop extension to a node on the Internet. 170 +---+ +---+ +---+ 171 |6LN|-------------------|LBR|--------------------| D | 172 +---+ LOWPAN_LE +---+ IPv6 Header|Data +---+ 173 [CH=0 Length Value] 174 LOWPAN_IPHC 175 [header values] 176 Data 178 Figure 4: removing Local extensions 180 In a route-over mode a 6LR receiving a packet with a LOWPAW_LE can be 181 decompressed to a compatible IPv6 packet by adding extension in the 182 transmission order before the payload. For instance: 184 LOWPAN_LE 185 [CH=0 Length Value] 186 LOWPAN_LE 187 [CH=41, Length, Value] 188 LOWPAN_IPHC 189 [header values] 190 Destination H. 191 Data 193 Figure 5: Local extensions received 195 Will be expanded in: 197 [IPv6 Header (NH=0)] 198 [HbH (NH=41)] 199 [Routing (NH=60)] 200 [Destination (NH=XX)] 201 Data 203 Figure 6: Uncompressed packet 205 For Mesh-Under, the process is transparent to 6LR, only 6LN may have 206 to expand the packet. 208 5. Security Considerations 210 The LOWPAN_LE is functionally equivalent to a tunnel. 212 6. Normative References 214 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 215 (IPv6) Specification", RFC 2460, December 1998. 217 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 218 Power and Lossy Networks (RPL) Option for Carrying RPL 219 Information in Data-Plane Datagrams", RFC 6553, March 220 2012. 222 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 223 Routing Header for Source Routes with the Routing Protocol 224 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 225 2012. 227 Author's Address 229 Laurent Toutain 230 Institut MINES TELECOM ; TELECOM Bretagne 231 2 rue de la Chataigneraie 232 CS 17607 233 35576 Cesson-Sevigne Cedex 234 France 236 Email: Laurent.Toutain@telecom-bretagne.eu