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