<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc rfcedstyle="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<rfc category="exp" docName="draft-boucadair-lisp-v6-compact-header-05"
     ipr="trust200902">
  <front>
    <title abbrev="Compact LISP Encapsulation">A Compact LISP Encapsulation
    Scheme to Transport IPv4 Packets over an IPv6 Network</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <date day="" month="" year="" />

    <area>Internet</area>

    <keyword>IPv4 service continuity</keyword>

    <keyword>IPv4 address exhaustion</keyword>

    <keyword>Service Availability</keyword>

    <keyword>Address sharing</keyword>

    <keyword>IPv6</keyword>

    <keyword>Reliability</keyword>

    <keyword>IPv4 over IPv6</keyword>

    <abstract>
      <t>The encapsulation scheme used by the Locator/ID Separation Protocol
      (LISP) may sometimes raise MTU issues at the cost of possibly degrading
      the overall performance of the LISP network, especially in IPv6
      migration contexts. This document proposes a new, more compact,
      encapsulation scheme that aims to accommodate such issues and facilitate
      LISP deployment for IPv6 migration purposes, in particular. This compact
      header may be considered to provide IPv4 over IPv6 connectivity for
      mobile LISP-capable devices.</t>

      <t><!--Also the fragmentation and reassembly case is not at all clear in the document.
--></t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The base specification of the Locator/ID Separation Protocol (LISP,
      <xref target="RFC6830"></xref>) defines an encapsulation scheme for
      transporting packets between xTR routers. When applied at the scale of
      the Internet, this encapsulation scheme may raise MTU issues because of
      the LISP overhead. This overhead may be aggravated when IPv6 transfer
      capabilities are used to interconnect LISP sites.</t>

      <t>As a reminder, <xref target="tcp"></xref> shows the format of an
      encapsulated TCP (<xref target="RFC0793"></xref>) packet over IPv6,
      while <xref target="udp"></xref> covers UDP (<xref
      target="RFC0768"></xref>).</t>

      <t><figure anchor="tcp" title="LISP IPv4-in-IPv6 Header Format (TCP)">
          <artwork><![CDATA[      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version| Traffic Class |           Flow Label                  |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Payload Length        | Next Header=17|   Hop Limit   |
 v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
 O   +                                                               +
 u   |                                                               |
 t   +                     Source Routing Locator                    +
 e   |                                                               |
 r   +                                                               +
     |                                                               |
 H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 d   |                                                               |
 r   +                                                               +
     |                                                               |
 ^   +                  Destination Routing Locator                  +
 |   |                                                               |
  \  +                                                               +
   \ |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |       Source Port = xxxx      |       Dest Port = 4341        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 L   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 S / |                 Instance ID/Locator-Status-Bits               |
 P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version|  IHL  |Type of Service|          Total Length         |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Identification        |Flags|      Fragment Offset    |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 IH  |  Time to Live |    Protocol   |         Header Checksum       |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |                           Source EID                          |
  \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |                         Destination EID                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |          Source Port          |       Destination Port        |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |                        Sequence Number                        |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |                    Acknowledgment Number                      |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP  |  Data |           |U|A|P|R|S|F|                               |
 |   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
 |   |       |           |G|K|H|T|N|N|                               |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |           Checksum            |         Urgent Pointer        |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \  |                      (Optional) Options                       |
   \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure><figure align="right" anchor="udp"
          title="LISP IPv4-in-IPv6 Header Format (UDP)">
          <artwork><![CDATA[      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version| Traffic Class |           Flow Label                  |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Payload Length        | Next Header=17|   Hop Limit   |
 v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
 O   +                                                               +
 u   |                                                               |
 t   +                     Source Routing Locator                    +
 e   |                                                               |
 r   +                                                               +
     |                                                               |
 H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 d   |                                                               |
 r   +                                                               +
     |                                                               |
 ^   +                  Destination Routing Locator                  +
 |   |                                                               |
  \  +                                                               +
   \ |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |       Source Port = xxxx      |       Dest Port = 4341        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 L   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 S / |                 Instance ID/Locator-Status-Bits               |
 P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version|  IHL  |Type of Service|          Total Length         |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Identification        |Flags|      Fragment Offset    |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 IH  |  Time to Live |    Protocol   |         Header Checksum       |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |                           Source EID                          |
  \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |                         Destination EID                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |           Source Port         |       Destination Port        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure></t>

      <t>This document proposes a new LISP encapsulation scheme that aims to
      reduce the overhead induced by LISP encapsulation (i.e., the one defined
      in <xref target="RFC6830"></xref>) to transport IPv4 packets over an
      IPv6 infrastructure.</t>

      <t>This proposal does not suggest to obsolete the current LISP base
      encapsulation mode as defined in <xref target="RFC6830"></xref>. Rather,
      this document proposes to associate a meaning with one of the reserved
      flag bits (see Section 5.3 of <xref target="RFC6830"></xref>) to
      explicitly indicate that, when the bit is set, compact LISP
      encapsulation is in use. This bit is called the C-bit ("Compact" flag
      bit). Defining this capability in the base LISP header will help
      experimenting this compact header and assess its efficiency.</t>

      <t>This document does not introduce an overhead compared to the
      encapsulation scheme in <xref target="RFC6830"></xref> given that the
      solution relies on a compact encoding. Some examples to illustrate the
      compression ratio achieved with the proposed compact header are shown
      below.<figure>
          <artwork><![CDATA[                  +----------+--------------+-----------+-----------+
                  | Origin   | RFC6830      | Compact   | Compact   |
                  | Size     | IPv4-in-IPv6 | Header 1  | Header 2  |
   +--------------+----------+--------------+-----------+-----------+
   | TCP ACK      | 40 bytes | 96 bytes     | 68 bytes  | 64 bytes  |
   |              |          |              | Gain: 29% | Gain: 33% |
   +--------------+----------+--------------+-----------+-- --------+
   | RTP          | 60 bytes | 116 bytes    | 80 bytes  | 76 bytes  |
   |              |          |              | Gain: 31% | Gain: 34% |
   +--------------+----------+--------------+-----------+-----------+]]></artwork>
        </figure></t>

      <t>This document assumes that RLOCs can be encoded as prefixes. One of
      the bits of "Unused Flags" in a Map-Register and Map-Reply can be used
      to explicitly indicate the enclosed locator is an IPv6 prefix. The
      length of the prefix can be 32, 40, 48, 56, 64, or 96 <xref
      target="RFC6052"></xref>. The RLOC address will be built using the
      algorithm in <xref target="RFC6052"></xref>.</t>
    </section>

    <section anchor="comp" title="A Compact LISP Header">
      <t></t>

      <section anchor="cbit" title="C Flag">
        <t>In order to allow for the co-existence of both legacy LISP header
        and this compact new header, this document associates a meaning with
        one of the reserved flag bits in <xref target="RFC6830"></xref>.
        Concretely, <xref target="cflag"></xref> shows the required change to
        the LISP header to support the new compact LISP header.</t>

        <t><figure anchor="cflag" title="C-bit in the LISP Header">
            <artwork><![CDATA[OLD:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|C|K|K|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t>The description of the remaining fields is the same as in <xref
        target="RFC6830"></xref> and <xref target="RFC8061"></xref>. Note, the
        definition of the C-bit does not interfere with the functionality
        provided by other flag bits.</t>

        <t>The use of the C-bit as defined in this document is encouraged in
        IPv6 migration contexts that rely upon IPv4-embedded IPv6 addresses,
        as defined in <xref target="RFC6052"></xref>. Concretely,
        IPv4-embedded IPv6 addresses are used to convey Source/Destination
        IPv4 EIDs in Source/Destination Routing Locators.</t>
      </section>

      <section anchor="emba" title="On the Use of IPv4-Embedded IPv6 RLOCs">
        <t><xref target="emb"></xref> summarizes how the IPv4-embedded IPv6
        RLOCs are synthesized from IPv4 EIDs. As discussed in <xref
        target="RFC6052"></xref>, the "u" byte is set to zero.</t>

        <t><figure align="center" anchor="emb" title="IPv4-embedded RLOCs">
            <artwork><![CDATA[    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |     RLOC Prefix (64 bits)     | u |   EID(32)     | suffix    |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Where "suffix" is : 

 * the concatenation of "Protocol" field of the Internet header
   as conveyed in the original packet and "source port" of the transport
   header of the original packet (Source IPv4-embedded IPv6 address).

 * the concatenation of a null octet and  "source port" of transport
   header of the original packet (Source IPv4-embedded IPv6 address). 
]]></artwork>
          </figure></t>

        <t></t>
      </section>

      <section anchor="trun" title="Truncated TCP Header">
        <t>In addition to the use of IPv4-embedded IPv6 addresses, this
        document proposes the use of a truncated TCP header as shown in <xref
        target="trunc-tcp"></xref> to reduce the size of the LISP header.</t>

        <t><figure align="center" anchor="trunc-tcp"
            title="Truncated TCP Header">
            <artwork><![CDATA[TCP Header: 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Source Port          |       Destination Port        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Sequence Number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Acknowledgment Number                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Data |           |U|A|P|R|S|F|                               |
       | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
       |       |           |G|K|H|T|N|N|                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |         Urgent Pointer        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      (Optional) Options                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Truncated TCP Header: 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Sequence Number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Acknowledgment Number                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Data |           |U|A|P|R|S|F|                               |
       | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
       |       |           |G|K|H|T|N|N|                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      (Optional) Options                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t></t>
      </section>

      <section anchor="cformat" title="Compact LISP Header Format">
        <t>The compact LISP header for a TCP packet is shown in <xref
        target="ctcp"></xref>, while the compact LISP header for UDP is
        depicted in <xref target="cudp"></xref>.</t>

        <t><figure anchor="ctcp" title="Compact LISP Header Format (TCP Case)">
            <artwork><![CDATA[      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version| Traffic Class |           Flow Label                  |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Payload Length        | Next Header=17|   Hop Limit   |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 |   |                                                               | |
 I   +                Source Routing Locator (64 bits)               + |
 P   |                                                               | S
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
 H   |     u byte    |         Source EID ...                        | C
 E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 A   |     ....      |    Protocol   |  (Inner) Source Port          | |
 D   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 E   |                                                               | |
 R   +            Destination Routing Locator (64 bits)              + |
 |   |                                                               | D
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
 |   |     u byte    |          Destination EID ...                  | T
  \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   \ |     ....      |    00000000   |(Inner)Destination Port        | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   / |       Source Port = xxxx      |       Dest Port = 4341        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 L   |N|L|E|V|I|C|K|K|            Nonce/Map-Version                  |
 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 S / |                 Instance ID/Locator-Status-Bits               |
 P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Acknowledgment Number                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Data |           |U|A|P|R|S|F|                               |
     | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
     |       |           |G|K|H|T|N|N|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      (Optional) Options                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t><figure anchor="cudp" title="Compact LISP Header Format (UDP Case)">
            <artwork><![CDATA[      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version| Traffic Class |           Flow Label                  |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Payload Length        | Next Header=17|   Hop Limit   |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 |   |                                                               | |
 I   +                Source Routing Locator (64 bits)               + |
 P   |                                                               | S
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
 H   |     u byte    |         Source EID ...                        | C
 E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 A   |     ....      |    Protocol   |  (Inner) Source Port          | |
 D   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 E   |                                                               | |
 R   +            Destination Routing Locator (64 bits)              + |
 |   |                                                               | D
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
 |   |     u byte    |          Destination EID ...                  | T
  \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   \ |     ....      |    00000000   |(Inner)Destination Port        | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   / |       Source Port = xxxx      |       Dest Port = 4341        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 L   |N|L|E|V|I|C|K|K|            Nonce/Map-Version                  |
 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 S / |                 Instance ID/Locator-Status-Bits               |
 P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="LISP Encapsulation with the Compact Header Form">
      <t>Upon receipt of an IPv4 packet that needs to be forwarded over a
      LISP-enabled IPv6 infrastructure, the ITR proceeds as described in <xref
      target="uenc"></xref> for UDP packets and in <xref target="tenc"></xref>
      for TCP packets. <xref target="fenc"></xref> specifies how fragments are
      handled.<?rfc subcompact="yes" ?></t>

      <section anchor="uenc" title="UDP Packets">
        <t><list style="symbols">
            <t>Retrieve the destination/source RLOC IPv6 prefix.</t>

            <t>Concatenate the source RLOC IPv6 prefix, the u byte, the source
            IPv4 address, the "Protocol" as indicated in the IP header, and
            the source port number to form the source IPv6 address as
            specified in <xref target="emba"></xref> for non-fragmented
            packets and fragments that convey a transport header.</t>

            <t>Concatenate the destination RLOC IPv6 prefix, the u byte, the
            destination IPv4 address, a null octet, and the destination port
            number to form the destination IPv6 address as specified in <xref
            target="emba"></xref> for non-fragmented packets and fragments
            that convey a transport header.</t>

            <t>Remove both the IP and UDP headers of the original packet.</t>

            <t>Prepend the LISP header with the C-flag set (<xref
            target="cbit"></xref>).</t>

            <t>Prepend the UDP header.</t>

            <t>Prepend the IPv6 header.</t>
          </list></t>
      </section>

      <section anchor="tenc" title="TCP Packets">
        <t><list style="symbols">
            <t>Retrieve the destination/source RLOC IPv6 prefix.</t>

            <t>Concatenate the source RLOC IPv6 prefix, the u byte, the source
            IPv4 address, the "Protocol" as indicated in the IP header, and
            the source port number to form the source IPv6 address as
            specified in <xref target="emba"></xref> for non-fragmented
            packets and fragments that convey a transport header.</t>

            <t>Concatenate the destination RLOC IPv6 prefix, the u byte, the
            destination IPv4 address, a null octet, and the destination port
            number to form the destination IPv6 address as specified in <xref
            target="emba"></xref> for non-fragmented packets and fragments
            that convey a transport header.</t>

            <t>Remove the IP header, the first 4 bytes of the TCP header, and
            the 4 bytes right after the "window" field from the original TCP
            header (<xref target="trun"></xref>).</t>

            <t>Prepend the LISP header with the C-flag set (<xref
            target="cbit"></xref>).</t>

            <t>Prepend the UDP header.</t>

            <t>Prepend the IPv6 header.</t>
          </list></t>
      </section>

      <section anchor="fenc" title="Fragments">
        <t><list style="symbols">
            <t>Retrieve the destination/source RLOC IPv6 prefix.</t>

            <t>Concatenate the source RLOC IPv6 prefix, the u byte, the source
            IPv4 address, and 3 bytes the "Protocol" as indicated in the IP
            header, and 2 bytes paddings of "1".</t>

            <t>Concatenate the destination RLOC IPv6 prefix, the u byte, the
            destination IPv4 address, and 3 bytes paddings of "1".</t>

            <t>Remove both the IP header of the original packet.</t>

            <t>Prepend the LISP header with the C-flag set (<xref
            target="cbit"></xref>).</t>

            <t>Prepend the UDP header.</t>

            <t>Prepend the IPv6 header.</t>
          </list><?rfc subcompact="no" ?></t>
      </section>
    </section>

    <section title="LISP Decapsulation with the Compact LISP Header">
      <t>Upon receipt of a LISP packet with the C-bit set, the ETR proceeds as
      follows to extract the inner IP packets (<xref target="dudp"></xref> for
      UDP and <xref target="dtcp"></xref> for TCP).</t>

      <t>The processing of the other flag bits is not detailed in this
      specification. Other than encoding RLOCs as prefixes, the behavior
      defined in <xref target="RFC6830"></xref> is not impacted by this
      specification.</t>

      <t>Obviously if the C-bit is unset, xTR routers follow the behavior
      defined in <xref target="RFC6830"></xref>.</t>

      <t>The UDP checksum setting and validation of LISP-encapsulated packets
      MUST follow the guidelines documented in Section 5.3 of <xref
      target="RFC6830"></xref>.</t>

      <t><?rfc subcompact="yes" ?></t>

      <section anchor="dudp" title="Build an IPv4/UDP Header">
        <t><list style="symbols">
            <t>Check whether the destination IPv6 address matches an RLOC
            prefix owned by the xTR.</t>

            <t>Extract the Source EID that is encoded in positions 72 to 103
            of the Source IPv6 address.</t>

            <t>Extract the "Protocol" field that is encoded in positions 104
            to 111 of the Source IPv6 address. This value is used to set the
            corresponding field in the IPv4 header of the de-capsulated
            packet.</t>

            <t>Extract the Source Port that is encoded in positions 112 to 127
            of the Source IPv6 address, for non-fragmented packets and
            fragments that convey a transport header.</t>

            <t>Extract the Destination EID that is encoded in positions 72 to
            103 of the Destination IPv6 address.</t>

            <t>Extract the Destination Port that is encoded in positions 112
            to 127 of the Destination IPv6 address, for non-fragmented packets
            and fragments that convey a transport header.</t>

            <t>Remove the IPv6 header, the UDP header, and the LISP
            header.</t>

            <t>Use the extracted Source Port and Destination Port to build the
            UDP header. Prepend the new UDP header.</t>

            <t>Use the extracted Source IP address, Destination IP address,
            and Protocol to build the IPv4 header.</t>

            <t>Prepend the new IPv4 header.</t>
          </list></t>
      </section>

      <section anchor="dtcp" title="Build an IPv4/TCP Header">
        <t><list style="symbols">
            <t>Check whether the destination IPv6 address matches an RLOC
            prefix owned by the xTR.</t>

            <t>Extract the Source EID that is encoded in positions 72 to 103
            of the Source IPv6 address.</t>

            <t>Extract the "Protocol" field that is encoded in positions 104
            to 111 of the Source IPv6 address. This value is used to set the
            corresponding field in the IPv4 header of the de-capsulated
            packet.</t>

            <t>Extract the Source Port that is encoded in positions 112 to 127
            of the Source IPv6 address, for non-fragmented packets and
            fragments that convey a transport header.</t>

            <t>Extract the Destination EID that is encoded in positions 72 to
            103 of the Destination IPv6 address.</t>

            <t>Extract the Destination Port that is encoded in positions 112
            to 127 of the Destination IPv6 address, for non-fragmented packets
            and fragments that convey a transport header.</t>

            <t>Remove the IPv6 header, UDP header, and LISP header.</t>

            <t>For non-fragmented packets and fragments that convey a
            transport header, prepend 4 bytes with the source/destination port
            number and insert 4 bytes right after the "window" field to build
            a proper TCP header. The extracted Source Port and Destination
            Port are used in this step.</t>

            <t>Prepend an IPv4 header. Use the extracted Source IP address,
            Destination IP address, and Protocol to build the IPv4 header.</t>
          </list><?rfc subcompact="no" ?></t>
      </section>
    </section>

    <section anchor="cc" title="A More Compact LISP Encapsulation Flavor">
      <t>A more compact LISP encapsulation scheme can be considered if the
      following conditions are met:<?rfc subcompact="yes" ?></t>

      <t><list style="symbols">
          <t>Compatibility with "u" byte is not required.</t>

          <t>The origin "Source Port" number is copied into the UDP header of
          the encapsulated packet, and vice versa.</t>

          <t>The LISP shim is split into two parts: 4 bytes that are placed
          right after the UDP header while "Instance ID/Locator-Status-Bits"
          are encoded in the last 32 bits of the source IPv4-embedded IPv6
          RLOC.</t>
        </list></t>

      <t><?rfc subcompact="no" ?>This alternate proposal leads to a 4-byte
      overhead when transporting IPv4-over-IPv6 LISP packets for both TCP
      (<xref target="ctcp2"></xref>) and UDP (<xref
      target="cudp2"></xref>).</t>

      <t><figure anchor="ctcp2"
          title="More Compacted LISP Header Format (TCP Case)">
          <artwork><![CDATA[      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version| Traffic Class |           Flow Label                  |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Payload Length        | Next Header=17|   Hop Limit   |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 |   |                                                               | |
 I   +                Source Routing Locator (64 bits)               + |
 P   |                                                               | S
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
 H   |                         Source EID                            | C
 E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 A   |                 Instance ID/Locator-Status-Bits               | |
 D   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 E   |                                                               | |
 R   +            Destination Routing Locator (64 bits)              + |
 |   |                                                               | D
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
 |   |                     Destination EID                           | T
  \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   \ |    00000000   |(Inner)Protocol|(Inner)Destination Port        | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   / | Source Port = Inner Src Port  |       Dest Port = 4341        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 I | |N|L|E|V|I|C|K|K|            Nonce/Map-Version                  |
 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 P   |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Acknowledgment Number                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Data |           |U|A|P|R|S|F|                               |
     | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
     |       |           |G|K|H|T|N|N|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      (Optional) Options                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t><figure anchor="cudp2"
          title="More Compacted LISP Header Format (UDP Case)">
          <artwork><![CDATA[      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   / |Version| Traffic Class |           Flow Label                  |
  /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   |         Payload Length        | Next Header=17|   Hop Limit   |
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 |   |                                                               | |
 I   +                Source Routing Locator (64 bits)               + |
 P   |                                                               | S
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
 H   |                         Source EID                            | C
 E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 A   |                 Instance ID/Locator-Status-Bits               | |
 D   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
 E   |                                                               | |
 R   +            Destination Routing Locator (64 bits)              + |
 |   |                                                               | D
 |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S
 |   |                     Destination EID                           | T
  \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   \ |    00000000   |(Inner)Protocol|(Inner)Destination Port        | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   / | Source Port = Inner Src Port  |       Dest Port = 4341        |
 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \ |           UDP Length          |        UDP Checksum           |
 L \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 I | |N|L|E|V|I|C|K|K|            Nonce/Map-Version                  |
 S / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 P   ]]></artwork>
        </figure></t>

      <section title="LISP Encapsulation with the More Compact Header Form">
        <t>Upon receipt of an IPv4 packet that needs to be forwarded over a
        LISP-enabled infrastructure, the ITR proceeds as follows:<?rfc subcompact="yes" ?></t>

        <section title="UDP Packets">
          <t><list style="symbols">
              <t>Retrieve the destination/source RLOC IPv6 prefix.</t>

              <t>Concatenate the source RLOC IPv6 prefix, the source IPv4
              address, and the "Instance ID/Locator-Status-Bits" to form the
              source IPv6 address as shown in <xref
              target="cudp2"></xref>.</t>

              <t>Concatenate the destination RLOC IPv6 prefix, the destination
              IPv4 address, a null octet, the "Protocol" as indicated in the
              IP header, and the destination port number to form the
              destination IPv6 address as shown in <xref
              target="cudp2"></xref>, for non-fragmented packets and fragments
              that convey a transport header.</t>

              <t>Remove the IPv4 header.</t>

              <t>Set the destination port number of the UDP header to
              4341.</t>

              <t>Insert the LISP header right after the UDP header; the C-flag
              must be set (<xref target="cbit"></xref>).</t>

              <t>Prepend the IPv6 header.</t>
            </list></t>
        </section>

        <section title="TCP Packets">
          <t><list style="symbols">
              <t>Retrieve the destination/source RLOC IPv6 prefix.</t>

              <t>Concatenate the source RLOC IPv6 prefix, the source IPv4
              address, and the "Instance ID/Locator-Status-Bits" to form the
              source IPv6 address as shown in <xref
              target="ctcp2"></xref>.</t>

              <t>Concatenate the destination RLOC IPv6 prefix, the destination
              IPv4 address, a null octet, the "Protocol" as indicated in the
              IP header, and the destination port number to form the
              destination IPv6 address as shown in <xref
              target="ctcp2"></xref>, for non-fragmented packets and fragments
              that convey a transport header.</t>

              <t>Remove the IPv4 header.</t>

              <t>Remove the first 4 bytes and the 4 bytes right after the
              "window" field of the TCP header (<xref
              target="trun"></xref>).</t>

              <t>Prepend the LISP header; the C-flag must be set (<xref
              target="cbit"></xref>)..</t>

              <t>Prepend the UDP header. Set to the source port number to the
              same port indicated in the original TCP header. Set the
              destination port number of the UDP header to 4341.</t>

              <t>Prepend an IPv6 header.</t>
            </list></t>
        </section>

        <section title="Fragments">
          <t><list style="symbols">
              <t>Retrieve the destination/source RLOC IPv6 prefix.</t>

              <t>Concatenate the source RLOC IPv6 prefix, the source IPv4
              address, and the "Instance ID/Locator-Status-Bits" to form the
              source IPv6 address as shown in <xref
              target="cudp2"></xref>.</t>

              <t>Concatenate the destination RLOC IPv6 prefix, the destination
              IPv4 address, a non-null octet, the "Protocol" as indicated in
              the IP header, and a null octet padding to form the destination
              IPv6 address.</t>

              <t>Remove the IPv4 header.</t>

              <t>Insert the LISP header.</t>

              <t>Insert the UDP header with a destination port number set to
              4341.</t>

              <t>Prepend the IPv6 header.</t>
            </list><?rfc subcompact="no" ?></t>
        </section>
      </section>

      <section title="LISP Decapsulation with the More Compact LISP Header">
        <t>Upon receipt of a LISP packet with the C-bit set, the ETR proceeds
        as follows to extract the inner IP packets: (<xref
        target="cudp2"></xref> for UDP and <xref target="ctcp2"></xref> for
        TCP). Like in <xref target="comp"></xref>, the UDP checksum setting
        and validation of LISP-encapsulated packets MUST follow the guidelines
        documented in Section 5.3 of <xref target="RFC6830"></xref>.<?rfc subcompact="yes" ?></t>

        <section anchor="eudp2" title="Build an IPv4/UDP Header">
          <t><list style="symbols">
              <t>Check whether the destination IPv6 address matches an RLOC
              prefix owned by the xTR.</t>

              <t>Extract the Source EID that is encoded in positions 64 to 95
              of the Source IPv6 address.</t>

              <t>Extract the "Instance ID/Locator-Status-Bits" field that is
              encoded in positions 96 to 127 of the Source IPv6 address.</t>

              <t>Extract the Destination EID that is encoded in positions 64
              to 95 of the Destination IPv6 address.</t>

              <t>Extract the "Protocol" that is encoded in positions 104 to
              111 of the Destination IPv6 address.</t>

              <t>Extract the Destination Port that is encoded in positions 112
              to 127 of the Destination IPv6 address if the octet in positions
              96 to 103 is not null.</t>

              <t>Remove the IPv6 header, the UDP header, and the LISP
              header.</t>

              <t>For non-fragmented packets and fragments that convey a
              transport header, use the extracted Source Port and Destination
              Port to build the UDP header. Prepend the new UDP header.</t>

              <t>Use the extracted Source IPv4 address, Destination IPv4
              address, and Protocol to build the IPv4 header. Prepend the new
              IPv4 header.</t>
            </list></t>
        </section>

        <section anchor="etcp2" title="Build an IPv4/TCP Header">
          <t><list style="symbols">
              <t>Check whether the destination IPv6 address matches an RLOC
              prefix owned by the xTR.</t>

              <t>Extract the Source EID that is encoded in positions 64 to 95
              of the Source IPv6 address.</t>

              <t>Extract the "Instance ID/Locator-Status-Bits" field that is
              encoded in positions 96 to 127 of the Source IPv6 address.</t>

              <t>Extract the Destination EID that is encoded in positions 64
              to 95 of the Destination IPv6 address.</t>

              <t>Extract the "Protocol" that is encoded in positions 104 to
              111 of the Destination IPv6 address.</t>

              <t>Extract the Destination Port that is encoded in positions 112
              to 127 of the Destination IPv6 address if the octet in positions
              96 to 103 is not null.</t>

              <t>Check whether the destination IPv6 address matches an RLOC
              prefix owned by the xTR.</t>

              <t>Remove the IPv6 header, UDP header, and LISP header.</t>

              <t>For non-fragmented packets and fragments that convey a
              transport header, prepend 4 bytes with the source/destination
              port number and insert 4 bytes right after the "window" field to
              build a proper TCP header. The extracted Source Port and
              Destination Port are used during this step.</t>

              <t>Prepend an IPv4 header. Use the extracted Source IP address,
              Destination IP address, and Protocol to build the IPv4
              header.</t>
            </list><?rfc subcompact="no" ?></t>
        </section>
      </section>
    </section>

    <section title="Discussion">
      <t>The proposed compact headers are experimental. What primarily
      motivates this specification is the need to assess its technical
      feasibility thanks to an existing LISP-enabled platform. Experiments
      will help evaluate the gain brought by using such compact headers
      compared to base LISP encapsulation scheme in typical IPv6 migration
      scenarios</t>

      <t>The proposed compact encapsulation schemes guarantee a functional
      parity with the base LISP specification, given that the signalling
      carried in a LISP packet remains usable.</t>

      <t>This specification does not include any capability checks to ensure
      that remote xTRs support the proposed header encoding. Particularly,
      deployability considerations in multi-domain LISP environments are not
      detailed in this document.</t>

      <t>This specification assumes that a configuration parameter should be
      supported by LISP implementations to tweak the encapsulation scheme to
      be used.</t>

      <t>The handling of fragmented packets by an ETR follows the same steps
      as in <xref target="comp"></xref> except that, for the fragments that do
      not carry the source/destination port numbers, a non-null octet of the
      "suffix" defined <xref target="emb"></xref> is used to signal that the
      LISP-encapsulated packet is a fragment that does not convey
      transport-related information.</t>
    </section>

    <section title="Security Considerations">
      <t>The security considerations discussed in Section 12 of<xref
      target="RFC6830"> </xref> are valid for this document.</t>

      <t>Security considerations related to building an IPv4-embedded IPv6
      address are discussed in <xref target="RFC6052"></xref>.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document does not make any request to IANA.</t>
    </section>

    <section title="Acknowledgments">
      <t>This work is partly funded by ANR LISP-Lab project
      #ANR-13-INFR-009-X.</t>

      <t>Many thanks to S. Secci, L. Iannone, and J. Saldana for the review
      and comments.</t>

      <t>The gain ratio table is a courtesy of J. Saldana.</t>
    </section>
  </middle>

  <back>
    <references title="Normative references">
      <?rfc include='reference.RFC.6830'
?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.6052'?>

      <?rfc include='reference.RFC.0793'?>

      <?rfc include='reference.RFC.0768'?>

      <?rfc include='reference.RFC.8061'?>
    </references>
  </back>
</rfc>
