<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0768 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4340 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4787 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5596 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5596.xml">
<!ENTITY RFC5597 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5597.xml">
<!ENTITY RFC6773 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6773.xml">
<!ENTITY RFC6888 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6888.xml">
<!ENTITY RFC7857 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7857.xml">
]>
<rfc submissionType="IETF" docName="draft-amend-tsvwg-dccp-udp-header-conversion-01" category="exp">
  <!-- Generated by id2xml 1.4.4 on 2019-05-17T06:10:33Z -->
  <?rfc compact="yes"?>
  <?rfc text-list-symbols="o*+-"?>
  <?rfc subcompact="no"?>
  <?rfc sortrefs="yes"?>
  <?rfc symrefs="yes"?>
  <?rfc strict="yes"?>
  <?rfc toc="yes"?>
  <front>
    <title abbrev="DCCP - UDP header conversion">Lossless and overhead free DCCP - UDP header conversion (U-DCCP)</title>
    <author fullname="Markus Amend" initials="M." surname="Amend">
      <organization>Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Deutsche-Telekom-Allee 7</street>
          <street>64295 Darmstadt</street>
          <street>Germany</street>
        </postal>
        <email>Markus.Amend@telekom.de</email>
      </address>
    </author>
    <author fullname="Anna Brunstrom" initials="A." surname="Brunstrom">
      <organization>Karlstad University</organization>
      <address>
        <postal>
          <street>Universitetsgatan 2</street>
          <street>651 88 Karlstad</street>
          <street>Sweden</street>
        </postal>
        <email>anna.brunstrom@kau.se</email>
      </address>
    </author>
    <author fullname="Andreas Kassler" initials="A." surname="Kassler">
      <organization>Karlstad University</organization>
      <address>
        <postal>
          <street>Universitetsgatan 2</street>
          <street>651 88 Karlstad</street>
          <street>Sweden</street>
        </postal>
        <email>andreas.kassler@kau.se</email>
      </address>
    </author>
    <author fullname="Veselin Rakocevic" initials="V." surname="Rakocevic">
      <organization>City University of London</organization>
      <address>
        <postal>
          <street>Northampton Square</street>
          <street>London</street>
          <street>United Kingdom</street>
        </postal>
        <email>veselin.rakocevic.1@city.ac.uk</email>
      </address>
    </author>
    <date day="08" month="July" year="2019"/>
    <workgroup>Transport Area Working Group</workgroup>
    <abstract>
      <t>
   The Datagram Congestion Control Protocol (DCCP) is a transport-layer protocol that provides upper layers with the ability to use non-reliable congestion-controlled flows. DCCP is not widely deployed in the Internet, and the reason for that can be defined as a typical example of a chicken-egg problem. Even if an application developer decided to use DCCP, the middle-boxes like firewalls and NATs would prevent DCCP end-to-end since they lack support for DCCP. Moreover, as long as the protocol penetration of DCCP does not increase, the middle-boxes will not handle DCCP properly. To overcome this challenge, NAT/NATP traversal and UDP encapsulation for DCCP is already defined. However, the former requires special middle-box support and the latter introduces overhead. The recent proposal of a multipath extension for DCCP further underlines the challenge of efficient middle-box passing as its main goal is to be applied over the Internet, traversing numerous uncontrolled middle-boxes. This document introduces a new solution which disguises DCCP during transmission as UDP without requiring middle-box modification or introducing any overhead.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="section-1">
      <t>
   The Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340"/> is a transport-layer protocol that provides upper layers with the ability  to use non-reliable congestion-controlled flows. The current specification for DCCP <xref target="RFC4340"/> specifies a direct native encapsulation in IPv4 or IPv6 packets.</t>
      <t>
   DCCP support has been specified for devices that use Network Address Translation (NAT) or Network Address and Port Translation (NAPT) <xref target="RFC5597"/>. However, there is a significant installed base of NAT/NAPT devices that do not support <xref target="RFC5597"/>.  An UDP encapsulation for DCCP <xref target="RFC6773"/> circumvents such limitations and makes DCCP compatible with any UDP <xref target="RFC0768"/> compliant device that supports <xref target="RFC4787"/> but does not support <xref target="RFC5597"/>. For convenience, the standard encapsulation for DCCP <xref target="RFC4340"/> (including <xref target="RFC5596"/> and <xref target="RFC5597"/> as required) is referred to as DCCP-STD, whereas the UDP encapsulation for DCCP <xref target="RFC6773"/> is referred to as DCCP-UDP.</t>
      <t>
   It can be stated that DCCP-STD and DCCP-UDP are techniques which increase the success rate of DCCP transmissions significantly. However, DCCP-STD fails on devices that block DCCP for any reasons. On the other hand, DCCP-UDP uses the well-accepted UDP to let devices assume they are handling the UDP protocol, but at the cost of a reduced goodput/throughput ratio.</t>
      <t>
   To compensate for the inefficiency of DCCP-STD (device blocking) and DCCP-UDP (overhead), this document proposes a beneficial modification scheme relying on UDP (like DCCP-UDP), but with no overhead.  This goal is reached by re-arranging DCCP's extended header to make it look like UDP, without losing critical information. This solution is referred to as U-DCCP.</t>
      <t>
   U-DCCP is limited to DCCP's extended header, requiring X is set to 1. Otherwise U-DCCP relies on the NAT/NATP functionalities specified for UDP in <xref target="RFC4787"/>, <xref target="RFC6888"/> and <xref target="RFC7857"/>.</t>
    </section>
    <section title="Terminology" anchor="section-2">
      <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"/>.</t>
    </section>
    <section title="U-DCCP" anchor="section-3">
      <section title="Overview" anchor="section-3.1">
        <t>
   The basic approach of U-DCCP is to modify the extended header of a DCCP packet so that it appears like UDP <xref target="RFC0768"/>. In particular, this takes place without losing any header information, but requires a U-DCCP termination before the packet is delivered to the DCCP end system .  This method does not change the 4-tuple of IP and port addressing, however it changes the protocol carried over IP from DCCP to UDP.  As a consequence, the length of the packet remains unchanged and behaves like DCCP-STD. The solution is not a tunneling approach. It requires that the same port used by DCCP can be used by UDP.</t>
        <t>
   The method is designed to support use when the IP addresses are modified by a device that implements NAT/NAPT.  A NAT translates the IP addresses, which impacts the transport-layer checksum. A NAPT device may also translate the port values (usually the source port). In both cases, the outer transport header that includes these values would need to be updated by the NAT/NAPT.</t>
        <t>
   U-DCCP supports IPv4 and IPv6.</t>
        <t>
   The basic format of a U-DCCP packet is:</t>
        <figure title="Format of U-DCCP packet" anchor="ref-format-of-u-dccp-packet">
          <artwork><![CDATA[
+-----------------------------------+
|     IP Header (IPv4 or IPv6)      |  Variable length
+-----------------------------------+
|UDP like arranged DCCP ext. Header |  8 bytes \
+-----------------------------------+           ) U-DCCP header
|Rest of rearranged DCCP ext. Header|  8 bytes /
+-----------------------------------+
| Additional (type-specific) Fields |  Variable length (could be 0)
+-----------------------------------+
|           DCCP Options            |  Variable length (could be 0)
+-----------------------------------+
|      Application Data Area        |  Variable length (could be 0)
+-----------------------------------+
]]></artwork>
        </figure>
        <t>
   The U-DCCP header is described in <xref target="section-3.4"/> after introducing the traditional DCCP header in <xref target="section-3.1"/> and its target appearance of a UDP header in <xref target="section-3.2"/>.  <xref target="section-3.3"/> discusses considerations for building the U-DCCP header upfront.</t>
      </section>
      <section title="The DCCP Generic header" anchor="section-3.2">
        <t>
   The DCCP Generic Header <xref target="RFC4340"/> takes two forms: one with long
   sequence numbers (48 bits) and the other with short sequence numbers
   (24 bits). The short one is not part of U-DCCP's modification.</t>
        <figure title="The extended DCCP Header with Long Sequence Numbers [RFC4340]" anchor="ref-the-extended-dccp-header-with-long-sequence-numbers-rfc4340">
          <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Source Port          |           Dest Port           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Data Offset  | CCVal | CsCov |           Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     |       |X|               |                               .
  | Res | Type  |=|   Reserved    |  Sequence Number (high bits)  .
  |     |       |1|               |                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Sequence Number (low bits)                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <figure title="The short DCCP Header with Short Sequence Numbers [RFC4340]" anchor="ref-the-short-dccp-header-with-short-sequence-numbers-rfc4340">
          <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Source Port          |           Dest Port           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Data Offset  | CCVal | CsCov |           Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     |       |X|                                               |
  | Res | Type  |=|   Sequence Number (low bits)                  |
  |     |       |0|                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
   All generic header fields have the meaning specified in <xref target="RFC4340"/>, updated by <xref target="RFC5596"/>.</t>
      </section>
      <section title="UDP header" anchor="section-3.3">
        <figure title="The UDP Header [RFC768]" anchor="ref-the-udp-header-rfc768">
          <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Source Port          |           Dest Port           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Length            |           Checksum            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
   All header fields have the meaning specified in <xref target="RFC0768"/>.</t>
      </section>
      <section title="U-DCCP conversion considerations" anchor="section-3.4">
        <t>
   The U-DCCP header has the goal to merge the information of DCCP's extended header (<xref target="section-3.1"/>) and imitates in the first 64 bits the UDP header (<xref target="section-3.2"/>). Information required to restore a DCCP header from any conversion, which must not be lost, includes: source and destination port, Data Offset, CCVal, CsCov, Checksum, Type, X and the Sequence Number.</t>
        <t>
   Compared with the UDP header, the DCCP extented header shows similarities in source and destination port and checksum. The length field of UDP (bits 33-48) is not part of the DCCP header and contains in case of DCCP the fields Data Offset, CCVal and CsCov.</t>
        <t>
   For the goal of imitating UDP, the checksum must cover the whole datagram, which renders any limitation by CsCov useless. The checksum itself is required to re-calculate after conversion anyway.</t>
        <t>
   If the conversion is limited to DCCP'S extended header only, X is always "1".</t>
        <t>
   Thus, Data Offset, CCVal, Type and Sequence Number must be re-arranged in a way that the Length field of UDP can be applied.</t>
      </section>
      <section title="U-DCCP header" anchor="section-3.5">
        <t>
   The considerations of <xref target="section-3.3"/> leads to the following header, denoted as U-DCCP header.</t>
        <figure title="The U-DCCDP Header" anchor="ref-the-u-dccdp-header">
          <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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U  |          Source Port          |           Dest Port           |
D  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P  |          Length               |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type  | CCVal |  Data Offset  |  Sequence Number (high bits)  .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                  Sequence Number (low bits)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>
   The first 8 bytes of the U-DCCP header corresponds to <xref target="RFC0768"/> and the fields are interpreted as follows:</t>
        <t>
   Source and Dest(ination) Ports: 16 bits each</t>
        <t>
   These fields identify the UDP ports used by the source and destination (respectively) of the packet to listen for incoming UDP packets. The UDP port values identify the DCCP source and destination ports.</t>
        <t>
   Length: 16 bits</t>
        <t>
   This field is the length of the UDP datagram, including the UDP header and the payload (for U-DCCP, the payload comprises the payload of the original DCCP datagram and part of its header).</t>
        <t>
   Checksum: 16 bits</t>
        <t>
   This field is the Internet checksum of a network-layer pseudoheader and Length bytes of the UDP packet <xref target="RFC0768"/>. The UDP checksum MUST NOT be zero for a U-DCCP packet.</t>
        <t>
   The remaining 8 bytes of the U-DCCP header contains:</t>
        <t>
   Type, CCVal, Data Offset, Seq. Number: As specified in <xref target="RFC4340"/></t>
        <t>
   In case U-DCCP is applied, the IP layer must be instructed to carry an UDP datagram and its checksum must be re-calculated. For detailed information see <xref target="section-3.7"/>.</t>
      </section>
      <section title="Implementation" anchor="section-3.6">
        <t>
   The process of applying U-DCCP is defined as follows:</t>
        <t>
   DCCP generation -&gt; U-DCCP conversion -&gt; UDP transmission -&gt; U-DCCP reception and restoration -&gt; DCCP reception</t>
        <t>
   The conversion can be integrated into DCCP endpoints directly or as an additional component on the way along the transmission route. Depending on the degree of integration, especially the process of checksum calculation and validation can be optimized. <xref target="section-3.7"/> and <xref target="section-3.8"/> provide a possible pseudo-code for the conversion without any optimized integration into the sender's network stack or into the receiver's network stack. The pseudo-code assumes explicit knowledge on which U-DCCP flows need conversion between the sender and the receiver.</t>
      </section>
      <section title="Pseudo-code DCCP to U-DCCP conversion" anchor="section-3.7">
        <t>
   A possible processing of an already generated DCCP datagram for
   U-DCCP conversion:</t>
        <t>
          <list style="numbers">
            <t> Receive DCCP datagram.</t>
            <t> Check eligibility for conversion; otherwise bypass conversion.</t>
            <t> Verify consistency, e.g. checksum; otherwise drop.</t>
            <t> Shift Type and CCVal field to the ninth octet.</t>
            <t> Shift Data Offset field to the tenth octet.</t>
            <t> Place a length information at octet 5+6 corresponding to
        <xref target="RFC0768"/>.</t>
            <t> Modify the IP header's encapsulated protocol from DCCP to UDP.</t>
            <t> Re-calculate IP header checksum.</t>
            <t> Reset DCCP checksum field: octet 7+8 = 0.</t>
            <t> Generate new checksum at octet 7+8 as described in <xref target="RFC0768"/>.</t>
            <t>Forward to destination based on the unmodified 4-tuple of IP-addresses and ports.</t>
          </list>
        </t>
      </section>
      <section title="Pseudo-code U-DCCP to DCCP restoration" anchor="section-3.8">
        <t>
   A possible processing of an already converted U-DCCP datagram for
   DCCP restoration:</t>
        <t>
          <list style="numbers">
            <t> Receive UDP datagram.</t>
            <t> Check eligibility for restoration; otherwise bypass restoration</t>
            <t> Validate UDP checksum; otherwise drop.</t>
            <t> Restore Data Offset field according to <xref target="RFC4340"/>.</t>
            <t> Restore CCVal field according to <xref target="RFC4340"/>.</t>
            <t> Set CsCov field according to <xref target="RFC4340"/> to "0".</t>
            <t> Restore Type field according to <xref target="RFC4340"/>.</t>
            <t> Set Reserved bits according to <xref target="RFC4340"/> to "0".</t>
            <t> Set X according to <xref target="RFC4340"/> to "1".</t>
            <t> Modify the IP header's encapsulated protocol from UDP to DCCP.</t>
            <t> Re-calculate IP header checksum.</t>
            <t> Reset DCCP checksum field: octet 7+8 = 0.</t>
            <t> Generate new checksum at octet 7+8 as described in <xref target="RFC0768"/>.</t>
            <t>Forward to destination based on the unmodified 4-tuple of IP-addresses and ports.</t>
          </list>
        </t>
      </section>
      <section title="U-DCCP negotiation (required????)" anchor="section-3.9">
        <t>
   Tbd later if required.  Otherwise assumes explicit knowledge about the U-DCCP conversion between sender and receiver.</t>
      </section>
    </section>
    <section title="Security Considerations" anchor="section-4">
      <t>
   TBD.</t>
    </section>
    <section title="IANA Considerations" anchor="section-5"/>
    <section title="Notes" anchor="section-6">
      <t>
   This document is inspired by <xref target="RFC6773"/> and some text passages for the -00 version are copied unmodified.</t>
    </section>
    <section title="Acknowledgments" anchor="section-7"/>
  </middle>
  <back>
    <references title="Informative References">
	&RFC0768;
	&RFC2119;
	&RFC4340;
	&RFC4787;
	&RFC5596;
	&RFC5597;
	&RFC6773;
	&RFC6888;
	&RFC7857;
	</references>
  </back>
</rfc>
