idnits 2.17.1 draft-boucadair-lisp-v6-compact-header-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2016) is 2702 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 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 M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental Orange 5 Expires: May 26, 2017 November 22, 2016 7 A Compact LISP Encapsulation Scheme to Transport IPv4 Packets over an 8 IPv6 Network 9 draft-boucadair-lisp-v6-compact-header-03 11 Abstract 13 The encapsulation scheme used by the Locator/ID Separation Protocol 14 (LISP) may sometimes raise MTU issues at the cost of possibly 15 degrading the overall performance of the LISP network, especially in 16 IPv6 migration contexts. This document proposes a new, more compact, 17 encapsulation scheme that aims to accommodate such issues and 18 facilitate LISP deployment for IPv6 migration purposes, in 19 particular. This compact header may be considered to provide IPv4 20 over IPv6 connectivity for mobile LISP-capable devices. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 26, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. A Compact LISP Header . . . . . . . . . . . . . . . . . . . . 6 64 2.1. C Flag . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2. On the Use of IPv4-Embedded IPv6 RLOCs . . . . . . . . . 7 66 2.3. Truncated TCP Header . . . . . . . . . . . . . . . . . . 8 67 2.4. Compact LISP Header Format . . . . . . . . . . . . . . . 9 68 3. LISP Encapsulation with the Compact Header Form . . . . . . . 11 69 3.1. UDP Packets . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.2. TCP Packets . . . . . . . . . . . . . . . . . . . . . . . 12 71 3.3. Fragments . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4. LISP Decapsulation with the Compact LISP Header . . . . . . . 13 73 4.1. Build an IPv4/UDP Header . . . . . . . . . . . . . . . . 13 74 4.2. Build an IPv4/TCP Header . . . . . . . . . . . . . . . . 13 75 5. A More Compact LISP Encapsulation Flavor . . . . . . . . . . 14 76 5.1. LISP Encapsulation with the More Compact Header Form . . 16 77 5.1.1. UDP Packets . . . . . . . . . . . . . . . . . . . . . 16 78 5.1.2. TCP Packets . . . . . . . . . . . . . . . . . . . . . 17 79 5.1.3. Fragments . . . . . . . . . . . . . . . . . . . . . . 17 80 5.2. LISP Decapsulation with the More Compact LISP Header . . 17 81 5.2.1. Build an IPv4/UDP Header . . . . . . . . . . . . . . 18 82 5.2.2. Build an IPv4/TCP Header . . . . . . . . . . . . . . 18 83 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 87 10. Normative references . . . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 The base specification of the Locator/ID Separation Protocol (LISP, 93 [RFC6830]) defines an encapsulation scheme for transporting packets 94 between xTR routers. When applied at the scale of the Internet, this 95 encapsulation scheme may raise MTU issues because of the LISP 96 overhead. This overhead may be aggravated when IPv6 transfer 97 capabilities are used to interconnect LISP sites. 99 As a reminder, Figure 1 shows the format of an encapsulated TCP 100 ([RFC0793]) packet over IPv6, while Figure 2 covers UDP ([RFC0768]). 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 / |Version| Traffic Class | Flow Label | 106 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | | Payload Length | Next Header=17| Hop Limit | 108 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | | 110 O + + 111 u | | 112 t + Source Routing Locator + 113 e | | 114 r + + 115 | | 116 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 d | | 118 r + + 119 | | 120 ^ + Destination Routing Locator + 121 | | | 122 \ + + 123 \ | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 / | Source Port = xxxx | Dest Port = 4341 | 126 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 \ | UDP Length | UDP Checksum | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 L |N|L|E|V|I|flags| Nonce/Map-Version | 130 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 S / | Instance ID/Locator-Status-Bits | 132 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 / |Version| IHL |Type of Service| Total Length | 134 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | Identification |Flags| Fragment Offset | 136 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 IH | Time to Live | Protocol | Header Checksum | 138 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | | Source EID | 140 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 \ | Destination EID | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 / | Source Port | Destination Port | 144 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | Sequence Number | 146 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | Acknowledgment Number | 148 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 TCP | Data | |U|A|P|R|S|F| | 150 | | Offset| Reserved |R|C|S|S|Y|I| Window | 151 | | | |G|K|H|T|N|N| | 152 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | | Checksum | Urgent Pointer | 154 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 \ | (Optional) Options | 156 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 1: LISP IPv4-in-IPv6 Header Format (TCP) 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 / |Version| Traffic Class | Flow Label | 164 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | Payload Length | Next Header=17| Hop Limit | 166 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 O + + 169 u | | 170 t + Source Routing Locator + 171 e | | 172 r + + 173 | | 174 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 d | | 176 r + + 177 | | 178 ^ + Destination Routing Locator + 179 | | | 180 \ + + 181 \ | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 / | Source Port = xxxx | Dest Port = 4341 | 184 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 \ | UDP Length | UDP Checksum | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 L |N|L|E|V|I|flags| Nonce/Map-Version | 188 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 S / | Instance ID/Locator-Status-Bits | 190 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 / |Version| IHL |Type of Service| Total Length | 192 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | Identification |Flags| Fragment Offset | 194 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 IH | Time to Live | Protocol | Header Checksum | 196 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | Source EID | 198 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 \ | Destination EID | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 / | Source Port | Destination Port | 202 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 \ | UDP Length | UDP Checksum | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2: LISP IPv4-in-IPv6 Header Format (UDP) 208 This document proposes a new LISP encapsulation scheme that aims to 209 reduce the overhead induced by LISP encapsulation (i.e., the one 210 defined in [RFC6830]) to transport IPv4 packets over an IPv6 211 infrastructure. 213 This proposal does not suggest to obsolete the current LISP base 214 encapsulation mode as defined in [RFC6830]. Rather, this document 215 proposes to associate a meaning with one of the reserved flag bits 216 (see Section 5.3 of [RFC6830]) to explicitly indicate that, when the 217 bit is set, compact LISP encapsulation is in use. This bit is called 218 the C-bit ("Compact" flag bit). Defining this capability in the base 219 LISP header will help experimenting this compact header and assess 220 its efficiency. 222 This document does not introduce an overhead compared to the 223 encapsulation scheme in [RFC6830] given that the solution relies on a 224 compact encoding. Some examples to illustrate the compression ratio 225 achieved with the proposed compact header are shown below. 227 +----------+--------------+-----------+-----------+ 228 | Origin | RFC6830 | Compact | Compact | 229 | Size | IPv4-in-IPv6 | Header 1 | Header 2 | 230 +--------------+----------+--------------+-----------+-----------+ 231 | TCP ACK | 40 bytes | 96 bytes | 68 bytes | 64 bytes | 232 | | | | Gain: 29% | Gain: 33% | 233 +--------------+----------+--------------+-----------+-- --------+ 234 | RTP | 60 bytes | 116 bytes | 80 bytes | 76 bytes | 235 | | | | Gain: 31% | Gain: 34% | 236 +--------------+----------+--------------+-----------+-----------+ 238 This document assumes that RLOCs can be encoded as prefixes. One of 239 the bits of "Unused Flags" in a Map-Register and Map-Reply can be 240 used to explicitly indicate the enclosed locator is an IPv6 prefix. 241 The length of the prefix can be 32, 40, 48, 56, 64, or 96 [RFC6052]. 242 The RLOC address will be built using the algorithm in [RFC6052]. 244 2. A Compact LISP Header 246 2.1. C Flag 248 In order to allow for the co-existence of both legacy LISP header and 249 this compact new header, this document associates a meaning with one 250 of the reserved flag bits in [RFC6830]. Concretely, Figure 3 shows 251 the required change to the LISP header to support the new compact 252 LISP header. 254 OLD: 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 L |N|L|E|V|I|flags| Nonce/Map-Version | 257 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 S / | Instance ID/Locator-Status-Bits | 259 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 NEW: 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 L |N|L|E|V|I|flg|C| Nonce/Map-Version | 264 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 S / | Instance ID/Locator-Status-Bits | 266 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 3: C-bit in the LISP Header 270 The "flg" bits are reserved bits for future assignment as additional 271 flag bits. These additional flag bits MUST each be set to zero and 272 MUST be ignored upon receipt. 274 The description of the remaining fields is the same as in [RFC6830]. 275 Note, the definition of the C-bit does not interfere with the 276 functionality provided by other flag bits. 278 The use of the C-bit as defined in this document is encouraged in 279 IPv6 migration contexts that rely upon IPv4-embedded IPv6 addresses, 280 as defined in [RFC6052]. Concretely, IPv4-embedded IPv6 addresses 281 are used to convey Source/Destination IPv4 EIDs in Source/Destination 282 Routing Locators. 284 2.2. On the Use of IPv4-Embedded IPv6 RLOCs 286 Figure 4 summarizes how the IPv4-embedded IPv6 RLOCs are synthesized 287 from IPv4 EIDs. As discussed in [RFC6052], the "u" byte is set to 288 zero. 290 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 291 | RLOC Prefix (64 bits) | u | EID(32) | suffix | 292 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 294 Where "suffix" is : 296 * the concatenation of "Protocol" field of the Internet header 297 as conveyed in the original packet and "source port" of the transport 298 header of the original packet (Source IPv4-embedded IPv6 address). 300 * the concatenation of a null octet and "source port" of transport 301 header of the original packet (Source IPv4-embedded IPv6 address). 303 Figure 4: IPv4-embedded RLOCs 305 2.3. Truncated TCP Header 307 In addition to the use of IPv4-embedded IPv6 addresses, this document 308 proposes the use of a truncated TCP header as shown in Figure 5 to 309 reduce the size of the LISP header. 311 TCP Header: 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Source Port | Destination Port | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Sequence Number | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Acknowledgment Number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Data | |U|A|P|R|S|F| | 320 | Offset| Reserved |R|C|S|S|Y|I| Window | 321 | | |G|K|H|T|N|N| | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Checksum | Urgent Pointer | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | (Optional) Options | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Truncated TCP Header: 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Sequence Number | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Acknowledgment Number | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Data | |U|A|P|R|S|F| | 335 | Offset| Reserved |R|C|S|S|Y|I| Window | 336 | | |G|K|H|T|N|N| | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | (Optional) Options | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 5: Truncated TCP Header 343 2.4. Compact LISP Header Format 345 The compact LISP header for a TCP packet is shown in Figure 6, while 346 the compact LISP header for UDP is depicted in Figure 7. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 / |Version| Traffic Class | Flow Label | 352 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | Payload Length | Next Header=17| Hop Limit | 354 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 355 | | | | 356 I + Source Routing Locator (64 bits) + | 357 P | | S 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 359 H | u byte | Source EID ... | C 360 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 361 A | .... | Protocol | (Inner) Source Port | | 362 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 363 E | | | 364 R + Destination Routing Locator (64 bits) + | 365 | | | D 366 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 367 | | u byte | Destination EID ... | T 368 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 369 \ | .... | 00000000 |(Inner)Destination Port | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 371 / | Source Port = xxxx | Dest Port = 4341 | 372 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 \ | UDP Length | UDP Checksum | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 L |N|L|E|V|I|flg|C| Nonce/Map-Version | 376 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 S / | Instance ID/Locator-Status-Bits | 378 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Sequence Number | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Acknowledgment Number | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Data | |U|A|P|R|S|F| | 384 | Offset| Reserved |R|C|S|S|Y|I| Window | 385 | | |G|K|H|T|N|N| | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | (Optional) Options | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 6: Compact LISP Header Format (TCP Case) 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 / |Version| Traffic Class | Flow Label | 396 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | Payload Length | Next Header=17| Hop Limit | 398 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 399 | | | | 400 I + Source Routing Locator (64 bits) + | 401 P | | S 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 403 H | u byte | Source EID ... | C 404 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 405 A | .... | Protocol | (Inner) Source Port | | 406 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 407 E | | | 408 R + Destination Routing Locator (64 bits) + | 409 | | | D 410 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 411 | | u byte | Destination EID ... | T 412 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 413 \ | .... | 00000000 |(Inner)Destination Port | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 415 / | Source Port = xxxx | Dest Port = 4341 | 416 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 \ | UDP Length | UDP Checksum | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 L |N|L|E|V|I|flg|C| Nonce/Map-Version | 420 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 S / | Instance ID/Locator-Status-Bits | 422 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 7: Compact LISP Header Format (UDP Case) 426 3. LISP Encapsulation with the Compact Header Form 428 Upon receipt of an IPv4 packet that needs to be forwarded over a 429 LISP-enabled IPv6 infrastructure, the ITR proceeds as described in 430 Section 3.1 for UDP packets and in Section 3.2 for TCP packets. 431 Section 3.3 specifies how fragments are handled. 433 3.1. UDP Packets 435 o Retrieve the destination/source RLOC IPv6 prefix. 436 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 437 IPv4 address, the "Protocol" as indicated in the IP header, and 438 the source port number to form the source IPv6 address as 439 specified in Section 2.2 for non-fragmented packets and fragments 440 that convey a transport header. 441 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 442 destination IPv4 address, a null octet, and the destination port 443 number to form the destination IPv6 address as specified in 444 Section 2.2 for non-fragmented packets and fragments that convey a 445 transport header. 446 o Remove both the IP and UDP headers of the original packet. 447 o Prepend the LISP header with the C-flag set (Section 2.1). 448 o Prepend the UDP header. 449 o Prepend the IPv6 header. 451 3.2. TCP Packets 453 o Retrieve the destination/source RLOC IPv6 prefix. 454 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 455 IPv4 address, the "Protocol" as indicated in the IP header, and 456 the source port number to form the source IPv6 address as 457 specified in Section 2.2 for non-fragmented packets and fragments 458 that convey a transport header. 459 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 460 destination IPv4 address, a null octet, and the destination port 461 number to form the destination IPv6 address as specified in 462 Section 2.2 for non-fragmented packets and fragments that convey a 463 transport header. 464 o Remove the IP header, the first 4 bytes of the TCP header, and the 465 4 bytes right after the "window" field from the original TCP 466 header (Section 2.3). 467 o Prepend the LISP header with the C-flag set (Section 2.1). 468 o Prepend the UDP header. 469 o Prepend the IPv6 header. 471 3.3. Fragments 473 o Retrieve the destination/source RLOC IPv6 prefix. 474 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 475 IPv4 address, and 3 bytes the "Protocol" as indicated in the IP 476 header, and 2 bytes paddings of "1". 477 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 478 destination IPv4 address, and 3 bytes paddings of "1". 479 o Remove both the IP header of the original packet. 480 o Prepend the LISP header with the C-flag set (Section 2.1). 481 o Prepend the UDP header. 482 o Prepend the IPv6 header. 484 4. LISP Decapsulation with the Compact LISP Header 486 Upon receipt of a LISP packet with the C-bit set, the ETR proceeds as 487 follows to extract the inner IP packets (Section 4.1 for UDP and 488 Section 4.2 for TCP). 490 The processing of the other flag bits is not detailed in this 491 specification. Other than encoding RLOCs as prefixes, the behavior 492 defined in [RFC6830] is not impacted by this specification. 494 Obviously if the C-bit is unset, xTR routers follow the behavior 495 defined in [RFC6830]. 497 The UDP checksum setting and validation of LISP-encapsulated packets 498 MUST follow the guidelines documented in Section 5.3 of [RFC6830]. 500 4.1. Build an IPv4/UDP Header 502 o Check whether the destination IPv6 address matches an RLOC prefix 503 owned by the xTR. 504 o Extract the Source EID that is encoded in positions 72 to 103 of 505 the Source IPv6 address. 506 o Extract the "Protocol" field that is encoded in positions 104 to 507 111 of the Source IPv6 address. This value is used to set the 508 corresponding field in the IPv4 header of the de-capsulated 509 packet. 510 o Extract the Source Port that is encoded in positions 112 to 127 of 511 the Source IPv6 address, for non-fragmented packets and fragments 512 that convey a transport header. 513 o Extract the Destination EID that is encoded in positions 72 to 103 514 of the Destination IPv6 address. 515 o Extract the Destination Port that is encoded in positions 112 to 516 127 of the Destination IPv6 address, for non-fragmented packets 517 and fragments that convey a transport header. 518 o Remove the IPv6 header, the UDP header, and the LISP header. 519 o Use the extracted Source Port and Destination Port to build the 520 UDP header. Prepend the new UDP header. 521 o Use the extracted Source IP address, Destination IP address, and 522 Protocol to build the IPv4 header. 523 o Prepend the new IPv4 header. 525 4.2. Build an IPv4/TCP Header 527 o Check whether the destination IPv6 address matches an RLOC prefix 528 owned by the xTR. 529 o Extract the Source EID that is encoded in positions 72 to 103 of 530 the Source IPv6 address. 532 o Extract the "Protocol" field that is encoded in positions 104 to 533 111 of the Source IPv6 address. This value is used to set the 534 corresponding field in the IPv4 header of the de-capsulated 535 packet. 536 o Extract the Source Port that is encoded in positions 112 to 127 of 537 the Source IPv6 address, for non-fragmented packets and fragments 538 that convey a transport header. 539 o Extract the Destination EID that is encoded in positions 72 to 103 540 of the Destination IPv6 address. 541 o Extract the Destination Port that is encoded in positions 112 to 542 127 of the Destination IPv6 address, for non-fragmented packets 543 and fragments that convey a transport header. 544 o Remove the IPv6 header, UDP header, and LISP header. 545 o For non-fragmented packets and fragments that convey a transport 546 header, prepend 4 bytes with the source/destination port number 547 and insert 4 bytes right after the "window" field to build a 548 proper TCP header. The extracted Source Port and Destination Port 549 are used in this step. 550 o Prepend an IPv4 header. Use the extracted Source IP address, 551 Destination IP address, and Protocol to build the IPv4 header. 553 5. A More Compact LISP Encapsulation Flavor 555 A more compact LISP encapsulation scheme can be considered if the 556 following conditions are met: 558 o Compatibility with "u" byte is not required. 559 o The origin "Source Port" number is copied into the UDP header of 560 the encapsulated packet, and vice versa. 561 o The LISP shim is split into two parts: 4 bytes that are placed 562 right after the UDP header while "Instance ID/Locator-Status-Bits" 563 are encoded in the last 32 bits of the source IPv4-embedded IPv6 564 RLOC. 566 This alternate proposal leads to a 4-byte overhead when transporting 567 IPv4-over-IPv6 LISP packets for both TCP (Figure 8) and UDP 568 (Figure 9). 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 / |Version| Traffic Class | Flow Label | 574 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | Payload Length | Next Header=17| Hop Limit | 576 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 577 | | | | 578 I + Source Routing Locator (64 bits) + | 579 P | | S 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 581 H | Source EID | C 582 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 583 A | Instance ID/Locator-Status-Bits | | 584 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 585 E | | | 586 R + Destination Routing Locator (64 bits) + | 587 | | | D 588 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 589 | | Destination EID | T 590 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 591 \ | 00000000 |(Inner)Protocol|(Inner)Destination Port | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 593 / | Source Port = Inner Src Port | Dest Port = 4341 | 594 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 \ | UDP Length | UDP Checksum | 596 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 I | |N|L|E|V|I|flg|C| Nonce/Map-Version | 598 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 P | Sequence Number | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Acknowledgment Number | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Data | |U|A|P|R|S|F| | 604 | Offset| Reserved |R|C|S|S|Y|I| Window | 605 | | |G|K|H|T|N|N| | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | (Optional) Options | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Figure 8: More Compacted LISP Header Format (TCP Case) 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 / |Version| Traffic Class | Flow Label | 616 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | | Payload Length | Next Header=17| Hop Limit | 618 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 619 | | | | 620 I + Source Routing Locator (64 bits) + | 621 P | | S 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 623 H | Source EID | C 624 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 625 A | Instance ID/Locator-Status-Bits | | 626 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 627 E | | | 628 R + Destination Routing Locator (64 bits) + | 629 | | | D 630 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 631 | | Destination EID | T 632 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 633 \ | 00000000 |(Inner)Protocol|(Inner)Destination Port | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 635 / | Source Port = Inner Src Port | Dest Port = 4341 | 636 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 \ | UDP Length | UDP Checksum | 638 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 I | |N|L|E|V|I|flg|C| Nonce/Map-Version | 640 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 P 643 Figure 9: More Compacted LISP Header Format (UDP Case) 645 5.1. LISP Encapsulation with the More Compact Header Form 647 Upon receipt of an IPv4 packet that needs to be forwarded over a 648 LISP-enabled infrastructure, the ITR proceeds as follows: 650 5.1.1. UDP Packets 652 o Retrieve the destination/source RLOC IPv6 prefix. 653 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 654 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 655 address as shown in Figure 9. 656 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 657 address, a null octet, the "Protocol" as indicated in the IP 658 header, and the destination port number to form the destination 659 IPv6 address as shown in Figure 9, for non-fragmented packets and 660 fragments that convey a transport header. 661 o Remove the IPv4 header. 662 o Set the destination port number of the UDP header to 4341. 663 o Insert the LISP header right after the UDP header; the C-flag must 664 be set (Section 2.1). 665 o Prepend the IPv6 header. 667 5.1.2. TCP Packets 669 o Retrieve the destination/source RLOC IPv6 prefix. 670 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 671 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 672 address as shown in Figure 8. 673 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 674 address, a null octet, the "Protocol" as indicated in the IP 675 header, and the destination port number to form the destination 676 IPv6 address as shown in Figure 8, for non-fragmented packets and 677 fragments that convey a transport header. 678 o Remove the IPv4 header. 679 o Remove the first 4 bytes and the 4 bytes right after the "window" 680 field of the TCP header (Section 2.3). 681 o Prepend the LISP header; the C-flag must be set (Section 2.1).. 682 o Prepend the UDP header. Set to the source port number to the same 683 port indicated in the original TCP header. Set the destination 684 port number of the UDP header to 4341. 685 o Prepend an IPv6 header. 687 5.1.3. Fragments 689 o Retrieve the destination/source RLOC IPv6 prefix. 690 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 691 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 692 address as shown in Figure 9. 693 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 694 address, a non-null octet, the "Protocol" as indicated in the IP 695 header, and a null octet padding to form the destination IPv6 696 address. 697 o Remove the IPv4 header. 698 o Insert the LISP header. 699 o Insert the UDP header with a destination port number set to 4341. 700 o Prepend the IPv6 header. 702 5.2. LISP Decapsulation with the More Compact LISP Header 704 Upon receipt of a LISP packet with the C-bit set, the ETR proceeds as 705 follows to extract the inner IP packets: (Figure 9 for UDP and 706 Figure 8 for TCP). Like in Section 2, the UDP checksum setting and 707 validation of LISP-encapsulated packets MUST follow the guidelines 708 documented in Section 5.3 of [RFC6830]. 710 5.2.1. Build an IPv4/UDP Header 712 o Check whether the destination IPv6 address matches an RLOC prefix 713 owned by the xTR. 714 o Extract the Source EID that is encoded in positions 64 to 95 of 715 the Source IPv6 address. 716 o Extract the "Instance ID/Locator-Status-Bits" field that is 717 encoded in positions 96 to 127 of the Source IPv6 address. 718 o Extract the Destination EID that is encoded in positions 64 to 95 719 of the Destination IPv6 address. 720 o Extract the "Protocol" that is encoded in positions 104 to 111 of 721 the Destination IPv6 address. 722 o Extract the Destination Port that is encoded in positions 112 to 723 127 of the Destination IPv6 address if the octet in positions 96 724 to 103 is not null. 725 o Remove the IPv6 header, the UDP header, and the LISP header. 726 o For non-fragmented packets and fragments that convey a transport 727 header, use the extracted Source Port and Destination Port to 728 build the UDP header. Prepend the new UDP header. 729 o Use the extracted Source IPv4 address, Destination IPv4 address, 730 and Protocol to build the IPv4 header. Prepend the new IPv4 731 header. 733 5.2.2. Build an IPv4/TCP Header 735 o Check whether the destination IPv6 address matches an RLOC prefix 736 owned by the xTR. 737 o Extract the Source EID that is encoded in positions 64 to 95 of 738 the Source IPv6 address. 739 o Extract the "Instance ID/Locator-Status-Bits" field that is 740 encoded in positions 96 to 127 of the Source IPv6 address. 741 o Extract the Destination EID that is encoded in positions 64 to 95 742 of the Destination IPv6 address. 743 o Extract the "Protocol" that is encoded in positions 104 to 111 of 744 the Destination IPv6 address. 745 o Extract the Destination Port that is encoded in positions 112 to 746 127 of the Destination IPv6 address if the octet in positions 96 747 to 103 is not null. 748 o Check whether the destination IPv6 address matches an RLOC prefix 749 owned by the xTR. 750 o Remove the IPv6 header, UDP header, and LISP header. 751 o For non-fragmented packets and fragments that convey a transport 752 header, prepend 4 bytes with the source/destination port number 753 and insert 4 bytes right after the "window" field to build a 754 proper TCP header. The extracted Source Port and Destination Port 755 are used during this step. 756 o Prepend an IPv4 header. Use the extracted Source IP address, 757 Destination IP address, and Protocol to build the IPv4 header. 759 6. Discussion 761 The proposed compact headers are experimental. What primarily 762 motivates this specification is the need to assess its technical 763 feasibility thanks to an existing LISP-enabled platform. Experiments 764 will help evaluate the gain brought by using such compact headers 765 compared to base LISP encapsulation scheme in typical IPv6 migration 766 scenarios 768 The proposed compact encapsulation schemes guarantee a functional 769 parity with the base LISP specification, given that the signalling 770 carried in a LISP packet remains usable. 772 This specification does not include any capability checks to ensure 773 that remote xTRs support the proposed header encoding. Particularly, 774 deployability considerations in multi-domain LISP environments are 775 not detailed in this document. 777 This specification assumes that a configuration parameter should be 778 supported by LISP implementations to tweak the encapsulation scheme 779 to be used. 781 The handling of fragmented packets by an ETR follows the same steps 782 as in Section 2 except that, for the fragments that do not carry the 783 source/destination port numbers, a non-null octet of the "suffix" 784 defined Figure 4 is used to signal that the LISP-encapsulated packet 785 is a fragment that does not convey transport-related information. 787 7. Security Considerations 789 The security considerations discussed in Section 12 of[RFC6830] are 790 valid for this document. 792 Security considerations related to building an IPv4-embedded IPv6 793 address are discussed in [RFC6052]. 795 8. IANA Considerations 797 This document does not make any request to IANA. 799 9. Acknowledgments 801 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 802 009-X. 804 Many thanks to S. Secci, L. Iannone, and J. Saldana for the review 805 and comments. 807 The gain ratio table is a courtesy of J. Saldana. 809 10. Normative references 811 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 812 DOI 10.17487/RFC0768, August 1980, 813 . 815 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 816 RFC 793, DOI 10.17487/RFC0793, September 1981, 817 . 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, 821 DOI 10.17487/RFC2119, March 1997, 822 . 824 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 825 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 826 DOI 10.17487/RFC6052, October 2010, 827 . 829 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 830 Locator/ID Separation Protocol (LISP)", RFC 6830, 831 DOI 10.17487/RFC6830, January 2013, 832 . 834 Authors' Addresses 836 Mohamed Boucadair 837 Orange 838 Rennes 35000 839 France 841 EMail: mohamed.boucadair@orange.com 842 Christian Jacquenet 843 Orange 844 Rennes 35000 845 France 847 EMail: christian.jacquenet@orange.com