idnits 2.17.1 draft-boucadair-lisp-v6-compact-header-05.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 (June 14, 2017) is 2508 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: December 16, 2017 June 14, 2017 7 A Compact LISP Encapsulation Scheme to Transport IPv4 Packets over an 8 IPv6 Network 9 draft-boucadair-lisp-v6-compact-header-05 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 December 16, 2017. 45 Copyright Notice 47 Copyright (c) 2017 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 . . . . . . . . . . . . . . . 8 68 3. LISP Encapsulation with the Compact Header Form . . . . . . . 10 69 3.1. UDP Packets . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.2. TCP Packets . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.3. Fragments . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4. LISP Decapsulation with the Compact LISP Header . . . . . . . 12 73 4.1. Build an IPv4/UDP Header . . . . . . . . . . . . . . . . 12 74 4.2. Build an IPv4/TCP Header . . . . . . . . . . . . . . . . 12 75 5. A More Compact LISP Encapsulation Flavor . . . . . . . . . . 13 76 5.1. LISP Encapsulation with the More Compact Header Form . . 15 77 5.1.1. UDP Packets . . . . . . . . . . . . . . . . . . . . . 15 78 5.1.2. TCP Packets . . . . . . . . . . . . . . . . . . . . . 16 79 5.1.3. Fragments . . . . . . . . . . . . . . . . . . . . . . 16 80 5.2. LISP Decapsulation with the More Compact LISP Header . . 16 81 5.2.1. Build an IPv4/UDP Header . . . . . . . . . . . . . . 17 82 5.2.2. Build an IPv4/TCP Header . . . . . . . . . . . . . . 17 83 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 87 10. Normative references . . . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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|R|K|K| 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|R|K|K| 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|R|K|K| Nonce/Map-Version | 257 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 S / | Instance ID/Locator-Status-Bits | 259 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 NEW: 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 L |N|L|E|V|I|C|K|K| 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 description of the remaining fields is the same as in [RFC6830] 271 and [RFC8061]. Note, the definition of the C-bit does not interfere 272 with the functionality provided by other flag bits. 274 The use of the C-bit as defined in this document is encouraged in 275 IPv6 migration contexts that rely upon IPv4-embedded IPv6 addresses, 276 as defined in [RFC6052]. Concretely, IPv4-embedded IPv6 addresses 277 are used to convey Source/Destination IPv4 EIDs in Source/Destination 278 Routing Locators. 280 2.2. On the Use of IPv4-Embedded IPv6 RLOCs 282 Figure 4 summarizes how the IPv4-embedded IPv6 RLOCs are synthesized 283 from IPv4 EIDs. As discussed in [RFC6052], the "u" byte is set to 284 zero. 286 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 287 | RLOC Prefix (64 bits) | u | EID(32) | suffix | 288 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 290 Where "suffix" is : 292 * the concatenation of "Protocol" field of the Internet header 293 as conveyed in the original packet and "source port" of the transport 294 header of the original packet (Source IPv4-embedded IPv6 address). 296 * the concatenation of a null octet and "source port" of transport 297 header of the original packet (Source IPv4-embedded IPv6 address). 299 Figure 4: IPv4-embedded RLOCs 301 2.3. Truncated TCP Header 303 In addition to the use of IPv4-embedded IPv6 addresses, this document 304 proposes the use of a truncated TCP header as shown in Figure 5 to 305 reduce the size of the LISP header. 307 TCP Header: 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Source Port | Destination Port | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Sequence Number | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Acknowledgment Number | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Data | |U|A|P|R|S|F| | 316 | Offset| Reserved |R|C|S|S|Y|I| Window | 317 | | |G|K|H|T|N|N| | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Checksum | Urgent Pointer | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | (Optional) Options | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Truncated TCP Header: 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Sequence Number | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Acknowledgment Number | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Data | |U|A|P|R|S|F| | 331 | Offset| Reserved |R|C|S|S|Y|I| Window | 332 | | |G|K|H|T|N|N| | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | (Optional) Options | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 5: Truncated TCP Header 339 2.4. Compact LISP Header Format 341 The compact LISP header for a TCP packet is shown in Figure 6, while 342 the compact LISP header for UDP is depicted in Figure 7. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 / |Version| Traffic Class | Flow Label | 348 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | Payload Length | Next Header=17| Hop Limit | 350 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 351 | | | | 352 I + Source Routing Locator (64 bits) + | 353 P | | S 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 355 H | u byte | Source EID ... | C 356 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 357 A | .... | Protocol | (Inner) Source Port | | 358 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 359 E | | | 360 R + Destination Routing Locator (64 bits) + | 361 | | | D 362 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 363 | | u byte | Destination EID ... | T 364 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 365 \ | .... | 00000000 |(Inner)Destination Port | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 367 / | Source Port = xxxx | Dest Port = 4341 | 368 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 \ | UDP Length | UDP Checksum | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 L |N|L|E|V|I|C|K|K| Nonce/Map-Version | 372 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 S / | Instance ID/Locator-Status-Bits | 374 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Sequence Number | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Acknowledgment Number | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Data | |U|A|P|R|S|F| | 380 | Offset| Reserved |R|C|S|S|Y|I| Window | 381 | | |G|K|H|T|N|N| | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | (Optional) Options | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 6: Compact LISP Header Format (TCP Case) 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 / |Version| Traffic Class | Flow Label | 392 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | Payload Length | Next Header=17| Hop Limit | 394 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 395 | | | | 396 I + Source Routing Locator (64 bits) + | 397 P | | S 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 399 H | u byte | Source EID ... | C 400 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 401 A | .... | Protocol | (Inner) Source Port | | 402 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 403 E | | | 404 R + Destination Routing Locator (64 bits) + | 405 | | | D 406 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 407 | | u byte | Destination EID ... | T 408 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 409 \ | .... | 00000000 |(Inner)Destination Port | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 411 / | Source Port = xxxx | Dest Port = 4341 | 412 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 \ | UDP Length | UDP Checksum | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 L |N|L|E|V|I|C|K|K| Nonce/Map-Version | 416 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 S / | Instance ID/Locator-Status-Bits | 418 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 7: Compact LISP Header Format (UDP Case) 422 3. LISP Encapsulation with the Compact Header Form 424 Upon receipt of an IPv4 packet that needs to be forwarded over a 425 LISP-enabled IPv6 infrastructure, the ITR proceeds as described in 426 Section 3.1 for UDP packets and in Section 3.2 for TCP packets. 427 Section 3.3 specifies how fragments are handled. 429 3.1. UDP Packets 431 o Retrieve the destination/source RLOC IPv6 prefix. 432 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 433 IPv4 address, the "Protocol" as indicated in the IP header, and 434 the source port number to form the source IPv6 address as 435 specified in Section 2.2 for non-fragmented packets and fragments 436 that convey a transport header. 437 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 438 destination IPv4 address, a null octet, and the destination port 439 number to form the destination IPv6 address as specified in 440 Section 2.2 for non-fragmented packets and fragments that convey a 441 transport header. 442 o Remove both the IP and UDP headers of the original packet. 443 o Prepend the LISP header with the C-flag set (Section 2.1). 444 o Prepend the UDP header. 445 o Prepend the IPv6 header. 447 3.2. TCP Packets 449 o Retrieve the destination/source RLOC IPv6 prefix. 450 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 451 IPv4 address, the "Protocol" as indicated in the IP header, and 452 the source port number to form the source IPv6 address as 453 specified in Section 2.2 for non-fragmented packets and fragments 454 that convey a transport header. 455 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 456 destination IPv4 address, a null octet, and the destination port 457 number to form the destination IPv6 address as specified in 458 Section 2.2 for non-fragmented packets and fragments that convey a 459 transport header. 460 o Remove the IP header, the first 4 bytes of the TCP header, and the 461 4 bytes right after the "window" field from the original TCP 462 header (Section 2.3). 463 o Prepend the LISP header with the C-flag set (Section 2.1). 464 o Prepend the UDP header. 465 o Prepend the IPv6 header. 467 3.3. Fragments 469 o Retrieve the destination/source RLOC IPv6 prefix. 470 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 471 IPv4 address, and 3 bytes the "Protocol" as indicated in the IP 472 header, and 2 bytes paddings of "1". 473 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 474 destination IPv4 address, and 3 bytes paddings of "1". 475 o Remove both the IP header of the original packet. 476 o Prepend the LISP header with the C-flag set (Section 2.1). 477 o Prepend the UDP header. 478 o Prepend the IPv6 header. 480 4. LISP Decapsulation with the Compact LISP Header 482 Upon receipt of a LISP packet with the C-bit set, the ETR proceeds as 483 follows to extract the inner IP packets (Section 4.1 for UDP and 484 Section 4.2 for TCP). 486 The processing of the other flag bits is not detailed in this 487 specification. Other than encoding RLOCs as prefixes, the behavior 488 defined in [RFC6830] is not impacted by this specification. 490 Obviously if the C-bit is unset, xTR routers follow the behavior 491 defined in [RFC6830]. 493 The UDP checksum setting and validation of LISP-encapsulated packets 494 MUST follow the guidelines documented in Section 5.3 of [RFC6830]. 496 4.1. Build an IPv4/UDP Header 498 o Check whether the destination IPv6 address matches an RLOC prefix 499 owned by the xTR. 500 o Extract the Source EID that is encoded in positions 72 to 103 of 501 the Source IPv6 address. 502 o Extract the "Protocol" field that is encoded in positions 104 to 503 111 of the Source IPv6 address. This value is used to set the 504 corresponding field in the IPv4 header of the de-capsulated 505 packet. 506 o Extract the Source Port that is encoded in positions 112 to 127 of 507 the Source IPv6 address, for non-fragmented packets and fragments 508 that convey a transport header. 509 o Extract the Destination EID that is encoded in positions 72 to 103 510 of the Destination IPv6 address. 511 o Extract the Destination Port that is encoded in positions 112 to 512 127 of the Destination IPv6 address, for non-fragmented packets 513 and fragments that convey a transport header. 514 o Remove the IPv6 header, the UDP header, and the LISP header. 515 o Use the extracted Source Port and Destination Port to build the 516 UDP header. Prepend the new UDP header. 517 o Use the extracted Source IP address, Destination IP address, and 518 Protocol to build the IPv4 header. 519 o Prepend the new IPv4 header. 521 4.2. Build an IPv4/TCP Header 523 o Check whether the destination IPv6 address matches an RLOC prefix 524 owned by the xTR. 525 o Extract the Source EID that is encoded in positions 72 to 103 of 526 the Source IPv6 address. 528 o Extract the "Protocol" field that is encoded in positions 104 to 529 111 of the Source IPv6 address. This value is used to set the 530 corresponding field in the IPv4 header of the de-capsulated 531 packet. 532 o Extract the Source Port that is encoded in positions 112 to 127 of 533 the Source IPv6 address, for non-fragmented packets and fragments 534 that convey a transport header. 535 o Extract the Destination EID that is encoded in positions 72 to 103 536 of the Destination IPv6 address. 537 o Extract the Destination Port that is encoded in positions 112 to 538 127 of the Destination IPv6 address, for non-fragmented packets 539 and fragments that convey a transport header. 540 o Remove the IPv6 header, UDP header, and LISP header. 541 o For non-fragmented packets and fragments that convey a transport 542 header, prepend 4 bytes with the source/destination port number 543 and insert 4 bytes right after the "window" field to build a 544 proper TCP header. The extracted Source Port and Destination Port 545 are used in this step. 546 o Prepend an IPv4 header. Use the extracted Source IP address, 547 Destination IP address, and Protocol to build the IPv4 header. 549 5. A More Compact LISP Encapsulation Flavor 551 A more compact LISP encapsulation scheme can be considered if the 552 following conditions are met: 554 o Compatibility with "u" byte is not required. 555 o The origin "Source Port" number is copied into the UDP header of 556 the encapsulated packet, and vice versa. 557 o The LISP shim is split into two parts: 4 bytes that are placed 558 right after the UDP header while "Instance ID/Locator-Status-Bits" 559 are encoded in the last 32 bits of the source IPv4-embedded IPv6 560 RLOC. 562 This alternate proposal leads to a 4-byte overhead when transporting 563 IPv4-over-IPv6 LISP packets for both TCP (Figure 8) and UDP 564 (Figure 9). 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 / |Version| Traffic Class | Flow Label | 570 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | Payload Length | Next Header=17| Hop Limit | 572 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 573 | | | | 574 I + Source Routing Locator (64 bits) + | 575 P | | S 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 577 H | Source EID | C 578 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 579 A | Instance ID/Locator-Status-Bits | | 580 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 581 E | | | 582 R + Destination Routing Locator (64 bits) + | 583 | | | D 584 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 585 | | Destination EID | T 586 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 587 \ | 00000000 |(Inner)Protocol|(Inner)Destination Port | | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 589 / | Source Port = Inner Src Port | Dest Port = 4341 | 590 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 \ | UDP Length | UDP Checksum | 592 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 I | |N|L|E|V|I|C|K|K| Nonce/Map-Version | 594 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 P | Sequence Number | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Acknowledgment Number | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Data | |U|A|P|R|S|F| | 600 | Offset| Reserved |R|C|S|S|Y|I| Window | 601 | | |G|K|H|T|N|N| | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | (Optional) Options | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Figure 8: More Compacted LISP Header Format (TCP Case) 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 / |Version| Traffic Class | Flow Label | 612 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | Payload Length | Next Header=17| Hop Limit | 614 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 615 | | | | 616 I + Source Routing Locator (64 bits) + | 617 P | | S 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 619 H | Source EID | C 620 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 621 A | Instance ID/Locator-Status-Bits | | 622 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 623 E | | | 624 R + Destination Routing Locator (64 bits) + | 625 | | | D 626 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 627 | | Destination EID | T 628 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 629 \ | 00000000 |(Inner)Protocol|(Inner)Destination Port | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 631 / | Source Port = Inner Src Port | Dest Port = 4341 | 632 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 \ | UDP Length | UDP Checksum | 634 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 I | |N|L|E|V|I|C|K|K| Nonce/Map-Version | 636 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 P 639 Figure 9: More Compacted LISP Header Format (UDP Case) 641 5.1. LISP Encapsulation with the More Compact Header Form 643 Upon receipt of an IPv4 packet that needs to be forwarded over a 644 LISP-enabled infrastructure, the ITR proceeds as follows: 646 5.1.1. UDP Packets 648 o Retrieve the destination/source RLOC IPv6 prefix. 649 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 650 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 651 address as shown in Figure 9. 652 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 653 address, a null octet, the "Protocol" as indicated in the IP 654 header, and the destination port number to form the destination 655 IPv6 address as shown in Figure 9, for non-fragmented packets and 656 fragments that convey a transport header. 657 o Remove the IPv4 header. 658 o Set the destination port number of the UDP header to 4341. 659 o Insert the LISP header right after the UDP header; the C-flag must 660 be set (Section 2.1). 661 o Prepend the IPv6 header. 663 5.1.2. TCP Packets 665 o Retrieve the destination/source RLOC IPv6 prefix. 666 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 667 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 668 address as shown in Figure 8. 669 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 670 address, a null octet, the "Protocol" as indicated in the IP 671 header, and the destination port number to form the destination 672 IPv6 address as shown in Figure 8, for non-fragmented packets and 673 fragments that convey a transport header. 674 o Remove the IPv4 header. 675 o Remove the first 4 bytes and the 4 bytes right after the "window" 676 field of the TCP header (Section 2.3). 677 o Prepend the LISP header; the C-flag must be set (Section 2.1).. 678 o Prepend the UDP header. Set to the source port number to the same 679 port indicated in the original TCP header. Set the destination 680 port number of the UDP header to 4341. 681 o Prepend an IPv6 header. 683 5.1.3. Fragments 685 o Retrieve the destination/source RLOC IPv6 prefix. 686 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 687 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 688 address as shown in Figure 9. 689 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 690 address, a non-null octet, the "Protocol" as indicated in the IP 691 header, and a null octet padding to form the destination IPv6 692 address. 693 o Remove the IPv4 header. 694 o Insert the LISP header. 695 o Insert the UDP header with a destination port number set to 4341. 696 o Prepend the IPv6 header. 698 5.2. LISP Decapsulation with the More Compact LISP Header 700 Upon receipt of a LISP packet with the C-bit set, the ETR proceeds as 701 follows to extract the inner IP packets: (Figure 9 for UDP and 702 Figure 8 for TCP). Like in Section 2, the UDP checksum setting and 703 validation of LISP-encapsulated packets MUST follow the guidelines 704 documented in Section 5.3 of [RFC6830]. 706 5.2.1. Build an IPv4/UDP Header 708 o Check whether the destination IPv6 address matches an RLOC prefix 709 owned by the xTR. 710 o Extract the Source EID that is encoded in positions 64 to 95 of 711 the Source IPv6 address. 712 o Extract the "Instance ID/Locator-Status-Bits" field that is 713 encoded in positions 96 to 127 of the Source IPv6 address. 714 o Extract the Destination EID that is encoded in positions 64 to 95 715 of the Destination IPv6 address. 716 o Extract the "Protocol" that is encoded in positions 104 to 111 of 717 the Destination IPv6 address. 718 o Extract the Destination Port that is encoded in positions 112 to 719 127 of the Destination IPv6 address if the octet in positions 96 720 to 103 is not null. 721 o Remove the IPv6 header, the UDP header, and the LISP header. 722 o For non-fragmented packets and fragments that convey a transport 723 header, use the extracted Source Port and Destination Port to 724 build the UDP header. Prepend the new UDP header. 725 o Use the extracted Source IPv4 address, Destination IPv4 address, 726 and Protocol to build the IPv4 header. Prepend the new IPv4 727 header. 729 5.2.2. Build an IPv4/TCP Header 731 o Check whether the destination IPv6 address matches an RLOC prefix 732 owned by the xTR. 733 o Extract the Source EID that is encoded in positions 64 to 95 of 734 the Source IPv6 address. 735 o Extract the "Instance ID/Locator-Status-Bits" field that is 736 encoded in positions 96 to 127 of the Source IPv6 address. 737 o Extract the Destination EID that is encoded in positions 64 to 95 738 of the Destination IPv6 address. 739 o Extract the "Protocol" that is encoded in positions 104 to 111 of 740 the Destination IPv6 address. 741 o Extract the Destination Port that is encoded in positions 112 to 742 127 of the Destination IPv6 address if the octet in positions 96 743 to 103 is not null. 744 o Check whether the destination IPv6 address matches an RLOC prefix 745 owned by the xTR. 746 o Remove the IPv6 header, UDP header, and LISP header. 747 o For non-fragmented packets and fragments that convey a transport 748 header, prepend 4 bytes with the source/destination port number 749 and insert 4 bytes right after the "window" field to build a 750 proper TCP header. The extracted Source Port and Destination Port 751 are used during this step. 752 o Prepend an IPv4 header. Use the extracted Source IP address, 753 Destination IP address, and Protocol to build the IPv4 header. 755 6. Discussion 757 The proposed compact headers are experimental. What primarily 758 motivates this specification is the need to assess its technical 759 feasibility thanks to an existing LISP-enabled platform. Experiments 760 will help evaluate the gain brought by using such compact headers 761 compared to base LISP encapsulation scheme in typical IPv6 migration 762 scenarios 764 The proposed compact encapsulation schemes guarantee a functional 765 parity with the base LISP specification, given that the signalling 766 carried in a LISP packet remains usable. 768 This specification does not include any capability checks to ensure 769 that remote xTRs support the proposed header encoding. Particularly, 770 deployability considerations in multi-domain LISP environments are 771 not detailed in this document. 773 This specification assumes that a configuration parameter should be 774 supported by LISP implementations to tweak the encapsulation scheme 775 to be used. 777 The handling of fragmented packets by an ETR follows the same steps 778 as in Section 2 except that, for the fragments that do not carry the 779 source/destination port numbers, a non-null octet of the "suffix" 780 defined Figure 4 is used to signal that the LISP-encapsulated packet 781 is a fragment that does not convey transport-related information. 783 7. Security Considerations 785 The security considerations discussed in Section 12 of[RFC6830] are 786 valid for this document. 788 Security considerations related to building an IPv4-embedded IPv6 789 address are discussed in [RFC6052]. 791 8. IANA Considerations 793 This document does not make any request to IANA. 795 9. Acknowledgments 797 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 798 009-X. 800 Many thanks to S. Secci, L. Iannone, and J. Saldana for the review 801 and comments. 803 The gain ratio table is a courtesy of J. Saldana. 805 10. Normative references 807 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 808 DOI 10.17487/RFC0768, August 1980, 809 . 811 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 812 RFC 793, DOI 10.17487/RFC0793, September 1981, 813 . 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, 817 DOI 10.17487/RFC2119, March 1997, 818 . 820 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 821 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 822 DOI 10.17487/RFC6052, October 2010, 823 . 825 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 826 Locator/ID Separation Protocol (LISP)", RFC 6830, 827 DOI 10.17487/RFC6830, January 2013, 828 . 830 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 831 (LISP) Data-Plane Confidentiality", RFC 8061, 832 DOI 10.17487/RFC8061, February 2017, 833 . 835 Authors' Addresses 837 Mohamed Boucadair 838 Orange 839 Rennes 35000 840 France 842 EMail: mohamed.boucadair@orange.com 843 Christian Jacquenet 844 Orange 845 Rennes 35000 846 France 848 EMail: christian.jacquenet@orange.com