idnits 2.17.1 draft-ietf-behave-dccp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 398. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 4, 2008) is 5837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-07 == Outdated reference: A later version (-08) exists of draft-ietf-dccp-simul-open-00 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-11) exists of draft-ietf-dccp-serv-codes-05 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance R. Denis-Courmont 3 Avoidance VideoLAN project 4 Internet-Draft May 4, 2008 5 Intended status: Standards Track 6 Expires: November 5, 2008 8 Network Address Translation (NAT) Behavioral Requirements for DCCP 9 draft-ietf-behave-dccp-00.txt 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 5, 2008. 36 Abstract 38 This document defines a set of requirements for DCCP-capable NATs 39 that would allow certain applications, such as streaming applications 40 to operate consistently. These requirements are very similar to the 41 TCP requirements for NATs already published by this IETF working 42 group. Developing NATs that meet this set of requirements will 43 greatly increase the likelihood that applications using DCCP will 44 function properly. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 51 4. DCCP Connection Initiation . . . . . . . . . . . . . . . . . . 4 52 5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5 53 6. Application Level Gateways . . . . . . . . . . . . . . . . . . 6 54 7. Other Requirements Applicable to DCCP . . . . . . . . . . . . . 6 55 8. Requirements specific to DCCP . . . . . . . . . . . . . . . . . 7 56 9. DCCP without NAT support . . . . . . . . . . . . . . . . . . . 7 57 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 59 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 60 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 13.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 For historical reasons, NAT devices are not typically capable of 67 handling datagrams and flows for applications using the Datagram 68 Congestion Control Protocol (DCCP)[RFC4340]. 70 This draft discusses the technical issues involved, and proposes a 71 set of requirements for NAT devices to handle DCCP in a way that 72 enables communications when either or both of the DCCP endpoints are 73 located behind one or more NAT devices. All definitions and 74 requirements in [RFC4787] are inherited here. The requirements are 75 otherwise designed similarly to those in [I-D.ietf-behave-tcp], from 76 which this memo borrows its structure and much of its content. 78 Note however that, if both endpoints are hindered by NAT devices, the 79 normal model of asymmetric connection model of DCCP will not work. A 80 simultaneous open must be performed, as in 81 [I-D.ietf-dccp-simul-open]. Also, a separate unspecified mechanism 82 may be needed, such as UNSAF protocols, if an endpoint needs to learn 83 its own external NAT mappings. 85 2. Definitions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 This documentation uses the term "DCCP connection" to refer to 92 invidual DCCP flows, as uniquely identified by the the 4-tuple 93 (source and destination IP addresses and DCCP ports) at a given time. 95 This document uses the term "NAT mapping" to refer to state at the 96 NAT necessary for network address and port translation of DCCP 97 connections. This document also uses the terms "endpoint independent 98 mapping", "address dependent mapping", "address and port dependent 99 mapping", "filtering behavior", "endpoint independent filtering", 100 "address dependent filtering", "address and port dependent 101 filtering", "port assignment", "port overloading", "hairpinning", and 102 "external source IP address and port" as defined in [RFC4787]. 104 3. Applicability statement 106 This document applies to NAT devices that want to handle DCCP 107 datagrams. It is not the intent of this document to deprecate the 108 overwhelming majority of deployed NAT devices. These NATs are simply 109 not expected to handle DCCP, so this memo is not applicable to them. 111 Expected NAT behaviors applicable to DCCP connections are very 112 similar to those applicable to TCP connections (with the exception or 113 REQ-6 below). The following requirements are discussed and justified 114 extensively in [I-D.ietf-behave-tcp]. These justifications are not 115 reproduced here for the sake of brevity. 117 In addition to the usual changes to the IP header (in particular the 118 IP addresses), NAT devices need to mangle: 120 o the DCCP source port, for outgoing packets, depending on the NAT 121 mapping 123 o the DCCP destination port, for incoming packets, depending on the 124 NAT mapping 126 o the DCCP checksum, to compensate for IP address and port number 127 modifications. 129 Because changing the the source or destination IP address of a DCCP 130 packet will normally invalidate the DCCP checksum, it is not possible 131 to use DCCP through a NAT without dedicated support. Some NAT 132 devices are known to provide a "generic" transport protocol support, 133 whereby only the IP header is mangled. That scheme is not sufficient 134 to support DCCP in any case. 136 4. DCCP Connection Initiation 138 4.1. Address and Port Mapping Behavior 140 A NAT uses a mapping to translate packets for each DCCP connection. 141 A mapping is dynamically allocated for connections initiated from the 142 internal side, and potentially reused for certain subsequent 143 connections. NAT behavior regarding when a mapping can be reused 144 differs for different NATs as described in [RFC4787]. 146 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior for 147 DCCP. 149 4.2. Internally Initiated Connections 151 REQ-2: A NAT MUST support all valid sequences of DCCP packets 152 (defined in [RFC4340] and its updates) for connections initiated both 153 internally as well as externally when the connection is permitted by 154 the NAT. 156 In particular, in addition to handling the DCCP 3-way handshake mode 157 of connection initiation, A NAT MUST handle the DCCP simultaneous- 158 open mode of connection initiation, defined in 159 [I-D.ietf-dccp-simul-open]. That mode updates DCCP by adding a new 160 packet type, DCCP-Listen. The A DCCP-Listen packet communicates the 161 information necessary to uniquely identify a DCCP session. NATs may 162 utilise the connection information (address, port, Service Code) to 163 establish local forwarding state. 165 4.3. Externally Initiated Connections 167 REQ-3: If application transparency is most important, it is 168 RECOMMENDED that a NAT have an "Endpoint independent filtering" 169 behavior for DCCP. If a more stringent filtering behavior is most 170 important, it is RECOMMENDED that a NAT have an "Address dependent 171 filtering" behavior. 173 o The filtering behavior MAY be an option configurable by the 174 administrator of the NAT. 176 o The filtering behavior for TCP MAY be independent of thefiltering 177 behavior for UDP. 179 REQ-4: A NAT MUST NOT respond to an unsolicited inbound DCCP-Listen 180 packet for at least 6 seconds after the packet is received. If 181 during this interval the NAT receives and translates an outbound 182 DCCP-Request packet for the connection the NAT MUST silently drop the 183 original unsolicited inbound DCCP-Listen packet. Otherwise the NAT 184 SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the 185 original DCCP-Listen, unless the security policy forbids it. 187 5. NAT Session Refresh 189 The "established connection idle-timeout" for a NAT is defined as the 190 minimum time a DCCP connection in the established phase must remain 191 idle before the NAT considers the associated session a candidate for 192 removal. The "transitory connection idle-timeout" for a NAT is 193 defined as the minimum time a DCCP connection in the CLOSEREQ or 194 CLOSING phases must remain idle before the NAT considers the 195 associated session a candidate for removal. DCCP connections in the 196 TIMEWAIT state are not affected by the "transitory connection idle- 197 timeout". 199 REQ-5: If a NAT cannot determine whether the endpoints of a DCCP 200 connection are active, it MAY abandon the session if it has been idle 201 for some time. In such cases, the value of the "established 202 connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. 203 The value of the "transitory connection idle-timeout" MUST NOT be 204 less than 4 minutes. The value of the NAT idle-timeouts MAY be 205 configurable. 207 NAT behavior for handling DCCP-Reset packets, or connections in 208 TIMEWAIT state is left unspecified. 210 6. Application Level Gateways 212 Contrary to TCP, DCCP is a loss-tolerant protocol. Therefore, 213 modifying the payload of DCCP packets presents a significant 214 additionnal challenge in maintaining sane DCCP sequence numbers, if 215 the size of the payload were altered. Moreover, DCCP provides 216 natural packet boundaries, whereby TCP provides a byte stream. As 217 such, changing the size of a DCCP packet may cause additional 218 problems at the application layer. Finally, there are no known DCCP- 219 capable Application Level Gateways (ALGs) at the time of writing this 220 document. 222 REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP. 224 NOTE: This is not consistent with REQ-6 of [I-D.ietf-behave-tcp]. 226 7. Other Requirements Applicable to DCCP 228 A list of general and UDP specific NAT behavioral requirements are 229 described in [RFC4787]. A list of ICMP specific NAT behavioral 230 requirements are described in [I-D.ietf-behave-nat-icmp]. The 231 requirements listed below reiterate the requirements from these two 232 documents that directly affect DCCP. The following requirements do 233 not relax anyrequirements in [RFC4787] or [I-D.ietf-behave-nat-icmp]. 235 7.1. Port Assignment 237 REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port 238 overloading" for DCCP. 240 7.2. Hairpinning Behavior 242 REQ-8: A NAT MUST support "Hairpinning" for DCCP. Futhermore, A 243 NAT's Hairpinning behavior MUST be of type "External source IP 244 address and port". 246 7.3. ICMP Responses to DCCP Packets 248 REQ-9: If a NAT translates DCCP, it SHOULD translate ICMP Destination 249 Unreachable (Type 3) messages. 251 REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the 252 NAT mapping or DCCP connection for which the ICMP was generated. 254 8. Requirements specific to DCCP 256 8.1. Partial checksum coverage 258 DCCP supports partial checksum coverage. A NAT will usually need to 259 perform incremental changes to the packet checksum field, as for 260 other IETF-defined protocols. However, if it needs to recalulate a 261 correct checksum value, as described in section 9.2 of [RFC4340]. 263 REQ-11: If a NAT translates a DCCP packet with a valid DCCP checksum, 264 it MUST ensure that the DCCP checksum is translated such that it is 265 valid after the translation. 267 REQ-12: A NAT MUST NOT modify the value of the DCCP Checksum 268 Coverage. 270 The Checksum Coverage field in the DCCP header determines the parts 271 of the packet that are covered by the Checksum field. This always 272 includes the DCCP header and options, but some or all of the 273 application data may be excluded as determined on a packet-by-packet 274 basis by the application. Changing the Checksum Coverage in the 275 network violates the integrity assumptions at the receiver and may 276 result in unpredictable or incorrect application behaviour. 278 8.2. Services codes 280 DCCP specifies a Service Code as a 4-byte value (32 bits) that 281 describes the application-level service to which a client application 282 wishes to connect [RFC4340]. 284 REQ-13: If a NAT translates a DCCP packet, it MUST NOT modify its 285 DCCP service code value. 287 Further guidance on the use of Service Codes by middleboxes, 288 including NATs, can be found in [I-D.ietf-dccp-serv-codes]. 290 9. DCCP without NAT support 292 If the NAT device cannot be updated to support DCCP, DCCP datagram 293 can be encapsulated within an UDP transport header. Indeed, most NAT 294 devices are already capable of handling UDP. This is however beyond 295 the scope of this document. 297 10. Security Considerations 299 TBD. 301 11. IANA Considerations 303 This document raises no IANA considerations. 305 12. Acknowledgments 307 The author would like to thank Gorry Fairhurst for his comments and 308 help on this document. 310 This memo borrows heavily from draft-ietf-behave-tcp-07, by S. Guha 311 (editor), K. Biswas, B. Ford, S. Sivakumar and P. Srisuresh. 313 13. References 315 13.1. Normative References 317 [I-D.ietf-behave-nat-icmp] Srisuresh, P., Ford, B., Sivakumar, S., 318 and S. Guha, "NAT Behavioral Requirements 319 for ICMP protocol", 320 draft-ietf-behave-nat-icmp-07 (work in 321 progress), February 2008. 323 [I-D.ietf-dccp-simul-open] Fairhurst, G. and G. Renker, "DCCP 324 Simultaneous-Open Technique to Facilitate 325 NAT/Middlebox Traversal", 326 draft-ietf-dccp-simul-open-00 (work in 327 progress), February 2008. 329 [RFC2119] Bradner, S., "Key words for use in RFCs 330 to Indicate Requirement Levels", BCP 14, 331 RFC 2119, March 1997. 333 [RFC4340] Kohler, E., Handley, M., and S. Floyd, 334 "Datagram Congestion Control Protocol 335 (DCCP)", RFC 4340, March 2006. 337 [RFC4787] Audet, F. and C. Jennings, "Network 338 Address Translation (NAT) Behavioral 339 Requirements for Unicast UDP", BCP 127, 340 RFC 4787, January 2007. 342 13.2. Informative References 344 [I-D.ietf-behave-tcp] Guha, S., "NAT Behavioral Requirements 345 for TCP", draft-ietf-behave-tcp-07 (work 346 in progress), April 2007. 348 [I-D.ietf-dccp-serv-codes] Fairhurst, G., "The DCCP Service Code", 349 draft-ietf-dccp-serv-codes-05 (work in 350 progress), April 2008. 352 Author's Address 354 Remi Denis-Courmont 355 VideoLAN project 357 EMail: rem@videolan.org 358 URI: http://www.videolan.org/ 360 Full Copyright Statement 362 Copyright (C) The IETF Trust (2008). 364 This document is subject to the rights, licenses and restrictions 365 contained in BCP 78, and except as set forth therein, the authors 366 retain all their rights. 368 This document and the information contained herein are provided on an 369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 371 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 372 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 373 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Intellectual Property 378 The IETF takes no position regarding the validity or scope of any 379 Intellectual Property Rights or other rights that might be claimed to 380 pertain to the implementation or use of the technology described in 381 this document or the extent to which any license under such rights 382 might or might not be available; nor does it represent that it has 383 made any independent effort to identify any such rights. Information 384 on the procedures with respect to rights in RFC documents can be 385 found in BCP 78 and BCP 79. 387 Copies of IPR disclosures made to the IETF Secretariat and any 388 assurances of licenses to be made available, or the result of an 389 attempt made to obtain a general license or permission for the use of 390 such proprietary rights by implementers or users of this 391 specification can be obtained from the IETF on-line IPR repository at 392 http://www.ietf.org/ipr. 394 The IETF invites any interested party to bring to its attention any 395 copyrights, patents or patent applications, or other proprietary 396 rights that may cover technology that may be required to implement 397 this standard. Please address the information to the IETF at 398 ietf-ipr@ietf.org.