idnits 2.17.00 (12 Aug 2021) /tmp/idnits46312/draft-amend-tsvwg-dccp-udp-header-conversion-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 (July 08, 2019) is 1041 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC768' is mentioned on line 227, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Amend 3 Internet-Draft Deutsche Telekom 4 Intended status: Experimental A. Brunstrom 5 Expires: January 9, 2020 A. Kassler 6 Karlstad University 7 V. Rakocevic 8 City University of London 9 July 08, 2019 11 Lossless and overhead free DCCP - UDP header conversion (U-DCCP) 12 draft-amend-tsvwg-dccp-udp-header-conversion-01 14 Abstract 16 The Datagram Congestion Control Protocol (DCCP) is a transport-layer 17 protocol that provides upper layers with the ability to use non- 18 reliable congestion-controlled flows. DCCP is not widely deployed in 19 the Internet, and the reason for that can be defined as a typical 20 example of a chicken-egg problem. Even if an application developer 21 decided to use DCCP, the middle-boxes like firewalls and NATs would 22 prevent DCCP end-to-end since they lack support for DCCP. Moreover, 23 as long as the protocol penetration of DCCP does not increase, the 24 middle-boxes will not handle DCCP properly. To overcome this 25 challenge, NAT/NATP traversal and UDP encapsulation for DCCP is 26 already defined. However, the former requires special middle-box 27 support and the latter introduces overhead. The recent proposal of a 28 multipath extension for DCCP further underlines the challenge of 29 efficient middle-box passing as its main goal is to be applied over 30 the Internet, traversing numerous uncontrolled middle-boxes. This 31 document introduces a new solution which disguises DCCP during 32 transmission as UDP without requiring middle-box modification or 33 introducing any overhead. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 9, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. U-DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3.2. The DCCP Generic header . . . . . . . . . . . . . . . . . 4 73 3.3. UDP header . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.4. U-DCCP conversion considerations . . . . . . . . . . . . 6 75 3.5. U-DCCP header . . . . . . . . . . . . . . . . . . . . . . 6 76 3.6. Implementation . . . . . . . . . . . . . . . . . . . . . 7 77 3.7. Pseudo-code DCCP to U-DCCP conversion . . . . . . . . . . 7 78 3.8. Pseudo-code U-DCCP to DCCP restoration . . . . . . . . . 8 79 3.9. U-DCCP negotiation (required????) . . . . . . . . . . . . 9 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 84 8. Informative References . . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 90 transport-layer protocol that provides upper layers with the ability 91 to use non-reliable congestion-controlled flows. The current 92 specification for DCCP [RFC4340] specifies a direct native 93 encapsulation in IPv4 or IPv6 packets. 95 DCCP support has been specified for devices that use Network Address 96 Translation (NAT) or Network Address and Port Translation (NAPT) 98 [RFC5597]. However, there is a significant installed base of NAT/ 99 NAPT devices that do not support [RFC5597]. An UDP encapsulation for 100 DCCP [RFC6773] circumvents such limitations and makes DCCP compatible 101 with any UDP [RFC0768] compliant device that supports [RFC4787] but 102 does not support [RFC5597]. For convenience, the standard 103 encapsulation for DCCP [RFC4340] (including [RFC5596] and [RFC5597] 104 as required) is referred to as DCCP-STD, whereas the UDP 105 encapsulation for DCCP [RFC6773] is referred to as DCCP-UDP. 107 It can be stated that DCCP-STD and DCCP-UDP are techniques which 108 increase the success rate of DCCP transmissions significantly. 109 However, DCCP-STD fails on devices that block DCCP for any reasons. 110 On the other hand, DCCP-UDP uses the well-accepted UDP to let devices 111 assume they are handling the UDP protocol, but at the cost of a 112 reduced goodput/throughput ratio. 114 To compensate for the inefficiency of DCCP-STD (device blocking) and 115 DCCP-UDP (overhead), this document proposes a beneficial modification 116 scheme relying on UDP (like DCCP-UDP), but with no overhead. This 117 goal is reached by re-arranging DCCP's extended header to make it 118 look like UDP, without losing critical information. This solution is 119 referred to as U-DCCP. 121 U-DCCP is limited to DCCP's extended header, requiring X is set to 1. 122 Otherwise U-DCCP relies on the NAT/NATP functionalities specified for 123 UDP in [RFC4787], [RFC6888] and [RFC7857]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. U-DCCP 133 3.1. Overview 135 The basic approach of U-DCCP is to modify the extended header of a 136 DCCP packet so that it appears like UDP [RFC0768]. In particular, 137 this takes place without losing any header information, but requires 138 a U-DCCP termination before the packet is delivered to the DCCP end 139 system . This method does not change the 4-tuple of IP and port 140 addressing, however it changes the protocol carried over IP from DCCP 141 to UDP. As a consequence, the length of the packet remains unchanged 142 and behaves like DCCP-STD. The solution is not a tunneling approach. 143 It requires that the same port used by DCCP can be used by UDP. 145 The method is designed to support use when the IP addresses are 146 modified by a device that implements NAT/NAPT. A NAT translates the 147 IP addresses, which impacts the transport-layer checksum. A NAPT 148 device may also translate the port values (usually the source port). 149 In both cases, the outer transport header that includes these values 150 would need to be updated by the NAT/NAPT. 152 U-DCCP supports IPv4 and IPv6. 154 The basic format of a U-DCCP packet is: 156 +-----------------------------------+ 157 | IP Header (IPv4 or IPv6) | Variable length 158 +-----------------------------------+ 159 |UDP like arranged DCCP ext. Header | 8 bytes \ 160 +-----------------------------------+ ) U-DCCP header 161 |Rest of rearranged DCCP ext. Header| 8 bytes / 162 +-----------------------------------+ 163 | Additional (type-specific) Fields | Variable length (could be 0) 164 +-----------------------------------+ 165 | DCCP Options | Variable length (could be 0) 166 +-----------------------------------+ 167 | Application Data Area | Variable length (could be 0) 168 +-----------------------------------+ 170 Figure 1: Format of U-DCCP packet 172 The U-DCCP header is described in Section 3.4 after introducing the 173 traditional DCCP header in Section 3.1 and its target appearance of a 174 UDP header in Section 3.2. Section 3.3 discusses considerations for 175 building the U-DCCP header upfront. 177 3.2. The DCCP Generic header 179 The DCCP Generic Header [RFC4340] takes two forms: one with long 180 sequence numbers (48 bits) and the other with short sequence numbers 181 (24 bits). The short one is not part of U-DCCP's modification. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Source Port | Dest Port | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Data Offset | CCVal | CsCov | Checksum | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | |X| | . 191 | Res | Type |=| Reserved | Sequence Number (high bits) . 192 | | |1| | . 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Sequence Number (low bits) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2: The extended DCCP Header with Long Sequence Numbers 198 [RFC4340] 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Source Port | Dest Port | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Data Offset | CCVal | CsCov | Checksum | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | |X| | 208 | Res | Type |=| Sequence Number (low bits) | 209 | | |0| | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 3: The short DCCP Header with Short Sequence Numbers [RFC4340] 214 All generic header fields have the meaning specified in [RFC4340], 215 updated by [RFC5596]. 217 3.3. UDP header 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Source Port | Dest Port | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Length | Checksum | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 4: The UDP Header [RFC768] 229 All header fields have the meaning specified in [RFC0768]. 231 3.4. U-DCCP conversion considerations 233 The U-DCCP header has the goal to merge the information of DCCP's 234 extended header (Section 3.1) and imitates in the first 64 bits the 235 UDP header (Section 3.2). Information required to restore a DCCP 236 header from any conversion, which must not be lost, includes: source 237 and destination port, Data Offset, CCVal, CsCov, Checksum, Type, X 238 and the Sequence Number. 240 Compared with the UDP header, the DCCP extented header shows 241 similarities in source and destination port and checksum. The length 242 field of UDP (bits 33-48) is not part of the DCCP header and contains 243 in case of DCCP the fields Data Offset, CCVal and CsCov. 245 For the goal of imitating UDP, the checksum must cover the whole 246 datagram, which renders any limitation by CsCov useless. The 247 checksum itself is required to re-calculate after conversion anyway. 249 If the conversion is limited to DCCP'S extended header only, X is 250 always "1". 252 Thus, Data Offset, CCVal, Type and Sequence Number must be re- 253 arranged in a way that the Length field of UDP can be applied. 255 3.5. U-DCCP header 257 The considerations of Section 3.3 leads to the following header, 258 denoted as U-DCCP header. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 U | Source Port | Dest Port | 264 D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 P | Length | Checksum | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | CCVal | Data Offset | Sequence Number (high bits) . 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 . Sequence Number (low bits) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 5: The U-DCCDP Header 274 The first 8 bytes of the U-DCCP header corresponds to [RFC0768] and 275 the fields are interpreted as follows: 277 Source and Dest(ination) Ports: 16 bits each 278 These fields identify the UDP ports used by the source and 279 destination (respectively) of the packet to listen for incoming UDP 280 packets. The UDP port values identify the DCCP source and 281 destination ports. 283 Length: 16 bits 285 This field is the length of the UDP datagram, including the UDP 286 header and the payload (for U-DCCP, the payload comprises the payload 287 of the original DCCP datagram and part of its header). 289 Checksum: 16 bits 291 This field is the Internet checksum of a network-layer pseudoheader 292 and Length bytes of the UDP packet [RFC0768]. The UDP checksum MUST 293 NOT be zero for a U-DCCP packet. 295 The remaining 8 bytes of the U-DCCP header contains: 297 Type, CCVal, Data Offset, Seq. Number: As specified in [RFC4340] 299 In case U-DCCP is applied, the IP layer must be instructed to carry 300 an UDP datagram and its checksum must be re-calculated. For detailed 301 information see Section 3.7. 303 3.6. Implementation 305 The process of applying U-DCCP is defined as follows: 307 DCCP generation -> U-DCCP conversion -> UDP transmission -> U-DCCP 308 reception and restoration -> DCCP reception 310 The conversion can be integrated into DCCP endpoints directly or as 311 an additional component on the way along the transmission route. 312 Depending on the degree of integration, especially the process of 313 checksum calculation and validation can be optimized. Section 3.7 314 and Section 3.8 provide a possible pseudo-code for the conversion 315 without any optimized integration into the sender's network stack or 316 into the receiver's network stack. The pseudo-code assumes explicit 317 knowledge on which U-DCCP flows need conversion between the sender 318 and the receiver. 320 3.7. Pseudo-code DCCP to U-DCCP conversion 322 A possible processing of an already generated DCCP datagram for 323 U-DCCP conversion: 325 1. Receive DCCP datagram. 327 2. Check eligibility for conversion; otherwise bypass conversion. 329 3. Verify consistency, e.g. checksum; otherwise drop. 331 4. Shift Type and CCVal field to the ninth octet. 333 5. Shift Data Offset field to the tenth octet. 335 6. Place a length information at octet 5+6 corresponding to 336 [RFC0768]. 338 7. Modify the IP header's encapsulated protocol from DCCP to UDP. 340 8. Re-calculate IP header checksum. 342 9. Reset DCCP checksum field: octet 7+8 = 0. 344 10. Generate new checksum at octet 7+8 as described in [RFC0768]. 346 11. Forward to destination based on the unmodified 4-tuple of IP- 347 addresses and ports. 349 3.8. Pseudo-code U-DCCP to DCCP restoration 351 A possible processing of an already converted U-DCCP datagram for 352 DCCP restoration: 354 1. Receive UDP datagram. 356 2. Check eligibility for restoration; otherwise bypass restoration 358 3. Validate UDP checksum; otherwise drop. 360 4. Restore Data Offset field according to [RFC4340]. 362 5. Restore CCVal field according to [RFC4340]. 364 6. Set CsCov field according to [RFC4340] to "0". 366 7. Restore Type field according to [RFC4340]. 368 8. Set Reserved bits according to [RFC4340] to "0". 370 9. Set X according to [RFC4340] to "1". 372 10. Modify the IP header's encapsulated protocol from UDP to DCCP. 374 11. Re-calculate IP header checksum. 376 12. Reset DCCP checksum field: octet 7+8 = 0. 378 13. Generate new checksum at octet 7+8 as described in [RFC0768]. 380 14. Forward to destination based on the unmodified 4-tuple of IP- 381 addresses and ports. 383 3.9. U-DCCP negotiation (required????) 385 Tbd later if required. Otherwise assumes explicit knowledge about 386 the U-DCCP conversion between sender and receiver. 388 4. Security Considerations 390 TBD. 392 5. IANA Considerations 394 6. Notes 396 This document is inspired by [RFC6773] and some text passages for the 397 -00 version are copied unmodified. 399 7. Acknowledgments 401 8. Informative References 403 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 404 DOI 10.17487/RFC0768, August 1980, 405 . 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 413 Congestion Control Protocol (DCCP)", RFC 4340, 414 DOI 10.17487/RFC4340, March 2006, 415 . 417 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 418 Translation (NAT) Behavioral Requirements for Unicast 419 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 420 2007, . 422 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 423 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 424 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 425 September 2009, . 427 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 428 Behavioral Requirements for the Datagram Congestion 429 Control Protocol", BCP 150, RFC 5597, 430 DOI 10.17487/RFC5597, September 2009, 431 . 433 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 434 Datagram Congestion Control Protocol UDP Encapsulation for 435 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 436 2012, . 438 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 439 A., and H. Ashida, "Common Requirements for Carrier-Grade 440 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 441 April 2013, . 443 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 444 S., and K. Naito, "Updates to Network Address Translation 445 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 446 DOI 10.17487/RFC7857, April 2016, 447 . 449 Authors' Addresses 451 Markus Amend 452 Deutsche Telekom 453 Deutsche-Telekom-Allee 7 454 64295 Darmstadt 455 Germany 457 Email: Markus.Amend@telekom.de 459 Anna Brunstrom 460 Karlstad University 461 Universitetsgatan 2 462 651 88 Karlstad 463 Sweden 465 Email: anna.brunstrom@kau.se 466 Andreas Kassler 467 Karlstad University 468 Universitetsgatan 2 469 651 88 Karlstad 470 Sweden 472 Email: andreas.kassler@kau.se 474 Veselin Rakocevic 475 City University of London 476 Northampton Square 477 London 478 United Kingdom 480 Email: veselin.rakocevic.1@city.ac.uk