idnits 2.17.1 draft-boucadair-lisp-v6-compact-header-01.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 (December 1, 2015) is 3066 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 France Telecom 5 Expires: June 3, 2016 December 1, 2015 7 A Compact LISP Encapsulation Scheme to Transport IPv4 Packets over an 8 IPv6 Network 9 draft-boucadair-lisp-v6-compact-header-01 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 June 3, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 Section 2 describes a compact header format that leads to a 8-byte 215 overhead when transporting IPv4-over-IPv6 LISP packets for both TCP 216 and UDP. Section 5 proposes a more compact header with 4-byte 217 overhead for both TCP and UDP packets. These overhead figures are 218 computed in reference to the size of the original packets. 220 This document does not introduce an overhead compared to the 221 encapsulation scheme in [RFC6830] given that the solution relies on a 222 compact encoding. 224 This document assumes that RLOCs can be encoded as prefixes. One of 225 the bits of "Unused Flags" in a Map-Register and Map-Reply can be 226 used to explicitly indicate the enclosed locator is an IPv6 prefix. 227 The length of the prefix can be 32, 40, 48, 56, 64, or 96 [RFC6052]. 228 The RLOC address will be built using the algorithm in [RFC6052]. 230 2. A Compact LISP Header 232 Figure 3 shows the required change to the LISP header. The "flg" 233 bits are reserved bits for future assignment as additional flag bits. 234 These additional flag bits MUST each be set to zero and MUST be 235 ignored upon receipt. The description of the remaining fields is the 236 same as in [RFC6830]. Note, the definition of the C-bit does not 237 interfere with the functionality provided by other flag bits. 239 OLD: 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 L |N|L|E|V|I|flags| Nonce/Map-Version | 242 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 S / | Instance ID/Locator-Status-Bits | 244 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 NEW: 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 L |N|L|E|V|I|flg|C| Nonce/Map-Version | 249 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 S / | Instance ID/Locator-Status-Bits | 251 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 3: C-bit in the LISP Header 255 The use of the C-bit as defined in this document is encouraged in 256 IPv6 migration contexts that rely upon IPv4-embedded IPv6 addresses, 257 as defined in [RFC6052]. Concretely, IPv4-embedded IPv6 addresses 258 are used to convey Source/Destination IPv4 EIDs in Source/Destination 259 Routing Locators. Figure 4 summarizes how the IPv4-embedded IPv6 260 RLOCs are synthesized from IPv4 EIDs. As discussed in [RFC6052], the 261 "u" byte is set to zero. 263 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 264 | RLOC Prefix (64 bits) | u | EID(32) | suffix | 265 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 267 Where "suffix" is : 269 * the concatenation of "Protocol" field of the Internet header 270 as conveyed in the original packet and "source port" of the transport 271 header of the original packet (Source IPv4-embedded IPv6 address). 273 * the concatenation of a null octet and "source port" of transport 274 header of the original packet (Source IPv4-embedded IPv6 address). 276 Figure 4: IPv4-embedded RLOCs 278 Also, the TCP header is truncated as shown in Figure 5. 280 TCP Header: 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Source Port | Destination Port | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Sequence Number | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Acknowledgment Number | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Data | |U|A|P|R|S|F| | 289 | Offset| Reserved |R|C|S|S|Y|I| Window | 290 | | |G|K|H|T|N|N| | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Checksum | Urgent Pointer | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | (Optional) Options | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Truncated TCP Header: 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Sequence Number | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Acknowledgment Number | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Data | |U|A|P|R|S|F| | 304 | Offset| Reserved |R|C|S|S|Y|I| Window | 305 | | |G|K|H|T|N|N| | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | (Optional) Options | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 5: Truncated TCP Header 312 The compact LISP header for a TCP packet is shown in Figure 6, while 313 the compact LISP header for UDP is depicted in Figure 6. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 / |Version| Traffic Class | Flow Label | 319 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | Payload Length | Next Header=17| Hop Limit | 321 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 322 | | | | 323 I + Source Routing Locator (64 bits) + | 324 P | | S 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 326 H | u byte | Source EID ... | C 327 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 328 A | .... | Protocol | (Inner) Source Port | | 329 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 330 E | | | 331 R + Destination Routing Locator (64 bits) + | 332 | | | D 333 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 334 | | u byte | Destination EID ... | T 335 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 336 \ | .... | 00000000 |(Inner)Destination Port | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 338 / | Source Port = xxxx | Dest Port = 4341 | 339 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 \ | UDP Length | UDP Checksum | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 L |N|L|E|V|I|flg|C| Nonce/Map-Version | 343 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 S / | Instance ID/Locator-Status-Bits | 345 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Sequence Number | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Acknowledgment Number | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Data | |U|A|P|R|S|F| | 351 | Offset| Reserved |R|C|S|S|Y|I| Window | 352 | | |G|K|H|T|N|N| | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | (Optional) Options | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 6: Compact LISP Header Format (TCP Case) 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 / |Version| Traffic Class | Flow Label | 363 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | Payload Length | Next Header=17| Hop Limit | 365 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 366 | | | | 367 I + Source Routing Locator (64 bits) + | 368 P | | S 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 370 H | u byte | Source EID ... | C 371 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 372 A | .... | Protocol | (Inner) Source Port | | 373 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 374 E | | | 375 R + Destination Routing Locator (64 bits) + | 376 | | | D 377 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 378 | | u byte | Destination EID ... | T 379 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 380 \ | .... | 00000000 |(Inner)Destination Port | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 382 / | Source Port = xxxx | Dest Port = 4341 | 383 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 \ | UDP Length | UDP Checksum | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 L |N|L|E|V|I|flg|C| Nonce/Map-Version | 387 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 S / | Instance ID/Locator-Status-Bits | 389 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 7: Compact LISP Header Format (UDP Case) 393 3. LISP Encapsulation with the Compact Header Form 395 Upon receipt of an IPv4 packet that needs to be forwarded over a 396 LISP-enabled infrastructure, the ITR proceeds as follows: 398 3.1. UDP Packets 400 o Retrieve the destination/source RLOC IPv6 prefix. 401 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 402 IPv4 address, the "Protocol" as indicated in the IP header, and 403 the source port number to form the source IPv6 address as 404 specified in Section 2 for non-fragmented packets and fragments 405 that convey a transport header. 407 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 408 destination IPv4 address, a null octet, and the destination port 409 number to form the destination IPv6 address as specified in 410 Section 2 for non-fragmented packets and fragments that convey a 411 transport header. 412 o Remove both the IP and UDP headers of the original packet. 413 o Prepend the LISP header. 414 o Prepend the UDP header. 415 o Prepend the IPv6 header. 417 3.2. TCP Packets 419 o Retrieve the destination/source RLOC IPv6 prefix. 420 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 421 IPv4 address, the "Protocol" as indicated in the IP header, and 422 the source port number to form the source IPv6 address as 423 specified in Section 2 for non-fragmented packets and fragments 424 that convey a transport header. 425 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 426 destination IPv4 address, a null octet, and the destination port 427 number to form the destination IPv6 address as specified in 428 Section 2 for non-fragmented packets and fragments that convey a 429 transport header. 430 o Remove the IP header and the first 4 bytes and the 4 bytes right 431 after the "window" field from the original TCP header. 432 o Prepend the LISP header. 433 o Prepend the UDP header. 434 o Prepend the IPv6 header. 436 3.3. Fragments 438 o Retrieve the destination/source RLOC IPv6 prefix. 439 o Concatenate the source RLOC IPv6 prefix, the u byte, the source 440 IPv4 address, and 3 bytes the "Protocol" as indicated in the IP 441 header, and 2 bytes paddings of "1". 442 o Concatenate the destination RLOC IPv6 prefix, the u byte, the 443 destination IPv4 address, and 3 bytes paddings of "1". 444 o Remove both the IP header of the original packet. 445 o Prepend the LISP header. 446 o Prepend the UDP header. 447 o Prepend the IPv6 header. 449 4. LISP Decapsulation with the Compact LISP Header 451 Upon receipt of a LISP packet with the C-bit set, the ETR proceeds as 452 follows to extract the inner IP packets (Section 4.1 for UDP and 453 Section 4.2 for TCP). 455 The processing of the other flag bits is not detailed in this 456 specification. Other than encoding RLOCs as prefixes, the behavior 457 defined in [RFC6830] is not impacted by this specification. 459 Obviously if the C-bit is unset, xTR routers follow the behavior 460 defined in [RFC6830]. 462 The UDP checksum setting and validation of LISP-encapsulated packets 463 MUST follow the guidelines documented in Section 5.3 of [RFC6830]. 465 4.1. Build an IPv4/UDP Header 467 o Check whether the destination IPv6 address matches an RLOC prefix 468 owned by the xTR. 469 o Extract the Source EID that is encoded in positions 72 to 103 of 470 the Source IPv6 address. 471 o Extract the "Protocol" field that is encoded in positions 104 to 472 111 of the Source IPv6 address. This value is used to set the 473 corresponding field in the IPv4 header of the de-capsulated 474 packet. 475 o Extract the Source Port that is encoded in positions 112 to 127 of 476 the Source IPv6 address, for non-fragmented packets and fragments 477 that convey a transport header. 478 o Extract the Destination EID that is encoded in positions 72 to 103 479 of the Destination IPv6 address. 480 o Extract the Destination Port that is encoded in positions 112 to 481 127 of the Destination IPv6 address, for non-fragmented packets 482 and fragments that convey a transport header. 483 o Remove the IPv6 header, the UDP header, and the LISP header. 484 o Use the extracted Source Port and Destination Port to build the 485 UDP header. Prepend the new UDP header. 486 o Use the extracted Source IP address, Destination IP address, and 487 Protocol to build the IPv4 header. 488 o Prepend the new IPv4 header. 490 4.2. Build an IPv4/TCP Header 492 o Check whether the destination IPv6 address matches an RLOC prefix 493 owned by the xTR. 494 o Extract the Source EID that is encoded in positions 72 to 103 of 495 the Source IPv6 address. 496 o Extract the "Protocol" field that is encoded in positions 104 to 497 111 of the Source IPv6 address. This value is used to set the 498 corresponding field in the IPv4 header of the de-capsulated 499 packet. 500 o Extract the Source Port that is encoded in positions 112 to 127 of 501 the Source IPv6 address, for non-fragmented packets and fragments 502 that convey a transport header. 504 o Extract the Destination EID that is encoded in positions 72 to 103 505 of the Destination IPv6 address. 506 o Extract the Destination Port that is encoded in positions 112 to 507 127 of the Destination IPv6 address, for non-fragmented packets 508 and fragments that convey a transport header. 509 o Remove the IPv6 header, UDP header, and LISP header. 510 o For non-fragmented packets and fragments that convey a transport 511 header, prepend 4 bytes with the source/destination port number 512 and insert 4 bytes right after the "window" field to build a 513 proper TCP header. The extracted Source Port and Destination Port 514 are used in this step. 515 o Prepend an IPv4 header. Use the extracted Source IP address, 516 Destination IP address, and Protocol to build the IPv4 header. 518 5. A More Compact LISP Encapsulation Flavor 520 A more compact LISP encapsulation scheme can be considered if the 521 following conditions are met: 523 o Compatibility with "u" byte is not required. 524 o The origin "Source Port" number is copied into the UDP header of 525 the encapsulated packet, and vice versa. 526 o The LISP shim is split into two parts: 4 bytes that are placed 527 right after the UDP header while "Instance ID/Locator-Status-Bits" 528 are encoded in the last 32 bits of the source IPv4-embedded IPv6 529 RLOC. 531 This alternate proposal leads to a 4-byte overhead when transporting 532 IPv4-over-IPv6 LISP packets for both TCP (Figure 8) and UDP 533 (Figure 9). 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 / |Version| Traffic Class | Flow Label | 539 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | Payload Length | Next Header=17| Hop Limit | 541 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 542 | | | | 543 I + Source Routing Locator (64 bits) + | 544 P | | S 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 546 H | Source EID | C 547 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 548 A | Instance ID/Locator-Status-Bits | | 549 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 550 E | | | 551 R + Destination Routing Locator (64 bits) + | 552 | | | D 553 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 554 | | Destination EID | T 555 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 556 \ | 00000000 |(Inner)Protocol|(Inner)Destination Port | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 558 / | Source Port = Inner Src Port | Dest Port = 4341 | 559 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 \ | UDP Length | UDP Checksum | 561 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 I | |N|L|E|V|I|flg|C| Nonce/Map-Version | 563 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 P | Sequence Number | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Acknowledgment Number | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Data | |U|A|P|R|S|F| | 569 | Offset| Reserved |R|C|S|S|Y|I| Window | 570 | | |G|K|H|T|N|N| | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | (Optional) Options | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 8: More Compacted LISP Header Format (TCP Case) 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 / |Version| Traffic Class | Flow Label | 581 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | | Payload Length | Next Header=17| Hop Limit | 583 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 584 | | | | 585 I + Source Routing Locator (64 bits) + | 586 P | | S 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 588 H | Source EID | C 589 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 590 A | Instance ID/Locator-Status-Bits | | 591 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 592 E | | | 593 R + Destination Routing Locator (64 bits) + | 594 | | | D 595 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 596 | | Destination EID | T 597 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 598 \ | 00000000 |(Inner)Protocol|(Inner)Destination Port | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 600 / | Source Port = Inner Src Port | Dest Port = 4341 | 601 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 \ | UDP Length | UDP Checksum | 603 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 I | |N|L|E|V|I|flg|C| Nonce/Map-Version | 605 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 P 608 Figure 9: More Compacted LISP Header Format (UDP Case) 610 5.1. LISP Encapsulation with the More Compact Header Form 612 Upon receipt of an IPv4 packet that needs to be forwarded over a 613 LISP-enabled infrastructure, the ITR proceeds as follows: 615 5.1.1. UDP Packets 617 o Retrieve the destination/source RLOC IPv6 prefix. 618 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 619 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 620 address as shown in Figure 9. 621 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 622 address, a null octet, the "Protocol" as indicated in the IP 623 header, and the destination port number to form the destination 624 IPv6 address as shown in Figure 9, for non-fragmented packets and 625 fragments that convey a transport header. 626 o Remove the IPv4 header. 627 o Set the destination port number of the UDP header to 4341. 628 o Insert the LISP header right after the UDP header. 629 o Prepend the IPv6 header. 631 5.1.2. TCP Packets 633 o Retrieve the destination/source RLOC IPv6 prefix. 634 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 635 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 636 address as shown in Figure 8. 637 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 638 address, a null octet, the "Protocol" as indicated in the IP 639 header, and the destination port number to form the destination 640 IPv6 address as shown in Figure 8, for non-fragmented packets and 641 fragments that convey a transport header. 642 o Remove the IPv4 header. 643 o Remove the first 4 bytes and the 4 bytes right after the "window" 644 field of the TCP header. 645 o Prepend the LISP header. 646 o Prepend the UDP header. Set to the source port number to the same 647 port indicated in the original TCP header. Set the destination 648 port number of the UDP header to 4341. 649 o Prepend an IPv6 header. 651 5.1.3. Fragments 653 o Retrieve the destination/source RLOC IPv6 prefix. 654 o Concatenate the source RLOC IPv6 prefix, the source IPv4 address, 655 and the "Instance ID/Locator-Status-Bits" to form the source IPv6 656 address as shown in Figure 9. 657 o Concatenate the destination RLOC IPv6 prefix, the destination IPv4 658 address, a non-null octet, the "Protocol" as indicated in the IP 659 header, and a null octet padding to form the destination IPv6 660 address. 661 o Remove the IPv4 header. 662 o Insert the LISP header. 663 o Insert the UDP header with a destination port number set to 4341. 664 o Prepend the IPv6 header. 666 5.2. LISP Decapsulation with the More Compact LISP Header 668 Upon receipt of a LISP packet with the C-bit set, the ETR proceeds as 669 follows to extract the inner IP packets: (Figure 9 for UDP and 670 Figure 8 for TCP). Like in Section 2, the UDP checksum setting and 671 validation of LISP-encapsulated packets MUST follow the guidelines 672 documented in Section 5.3 of [RFC6830]. 674 5.2.1. Build an IPv4/UDP Header 676 o Check whether the destination IPv6 address matches an RLOC prefix 677 owned by the xTR. 678 o Extract the Source EID that is encoded in positions 64 to 95 of 679 the Source IPv6 address. 680 o Extract the "Instance ID/Locator-Status-Bits" field that is 681 encoded in positions 96 to 127 of the Source IPv6 address. 682 o Extract the Destination EID that is encoded in positions 64 to 95 683 of the Destination IPv6 address. 684 o Extract the "Protocol" that is encoded in positions 104 to 111 of 685 the Destination IPv6 address. 686 o Extract the Destination Port that is encoded in positions 112 to 687 127 of the Destination IPv6 address if the octet in positions 96 688 to 103 is not null. 689 o Remove the IPv6 header, the UDP header, and the LISP header. 690 o For non-fragmented packets and fragments that convey a transport 691 header, use the extracted Source Port and Destination Port to 692 build the UDP header. Prepend the new UDP header. 693 o Use the extracted Source IPv4 address, Destination IPv4 address, 694 and Protocol to build the IPv4 header. Prepend the new IPv4 695 header. 697 5.2.2. Build an IPv4/TCP Header 699 o Check whether the destination IPv6 address matches an RLOC prefix 700 owned by the xTR. 701 o Extract the Source EID that is encoded in positions 64 to 95 of 702 the Source IPv6 address. 703 o Extract the "Instance ID/Locator-Status-Bits" field that is 704 encoded in positions 96 to 127 of the Source IPv6 address. 705 o Extract the Destination EID that is encoded in positions 64 to 95 706 of the Destination IPv6 address. 707 o Extract the "Protocol" that is encoded in positions 104 to 111 of 708 the Destination IPv6 address. 709 o Extract the Destination Port that is encoded in positions 112 to 710 127 of the Destination IPv6 address if the octet in positions 96 711 to 103 is not null. 712 o Check whether the destination IPv6 address matches an RLOC prefix 713 owned by the xTR. 714 o Remove the IPv6 header, UDP header, and LISP header. 715 o For non-fragmented packets and fragments that convey a transport 716 header, prepend 4 bytes with the source/destination port number 717 and insert 4 bytes right after the "window" field to build a 718 proper TCP header. The extracted Source Port and Destination Port 719 are used during this step. 720 o Prepend an IPv4 header. Use the extracted Source IP address, 721 Destination IP address, and Protocol to build the IPv4 header. 723 6. Discussion 725 The proposed compact headers are experimental. What primarily 726 motivates this specification is the need to assess its technical 727 feasibility thanks to an existing LISP-enabled platform. Experiments 728 will help evaluate the gain brought by using such compact headers 729 compared to base LISP encapsulation scheme in typical IPv6 migration 730 scenarios 732 The proposed compact encapsulation schemes guarantee a functional 733 parity with the base LISP specification, given that the signalling 734 carried in a LISP packet remains usable. 736 This specification does not include any capability checks to ensure 737 that remote xTRs support the proposed header encoding. Particularly, 738 deployability considerations in multi-domain LISP environments are 739 not detailed in this document. 741 This specification assumes that a configuration parameter should be 742 supported by LISP implementations to tweak the encapsulation scheme 743 to be used. 745 The handling of fragmented packets by an ETR follows the same steps 746 as in Section 2 except that, for the fragments that do not carry the 747 source/destination port numbers, a non-null octet of the "suffix" 748 defined Figure 4 is used to signal that the LISP-encapsulated packet 749 is a fragment that does not convey transport-related information. 751 7. Security Considerations 753 The security considerations discussed in Section 12 of[RFC6830] are 754 valid for this document. 756 Security considerations related to building an IPv4-embedded IPv6 757 address are discussed in [RFC6052]. 759 8. IANA Considerations 761 This document does not make any request to IANA. 763 9. Acknowledgments 765 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 766 009-X. 768 Many thanks to S. Secci and L. Iannone for the review and comments. 770 10. Normative references 772 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 773 DOI 10.17487/RFC0768, August 1980, 774 . 776 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 777 RFC 793, DOI 10.17487/RFC0793, September 1981, 778 . 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, 782 DOI 10.17487/RFC2119, March 1997, 783 . 785 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 786 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 787 DOI 10.17487/RFC6052, October 2010, 788 . 790 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 791 Locator/ID Separation Protocol (LISP)", RFC 6830, 792 DOI 10.17487/RFC6830, January 2013, 793 . 795 Authors' Addresses 797 Mohamed Boucadair 798 France Telecom 799 Rennes 35000 800 France 802 EMail: mohamed.boucadair@orange.com 804 Christian Jacquenet 805 France Telecom 806 Rennes 35000 807 France 809 EMail: christian.jacquenet@orange.com