idnits 2.17.1 draft-denis-behave-nat-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 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 229. 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 (November 12, 2007) is 6008 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 (-08) exists of draft-ietf-behave-tcp-07 Summary: 1 error (**), 0 flaws (~~), 2 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 (if taken) VideoLAN project 4 Internet-Draft November 12, 2007 5 Intended status: Standards Track 6 Expires: May 15, 2008 8 Network Address Translation (NAT) Behavioral Requirements for DCCP 9 draft-denis-behave-nat-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 May 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document would define a set of requirements for NATs that handle 43 DCCP. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Requirements for NATs . . . . . . . . . . . . . . . . . . . . . 3 51 5. Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 6. DCCP simultaneous open . . . . . . . . . . . . . . . . . . . . 4 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 54 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 10.1. Normative References . . . . . . . . . . . . . . . . . . . 5 58 10.2. Informative References . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 For historical reasons, NAT devices are not typically capable of 63 handling datagrams and flows for application using the Datagram 64 Congestion Control Protocol (DCCP)[RFC4340]. 66 This draft discusses the technical issues involved, and proposes 67 different potential solutions. It is however expected that not all 68 of them (if any) will be carried on. 70 2. Definitions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Applicability 78 This document applies to NAT devices that want to handle DCCP 79 datagrams. It is not the intent of this document to deprecate the 80 overwhelming majority of deployed NAT devices. These NATs are simply 81 not expected to handle DCCP, so this memo is not applicable to them. 83 TBD: This draft does not currently specify any clear requirement 84 anyway. 86 4. Requirements for NATs 88 The first approach to using DCCP through NAT devices involves 89 changing the NAT devices to handle DCCP explicitly. Processing of 90 DCCP packets by a NAT device would then be very similar to processing 91 of TCP packets, as already specified in [I-D.ietf-behave-tcp]. 93 In addition to the usual changes to the IP header, NAT devices would 94 need to mangle: 95 o DCCP source port, for outgoing packets, depending on the NAT 96 mapping 97 o DCCP destination port, for incoming packets, depending on the NAT 98 mapping 99 o DCCP checksum, to compensate for IP address and port number 100 modifications. 102 Because changing the the source or destination IP address of a DCCP 103 packet will normally invalidate the DCCP checksum, it is not possible 104 to use DCCP through a NAT without dedicated support. Some NAT 105 devices are known to provide a "generic" transport protocol support, 106 whereby only the IP header is mangled. That scheme will not work 107 with DCCP at all. 109 TBD: write down actual mapping and timing requirements, etc. See 110 behave-nat-tcp as a start. 112 5. Tunnelling 114 Tunnelling is another approach: DCCP datagram would be encapsulated 115 into an additionnal UDP transport header. This relies on the fact 116 that many NATs are capable of handling UDP datagrams. This solution 117 has tha major advantage of not needing any changes to the existing 118 deployed NAT devices. 120 Issues with this solution include: 121 o Both sides of the DCCP session need to be updated to use 122 tunnelling, even though only one side might be hindered with a 123 NAT. This implies a non-backward compatible extension to 124 [RFC4340]. 125 o A method MUST be defined to negociate when to use tunnelling. 126 o The per-packet overhead is increased. 128 Various actual tunnelling solutions are already defined, such as ESP- 129 in-UDP[RFC3948] (especially with the NULL cipher suite) or 130 Teredo[RFC4380]. 132 6. DCCP simultaneous open 134 When both parties to an intended DCCP session are located behind 135 either a NAT device or a stateful firewall, neither can act as the 136 paassive endpoint in the connection establishment. 138 Unfortunately, at the time of writing, the DCCP connection state 139 machine does not allow both peers to behave as active endpoint, as is 140 the case in TCP simultaneous open. It is expected that this issue 141 will be tackled in the DCCP working group shortly (TODO: reference 142 relevant I-D). 144 7. Security Considerations 146 TBD. 148 8. IANA Considerations 150 This document raises no IANA considerations. 152 9. Acknowledgments 154 The authors would like to thank ... for their comments on this 155 document. 157 10. References 159 10.1. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to 162 Indicate Requirement Levels", BCP 14, 163 RFC 2119, March 1997. 165 [RFC4340] Kohler, E., Handley, M., and S. Floyd, 166 "Datagram Congestion Control Protocol (DCCP)", 167 RFC 4340, March 2006. 169 10.2. Informative References 171 [I-D.ietf-behave-tcp] Guha, S., "NAT Behavioral Requirements for 172 TCP", draft-ietf-behave-tcp-07 (work in 173 progress), April 2007. 175 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, 176 L., and M. Stenberg, "UDP Encapsulation of 177 IPsec ESP Packets", RFC 3948, January 2005. 179 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP 180 through Network Address Translations (NATs)", 181 RFC 4380, February 2006. 183 Author's Address 185 Remi Denis-Courmont 186 VideoLAN project 188 EMail: rem@videolan.org 189 URI: http://www.videolan.org/ 191 Full Copyright Statement 193 Copyright (C) The IETF Trust (2007). 195 This document is subject to the rights, licenses and restrictions 196 contained in BCP 78, and except as set forth therein, the authors 197 retain all their rights. 199 This document and the information contained herein are provided on an 200 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 201 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 202 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 203 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 204 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 205 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 207 Intellectual Property 209 The IETF takes no position regarding the validity or scope of any 210 Intellectual Property Rights or other rights that might be claimed to 211 pertain to the implementation or use of the technology described in 212 this document or the extent to which any license under such rights 213 might or might not be available; nor does it represent that it has 214 made any independent effort to identify any such rights. Information 215 on the procedures with respect to rights in RFC documents can be 216 found in BCP 78 and BCP 79. 218 Copies of IPR disclosures made to the IETF Secretariat and any 219 assurances of licenses to be made available, or the result of an 220 attempt made to obtain a general license or permission for the use of 221 such proprietary rights by implementers or users of this 222 specification can be obtained from the IETF on-line IPR repository at 223 http://www.ietf.org/ipr. 225 The IETF invites any interested party to bring to its attention any 226 copyrights, patents or patent applications, or other proprietary 227 rights that may cover technology that may be required to implement 228 this standard. Please address the information to the IETF at 229 ietf-ipr@ietf.org. 231 Acknowledgement 233 Funding for the RFC Editor function is provided by the IETF 234 Administrative Support Activity (IASA).