idnits 2.17.1 draft-irtf-dtnrg-udp-clayer-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 332. 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 date (November 19, 2008) is 5634 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2147 (Obsoleted by RFC 2675) == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-tcp-clayer-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTNRG H. Kruse 3 Internet-Draft S. Ostermann 4 Intended status: Experimental Ohio University 5 Expires: May 23, 2009 November 19, 2008 7 UDP Convergence Layers for the DTN Bundle and LTP Protocols 8 draft-irtf-dtnrg-udp-clayer-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 23, 2009. 35 Abstract 37 This document specifies the use of the User Datagram Protocol (UDP) 38 as a method for transporting DTN protocol data over the Internet. 39 The specification covers both the use of UDP as a convergence layer 40 for the Bundle Protocol as well as the use of UDP to carry LTP 41 segments. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 47 2. General UDP Considerations . . . . . . . . . . . . . . . . . . 3 48 2.1. UDP Checksums are Required . . . . . . . . . . . . . . . . 3 49 2.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 3 50 2.3. How and Where to Deal with Fragmentation . . . . . . . . . 4 51 2.4. Keep Alive Option . . . . . . . . . . . . . . . . . . . . . 5 52 3. Bundle Protocol over UDP Convergence Layer . . . . . . . . . . 5 53 4. LTP over UDP Convergence Layer . . . . . . . . . . . . . . . . 5 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . . . 8 63 1. Introduction 65 Delay/Disruption Tolerant Network (DTN) communication protocols 66 include the Bundle Protocol described in RFC 5050 [RFC5050], which 67 provides reliable transmission of application data blocks (bundles) 68 with optional intermediate custody transfer, and the Licklider 69 Transport Protocol (LTP), RFCs 5325 [RFC5325], 5326 [RFC5326], and 70 5327 [RFC5327] which can be used to transmit bundles reliably and 71 efficiently over a point to point link. It is often desirable to 72 test these protocols over Internet Protocol links. 73 draft-irtf-dtnrg-tcp-clayer [I-D.irtf-dtnrg-tcp-clayer] defines a 74 method for transporting bundles over TCP. This draft specifies the 75 convergence layer for transmitting either bundles or LTP blocks over 76 UDP. 78 1.1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. General UDP Considerations 86 2.1. UDP Checksums are Required 88 Both the core bundle protocol specification and core LTP 89 specification assume that they are transmitting over an erasure 90 channel, i.e. a channel that either delivers packets correctly or not 91 at all. The UDP CL transmitter therefore MUST NOT disable UDP 92 checksums, and the UDP CL receiver MUST NOT disable checking of 93 received UDP checksums. 95 Even when UDP checksums are enabled a small probablity of UDP packet 96 corruption remains. In some environments it may be acceptable for 97 LTP or the bundle protocol to occasionally receive corrcupted input. 98 In general, however, a UDP CL implementation SHOULD use optional 99 security extensions available in the bundle protocol or LTP to 100 protect against message corruption (see the protocol specific 101 sections below). 103 2.2. Congestion Control 105 UDP operates on a packet by packet, best effort delivery basis. It 106 provides no congestion control. When the bundle protocol or LTP are 107 operated over UDP, the lack of congestion control can interfere with 108 other traffic in the network, and will be particularly harmful to 109 traffic that does obey congestion control. If the UDP CL is used to 110 send more than a very small number of packets at a time, it either 111 SHOULD NOT be used outside an isolated network, or it MUST implement 112 congestion control procedures as outlined in RFC 5405. 114 2.3. How and Where to Deal with Fragmentation 116 The bundling protocol allows bundles with sizes limited only by node 117 resource constraints. In IPv4, the maximum size of a UDP datagram is 118 nearly 64KB. In IPv6, when using jumbograms [RFC2675], UDP datagrams 119 can be up to 4GB in size [RFC2147]. It is well understood that 120 sending large IP datagrams that must be fragmented by the network has 121 enormous efficiency penalties [Kent88]. The primary efficiency 122 penalty is increased loss probability. When a large datagram is 123 broken into a number of fragments, the original datagram can only be 124 recreated if all the fragments arrive at the ultimate destination for 125 reassembly. When transmitted over a network with a packet loss 126 probability of 2%, for example, a single, unfragmented datagram will 127 arrive with probability 98%; a large datagram fragmented into 10 128 fragments will have all of its fragments arrive with probability 129 98%**10, giving a datagram arrival probability of only 81.7%. The 130 higher-level protocol using UDP for delivery can retransmit lost UDP 131 datagrams, but cannot retransmit lost IP datagram fragments. 132 Therefore, retransmitting large, lost datagrams because of a small 133 number of missing fragments can require many more packets than 134 retransmitting a number of smaller, unfragmented datagrams because 135 only the missing pieces need to be retransmitted. The other 136 efficiency penalty paid by fragmentation that would be significant 137 for DTN is the resources (time, complexity, and memory) required for 138 IP reassembly. 140 When an LTP CL is using UDP for datagram delivery, it SHOULD NOT 141 create segments that will result in UDP datagrams that will need to 142 be fragmented, as discussed above. When using UDP directly as a CL, 143 the software SHOULD NOT directly encapsulate large bundles into large 144 UDP datagrams that would need to be fragmented, as discussed above. 145 In the latter case, the bundle protocol specification provides a 146 bundle fragmentation concept [RFC5050] that allows a large bundle to 147 be divided into bundle fragments, each of which SHOULD be created of 148 sufficiently small size that it can then be encapsulated into a UDP 149 datagram that will not need to be fragmented. 151 Without information from elsewhere in the networking stack about path 152 MTU, the protocol can assume a minimum path MTU that would allow 512 153 bytes of UDP data [RFC0791] over IPv4 or (1280-(UDP and IP header 154 sizes)) bytes [RFC1883] over IPv6. 156 2.4. Keep Alive Option 158 It may be desirable for a UDP CL to send "keep-alive" packets during 159 extended idle periods. This may be needed to refresh a contact table 160 entry at the destination, or to maintain an address mapping in a NAT 161 or a dynamic access rule in a firewall. Therefore, a UDP CL MAY send 162 a UDP packet containing exactly 4 octets of zero bits. A UDP CL 163 receiving such a packet MUST discard this packet; the receiving CL 164 may then perform local maintenance of its state tables, these 165 maintenance functions are not covered in this draft. Note that 166 "real" CL packets will always contain more than 4 octets of 167 information (either the bundle or the LTP header); keep-alives will 168 therefore never be mistaken for actual data packets. 170 3. Bundle Protocol over UDP Convergence Layer 172 In general, the use of the bundle protocol over a UDP CL is 173 discouraged. Bundles can be of (almost) arbitrary length, and the 174 bundle protocol does not include an effective retransmission 175 mechanism. Whenever possible the bundle protocol SHOULD be operated 176 over the TCP Convergence Layer or over LTP. 178 If a UDP CL is used for transmission of bundles, every UDP packet 179 MUST contain exactly one bundle or four zero octets as a keep-alive. 180 The UDP CL SHOULD use avalailable operating system services to obtain 181 the largest supported UDP packet size, and MAY use the default UDP 182 packet size limit if path-specific information is not available. For 183 bundles that are too large for the supported UDP packet size, the 184 bundle protocol fragmentation process SHOULD be used transmit the 185 large bundle. 187 The UDP CL for bundle protocol use SHOULD use the IANA assigned port 188 4556/UDP; the use of other port numbers is implementation specific. 190 4. LTP over UDP Convergence Layer 192 LTP is designed as a point to point protocol within DTN, and it 193 provides intrinsic acknowledgement and retransmission facilities. 194 Transmission of LTP over a UDP CL is therefore the most appropriate 195 choice. When a UDP CL is used to transmit LTP data, every UDP packet 196 MUST contain exactly one LTP segment or four zero octets as a keep- 197 alive. The UDP CL SHOULD use avalailable operating system services 198 to obtain the largest supported UDP packet size, and MAY use the 199 default UDP packet size limit if path-specific information is not 200 available. LTP MUST perform segmentation in such a way as to insure 201 that every LTP segments fits into a UDP packet. 203 The UDP CL for LTP SHOULD use the IANA assigned port 1113/UDP; the 204 use of other port numbers is implementation specific. 206 5. Acknowledgements 208 6. IANA Considerations 210 This memo includes no request to IANA. 212 7. Security Considerations 214 This memo describes the use of UDP to transport DTN applications 215 data. Hosts may be in a position of having to accept and process UDP 216 packet from unknown sources; the DTN Endpoint ID can be discovered 217 only after the bundle has been retrieved from the UDP packet. Hosts 218 SHOULD use authentication methods available in the DTN specifications 219 to prevent malicious hosts from inserting unknown data into the 220 application. 222 Hosts need to listen for and process UDP data on the known LTP or 223 bundle protocol ports. A denial of service scenario exists where a 224 malicious host send UDP packets at a high rate, forcing the receiving 225 hosts to use its resources to process and attempt to authenticate 226 these data. Whenever possible, hosts SHOULD use IP address filtering 227 to limit the origin of packets to known hosts. 229 8. References 231 8.1. Normative References 233 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 234 September 1981. 236 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 237 (IPv6) Specification", RFC 1883, December 1995. 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, 243 May 1997. 245 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 246 RFC 2675, August 1999. 248 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 249 Specification", RFC 5050, November 2007. 251 [RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider 252 Transmission Protocol - Motivation", RFC 5325, 253 September 2008. 255 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 256 Transmission Protocol - Specification", RFC 5326, 257 September 2008. 259 [RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 260 Transmission Protocol - Security Extensions", RFC 5327, 261 September 2008. 263 8.2. Informative References 265 [I-D.irtf-dtnrg-tcp-clayer] 266 Demmer, M. and J. Ott, "Delay Tolerant Networking TCP 267 Convergence Layer Protocol", 268 draft-irtf-dtnrg-tcp-clayer-02 (work in progress), 269 November 2008. 271 [Kent88] Kent, C. and J. Mogul, "Fragmentation considered 272 harmful.", 1988, . 274 Authors' Addresses 276 Hans Kruse 277 Ohio University 278 292 Lindley Hall 279 Athens, OH 45701 280 United States 282 Phone: +1 740 593 4891 283 Email: kruse@ohiou.edu 285 Shawn Ostermann 286 Ohio University 287 Stoecker Engineering Center 288 Athens, OH 45701 289 United States 291 Phone: +1 740 593 1566 292 Email: ostermann@eecs.ohiou.edu 294 Full Copyright Statement 296 Copyright (C) The IETF Trust (2008). 298 This document is subject to the rights, licenses and restrictions 299 contained in BCP 78, and except as set forth therein, the authors 300 retain all their rights. 302 This document and the information contained herein are provided on an 303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 305 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 306 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 307 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 310 Intellectual Property 312 The IETF takes no position regarding the validity or scope of any 313 Intellectual Property Rights or other rights that might be claimed to 314 pertain to the implementation or use of the technology described in 315 this document or the extent to which any license under such rights 316 might or might not be available; nor does it represent that it has 317 made any independent effort to identify any such rights. Information 318 on the procedures with respect to rights in RFC documents can be 319 found in BCP 78 and BCP 79. 321 Copies of IPR disclosures made to the IETF Secretariat and any 322 assurances of licenses to be made available, or the result of an 323 attempt made to obtain a general license or permission for the use of 324 such proprietary rights by implementers or users of this 325 specification can be obtained from the IETF on-line IPR repository at 326 http://www.ietf.org/ipr. 328 The IETF invites any interested party to bring to its attention any 329 copyrights, patents or patent applications, or other proprietary 330 rights that may cover technology that may be required to implement 331 this standard. Please address the information to the IETF at 332 ietf-ipr@ietf.org.