idnits 2.17.1 draft-ietf-tsvwg-udp-lite-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** There are 191 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC-768]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '3GPP-QoS' is mentioned on line 85, but not defined == Unused Reference: '3GPP' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'ITU-H.264' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC-2026' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC-2402' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC-2406' is defined on line 446, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1071 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-05) exists of draft-ietf-avt-ilbc-codec-01 -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3267 (Obsoleted by RFC 4867) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L-A. Larzon 3 INTERNET-DRAFT Lulea University of Technology 4 Expires: January 2003 M. Degermark 5 S. Pink 6 The University of Arizona 7 L-E. Jonsson (Editor) 8 Ericsson 9 G. Fairhurst (Editor) 10 University of Aberdeen 11 August, 2003 13 The UDP-Lite Protocol 14 16 Status of this memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Please direct comments to the TSV WG mailing list: tsvwg@ietf.org 38 Abstract 40 This document describes the UDP-Lite protocol, which is similar to 41 UDP [RFC-768], but can also serve applications that in error-prone 42 network environments prefer to have partially damaged payloads 43 delivered rather than discarded. If this feature is not used, UDP- 44 Lite is semantically identical to UDP. 46 Table of Contents 47 1. Introduction...................................................2 48 2. Terminology....................................................3 49 3. Protocol Description...........................................3 50 3.1. Fields....................................................3 51 3.2. Pseudo Header.............................................4 52 3.3. Application Interface.....................................4 53 3.4. IP Interface..............................................5 54 3.5. Jumbograms................................................5 55 4. Lower Layer Considerations.....................................6 56 5. Compatibility with UDP.........................................6 57 6. Security Considerations........................................7 58 7. IANA Considerations............................................8 59 8. References.....................................................8 60 8.1. Normative References......................................8 61 8.2. Informative References....................................9 62 9. Acknowledgements...............................................10 63 10. Authors' Addresses............................................11 65 1. Introduction 67 This document describes a new transport protocol, UDP-Lite, (also 68 known as UDPLite). This new protocol is based on three observations: 70 First, there is a class of applications that benefit from having 71 damaged data delivered rather than discarded by the network. A number 72 of codecs for voice and video fall into this class (e.g. the AMR 73 speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC], and 74 error resilient H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264] and 75 MPEG-4 [ISO-14496] video codecs). These codecs may be designed to 76 cope better with errors in the payload than with loss of entire 77 packets. 79 Second, all links that support IP transmission should use a strong 80 link layer integrity check (e.g. CRC-32 [LINK]), and this MUST be 81 used by default for IP traffic. When the under-lying link supports 82 it, certain types of traffic (e.g. UDP-Lite) may benefit from a 83 different link behavior that permits partially damaged IP packets to 84 be forwaded when requested [LINK]. Several radio technologies (e.g. 85 [3GPP-QoS]) support this link behavior when operating at a point 86 where cost and delay are sufficiently low. If error-prone links are 87 aware of the error sensitive portion of a packet, it is also possible 88 for the physical link to provide greater protection to reduce the 89 probability of corruption of these error sensitive bytes (e.g., the 90 use of unequal Forward Error Correction). 92 Third, intermediate layers (i.e., IP and the transport layer 93 protocols) should not prevent error-tolerant applications from 94 running well in the presence of such links. IP is not a problem in 95 this regard, since the IP header has no checksum that covers the IP 96 payload. The generally available transport protocol best suited for 97 these applications is UDP, since it has no overhead for 98 retransmission of erroneous packets, in-order delivery, or error 99 correction. In IPv4 [RFC-791], the UDP checksum covers either the 100 entire packet or nothing at all. In IPv6 [RFC-2460], the UDP checksum 101 is mandatory and must not be disabled. The IPv6 header does not have 102 a header checksum and it was deemed necessary to always protect the 103 IP addressing information by making the UDP checksum mandatory. 105 A transport protocol is needed that conforms to the properties of 106 link layers and applications described above [LDP99]. The error- 107 detection mechanism of the transport layer must be able to protect 108 vital information such as headers, but also to optionally ignore 109 errors best dealt with by the application. The set of octets to be 110 verified by the checksum is best specified by the sending 111 application. 113 UDP-Lite provides a checksum with an optional partial coverage. When 114 using this option, a packet is divided into a sensitive part (covered 115 by the checksum) and an insensitive part (not covered by the 116 checksum). Errors in the insensitive part will not cause the packet 117 to be discarded by the transport layer at the receiving end host. 118 When the checksum covers the entire packet, which should be the 119 default, UDP-Lite is semantically identical to UDP. 121 Compared to UDP, the UDP-Lite partial checksum provides extra 122 flexibility for applications that want to define the payload as 123 partially insensitive to bit errors. 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 [RFC-2119]. 131 3. Protocol Description 133 The UDP-Lite header is shown in figure 1. Its format differs from 134 UDP in that the Length field has been replaced with a Checksum 135 Coverage field. This can be done since information about UDP packet 136 length can be provided by the IP module in the same manner as for TCP 137 [RFC-793]. 139 0 15 16 31 140 +--------+--------+--------+--------+ 141 | Source | Destination | 142 | Port | Port | 143 +--------+--------+--------+--------+ 144 | Checksum | | 145 | Coverage | Checksum | 146 +--------+--------+--------+--------+ 147 | | 148 : Payload : 149 | | 150 +-----------------------------------+ 152 Figure 1: UDP-Lite Header Format 154 3.1. Fields 156 The fields Source Port and Destination Port are defined as in the UDP 157 specification [RFC-768]. UDP-Lite uses the same set of port number 158 values as those assigned by the IANA for use by UDP. 160 Checksum Coverage is the number of octets, counting from the first 161 octet of the UDP-Lite header, that are covered by the checksum. The 162 UDP-Lite header MUST always be covered by the checksum. Despite this 163 requirement, the Checksum Coverage is expressed in octets from the 164 beginning of the UDP-Lite header, in the same way as for UDP. A 165 Checksum Coverage of zero indicates that the entire UDP-Lite packet 166 is covered by the checksum. This means that the value of the Checksum 167 Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with 168 a Checksum Coverage value of 1 to 7 MUST be discarded by the 169 receiver. Irrespective of the Checksum Coverage, the computed 170 Checksum field MUST include a pseudo-header, based on the IP header 171 (see below). UDP-Lite packets with a Checksum Coverage greater than 172 the IP length MUST also be discarded. 174 The Checksum field is the 16-bit one's complement of the one's 175 complement sum of a pseudo-header of information collected from the 176 IP header, the number of octets specified by the Checksum Coverage 177 (starting at the first octet in the UDP-Lite header), virtually 178 padded with a zero octet at the end (if necessary) to make a multiple 179 of two octets [RFC-1071]. Prior to computation, the checksum field 180 MUST be set to zero. If the computed checksum is 0, it is transmitted 181 as all ones (the equivalent in one's complement arithmetic). 183 Since the transmitted checksum MUST NOT be all zeroes, an application 184 using UDP-Lite that wishes to have no protection of the packet 185 payload, should use a Checksum Coverage value of 8. This differs from 186 the use of UDP over IPv4, in that the minimal UDP-Lite checksum 187 always covers the UDP-Lite protocol header, which includes the 188 Checksum Coverage field. 190 3.2. Pseudo Header 192 UDP and UDP-Lite use the same conceptually prefixed pseudo header 193 from the IP layer for the checksum. This pseudo header is different 194 for IPv4 and IPv6. The pseudo header of UDP-Lite is different from 195 the pseudo header of UDP in one way: The value of the Length field of 196 the pseudo header is not taken from the UDP-Lite header, but rather 197 from information provided by the IP module. This computation is done 198 in the same manner as for TCP [RFC-793], and implies that the Length 199 field of the pseudo header includes the UDP-Lite header and all 200 subsequent octets in the IP payload. 202 3.3. Application Interface 204 An application interface should allow the same operations as for 205 UDP. In addition to this, it should provide a way for the sending 206 application to pass the Checksum Coverage value to the UDP-Lite 207 module. There should also be a way to pass the Checksum Coverage 208 value to the receiving application, or at least let the receiving 209 application block delivery of packets with coverage values less than 210 a value provided by the application. 212 It is RECOMMENDED that the default behavior of UDP-Lite be to mimic 213 UDP by having the Checksum Coverage field match the length of the 214 UDP-Lite packet, and verify the entire packet. Applications that wish 215 to define the payload as partially insensitive to bit errors (e.g. 216 error tolerant codecs using RTP [RFC-1889]) should do this by an 217 explicit system call on the sender side. Applications that wish to 218 receive payloads that were only partially covered by a checksum 219 should inform the receiving system by an explicit system call. 221 The characteristics of the links forming an Internet path may vary 222 greatly. It is therefore difficult to make assumptions about the 223 level or patterns of errors that may occur in the corruption 224 insensitive part of the UDP-Lite payload. Applications that use UDP- 225 Lite should not make any assumptions regarding the correctness of the 226 received data beyond the position indicated by the Checksum Coverage 227 field, and should if necessary introduce their own appropriate 228 validity checks. 230 3.4. IP Interface 232 As for UDP, the IP module must provide the pseudo header to the UDP- 233 Lite protocol module (known as the UDPLite module). The UDP-Lite 234 pseudo header contains the IP addresses and protocol fields of the IP 235 header, and also the length of the IP payload, which is derived from 236 the Length field in the IP header. 238 The sender IP module MUST NOT pad the IP payload with extra octets, 239 since the length of the UDP-Lite payload delivered to the receiver 240 depends on the length of the IP payload. 242 3.5. Jumbograms 244 The Checksum Coverage field is 16 bits and can represent a Checksum 245 Coverage value of up to 65535 octets. This allows arbitrary checksum 246 coverage for IP packets, unless they are Jumbograms. For Jumbograms, 247 the checksum can cover either the entire payload (when the Checksum 248 Coverage field has the value zero), or else at most the initial 65535 249 octets of the UDP-Lite packet. 251 4. Lower Layer Considerations 253 Since UDP-Lite can deliver packets with damaged payloads to an 254 application that wishes to receive them, frames carrying UDP-Lite 255 packets need not be discarded by lower layer protocols when there are 256 errors only in the insensitive part. For a link that supports partial 257 error detection, the Checksum Coverage field in the UDP-Lite header 258 MAY be used as a hint of where errors do not need to be detected. 259 Lower layers MUST use a strong error detection mechanism [LINK] to 260 detect at least errors that occur in the sensitive part of the 261 packet, and discard damaged packets. The sensitive part consists of 262 the octets between the first octet of the IP header and the last 263 octet identified by the Checksum Coverage field. The sensitive part 264 would thus be treated in exactly the same way as for a UDP packet. 266 Link layers that do not support partial error detection suitable for 267 UDP-Lite, as described above, MUST detect errors in the entire UDP- 268 Lite packet, and MUST discard damaged packets [LINK]. The whole UDP- 269 Lite packet is thus treated in exactly the same way as a UDP packet. 271 It should be noted that UDP-Lite would only make a difference to an 272 application if partial error detection, based on the partial checksum 273 feature of UDP-Lite, is implemented also by link layers, as discussed 274 above. Partial error detection at the link layer would only make a 275 difference when implemented over error-prone links. 277 5. Compatibility with UDP 279 UDP and UDP-Lite have similar syntax and semantics. Applications 280 designed for UDP may therefore use UDP-Lite instead, and will by 281 default receive the same full packet coverage. The similarities also 282 ease implementation of UDP-Lite, since only minor modifications are 283 needed to an existing UDP implementation. 285 UDP-Lite has been allocated a separate IP protocol identifier, XXXX 286 (UDPLite) [INSERT IANA NUMBER BEFORE PUBLICATION], that allows a 287 receiver to identify whether UDP or UDP-Lite is used. A destination 288 end host that is unaware of UDP-Lite will, in general, return an ICMP 289 "Protocol Unreachable" or an ICMPv6 "Payload Type Unknown" error 290 message (depending on the IP protocol type). This simple method of 291 detecting UDP-Lite unaware systems is the primary benefit of having 292 separate protocol identifiers. 294 The remainder of this section provides the rationale for allocating a 295 separate IP protocol identifier for UDP-Lite, rather than sharing the 296 IP protocol identifier with UDP. 298 There are no known interoperability problems between UDP and UDP-Lite 299 if they were to share the protocol identifier with UDP. Specifically, 300 there is no case where a potentially problematic packet is delivered 301 to an unsuspecting application; a UDP-Lite payload with partial 302 checksum coverage cannot be delivered to UDP applications, and UDP 303 packets that only partially fill the IP payload cannot be delivered 304 to applications using UDP-Lite. 306 However, if the protocol identifier were to have been shared between 307 UDP and UDP-Lite, and a UDP-Lite implementation was to send a UDP- 308 Lite packet using a partial checksum to a UDP implementation, the UDP 309 implementation would silently discard the packet, because a 310 mismatching pseudo header would cause the UDP checksum to fail. 311 Neither the sending nor the receiving application would be notified. 312 Potential solutions to this could have been: 314 1) explicit application in-band signaling (while not using the 315 partial checksum coverage option) to enable the sender to learn 316 whether the receiver is UDP-Lite enabled or not, or 318 2) use of out-of-band signaling such as H.323, SIP, or RTCP to 319 convey whether the receiver is UDP-Lite enabled. 321 Since UDP-Lite has been assigned its own IP protocol identifier, 322 there is no need to consider this possibility of delivery of a UDP- 323 Lite packet to an unsuspecting UDP port. 325 6. Security Considerations 327 The security impact of UDP-Lite is related to its interaction with 328 authentication and encryption mechanisms. When the partial checksum 329 option of UDP-Lite is enabled, the insensitive portion of a packet 330 may change in transit. This is contrary to the idea behind most 331 authentication mechanisms: authentication succeeds if the packet has 332 not changed in transit. Unless authentication mechanisms that operate 333 only on the sensitive part of packets are developed and used, 334 authentication will always fail for UDP-Lite packets where the 335 insensitive part has been damaged. 337 The IPSec integrity check (Encapsulation Security Protocol, ESP, or 338 Authentication Header, AH) is applied (at least) to the entire IP 339 packet payload. Corruption of any bit within the protected area will 340 then result in the IP receiver discarding the UDP-Lite packet. 342 When IPSEC is used with ESP payload encryption, a link can not 343 determine the specific transport protocol of a packet being forwarded 344 by inspecting the IP packet payload. In this case, the link MUST 345 provide a standard integrity check covering the entire IP packet and 346 payload. UDP-Lite provides no benefit in this case. 348 Encryption (e.g., at the transport or application levels) 349 may be used. Note that omitting an integrity check can, under 350 certain circumstances, compromise confidentiality [Bell98]. 352 If a few bits of an encrypted packet are damaged, the decryption 353 transform will typically spread errors so that the packet becomes 354 too damaged to be of use. Many encryption transforms today exhibit 355 this behavior. There exist encryption transforms, stream ciphers, 356 which do not cause error propagation. Proper use of stream ciphers 357 can be quite difficult, especially when authentication-checking is 358 omitted [BB01]. In particular, an attacker can cause predictable 359 changes to the ultimate plaintext, even without being able to 360 decrypt the ciphertext. 362 7. IANA Considerations 364 A new IP protocol number, XXXX [INSERT NUMBER BEFORE PUBLICATION], 365 has been assigned for UDP-Lite. The name associated with this 366 protocol number is "UDPLite". This ensures compatibility across a 367 wide range of platforms, since on some platforms the "-" character 368 may not form part of a protocol entity name. 370 [NOTE, REMOVE BEFORE PUBLICATION] 372 IANA assignment instruction: 373 The IANA must reserve an IP protocol number for UDP-Lite. 374 IANA - Please NOTE the name of the registry entry MUST be 375 "UDPLite", as detailed above. 377 [END OF NOTE] 378 8. References 380 8.1. Normative References 382 [RFC-768] Postel, J., "User Datagram Protocol", RFC 768 (STD6), 383 August 1980. 385 [RFC-791] Postel, J., "Internet Protocol", RFC 791 (STD5), 386 September 1981. 388 [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793 389 (STD7), September 1981. 391 [RFC-1071] Braden, R., Borman, D., and C. Partridge, "Computing the 392 Internet Checksum", RFC 1071, September 1988. 394 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", RFC 2119 (BCP15), March 1997. 397 [RFC-2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 398 (IPv6) Specification", RFC 2460, December 1998. 400 8.2. Informative References 402 [Bell98] Bellovin, S.M., "Cryptography and the Internet", 403 Proceedings of CRYPTO �98, August, 1988. 405 [BB01] Bellovin, S.M., and M. Blaze, "Cryptographic Modes of 406 Operation for the Internet", 2nd NIST Workshop on Modes 407 of Operation, August 2001. 409 [3GPP] "Technical Specification Group Services and System 410 Aspects; Quality of Service (QoS) concept and 411 architecture", TS 23.107 V5.9.0, Technical Specification 412 3rd Generation Partnership Project, June 2003. 414 [H.264] Hannuksela, M.M., T. Stockhammer, M. Westerlund. And 415 D. Singer, "RTP payload Format for H.264 Video", Internet 416 Draft, Work in Progress, March 2003. 418 [ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec", 419 draft-ietf-avt-ilbc-codec-01.txt, Internet Draft, Work in 420 Progress, March 2003. 422 [ISO-14496] ISO/IEC International Standard 1446 (MPEG-4), 423 "Information Technology � Coding of Audio-Visual 424 Objects", January 2000. 426 [ITU-H.263] "Video Coding for Low Bit Rate Communication," ITU-T 427 Recommendation H.263, January 1998. 429 [ITU-H.264] "Draft ITU-T Recommendation and Final Draft International 430 Standard of Joint Video Specification", 431 ITU-T Recommendation H.264, May 2003. 433 [LINK] Phil Karn, Editor, "Advice for Internet Subnetwork 434 Designers", Work in Progress, IETF. 436 [RFC-1889] Schulzrinne, H., Casner, S., Frederick, R., and 437 V. Jacobson, "RTP: A Transport Protocol for Real-Time 438 Applications", RFC 1889, January 1996. 440 [RFC-2026] Bradner, S., "The Internet Standards Process", RFC 2026, 441 October 1996. 443 [RFC-2402] Kent, S., and R. Atkinson, "IP Authentication Header", 444 RFC 2402, November 1998. 446 [RFC-2406] Kent, S., and R. Atkinson, "IP Encapsulating Security 447 Payload (ESP)", RFC 206, November 1998. 449 [RFC-3267] Sjoberg, J., M. Westerlund, A. Lakeaniemi, and Q. Xie, 450 "Real-Time Transport Protocol (RTP) Payload Format and 451 File Storage Format for the Adaptiove Multi-Rate (AMR) 452 and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", 453 RFC 3267, June 2002. 455 [LDP99] Larzon, L-A., Degermark, M., and S. Pink, "UDP Lite for 456 Real-Time Multimedia Applications", Proceedings of the 457 IEEE International Conference of Communications (ICC), 458 1999. 460 9. Acknowledgements 462 Thanks to Ghyslain Pelletier for significant technical and editorial 463 comments. Thanks also to Steven Bellovin, Elisabetta Carrara, and 464 Mats Naslund for reviewing the security considerations chapter, and 465 to Peter Eriksson for a language review and thereby improving the 466 clarity of this document. 468 10. Authors' Addresses 470 Lars-Ake Larzon 471 Department of CS & EE 472 Lulea University of Technology 473 S-971 87 Lulea, Sweden 474 Email: lln@cdt.luth.se 476 Mikael Degermark 477 Department of Computer Science 478 The University of Arizona 479 P.O. Box 210077 480 Tucson, AZ 85721-0077, USA 481 Email: micke@cs.arizona.edu 483 Stephen Pink 484 The University of Arizona 485 P.O. Box 210077 486 Tucson, AZ 85721-0077, USA 487 Email: steve@cs.arizona.edu 489 Lars-Erik Jonsson 490 Ericsson AB 491 Box 920 492 S-971 28 Lulea, Sweden 493 Email: lars-erik.jonsson@ericsson.com 495 Godred Fairhurst 496 Department of Engineering 497 University of Aberdeen 498 Aberdeen, AB24 3UE, UK 499 Email: gorry@erg.abdn.ac.uk 500 Full Copyright Statement 502 Copyright (C) The Internet Society (2002). All Rights Reserved. 504 This document and translations of it may be copied and furnished to 505 others, and derivative works that comment on or otherwise explain it 506 or assist in its implementation may be prepared, copied, published 507 and distributed, in whole or in part, without restriction of any 508 kind, provided that the above copyright notice and this paragraph are 509 included on all such copies and derivative works. However, this 510 document itself may not be modified in any way, such as by removing 511 the copyright notice or references to the Internet Society or other 512 Internet organizations, except as needed for the purpose of 513 developing Internet standards in which case the procedures for 514 copyrights defined in the Internet Standards process must be 515 followed, or as required to translate it into languages other than 516 English. 518 The limited permissions granted above are perpetual and will not be 519 revoked by the Internet Society or its successors or assigns. 521 This document and the information contained herein is provided on an 522 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 523 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 524 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 525 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 526 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 This Internet-Draft expires December, 2003. 530 [NOTE, REMOVE BEFORE PUBLICATION] 532 Document History 02j - This section is intended to assist the AD in 533 review of the document. It must be deleted by the RFC Editor. 535 (1) IANA Assignemnet Name chnage UDP-Lite renamed UDPLite to 536 increase the portability of the code to operating systems that 537 use the "-" character as a part of the mapping function (i.e. 538 not allowed in the protocol ID). 540 Having done this, I now worry a little that this may now divorce 541 the RFC from the previous published work --- should we also 542 refer people to UDP-Lite? 544 (2) Text added to 2nd para, section 3.1 to say pseudo header always 545 present. 547 (3) Text added to 2nd para, section 3.1 to say initial checksum value 548 is zero. 550 (4) Section 5, added IPv6 text: A destination end host that is 551 unaware of UDP-Lite will, in general, return an ICMP "Protocol 552 Unreachable" or an ICMPv6 "Payload Type Unknown" error message 553 (depending on the IP protocol type). 555 (5) BSD Code behaviour? This is a protocol problem with a BSD 556 implementation, not a spec fault. 558 (6) Examples added of applications 560 (7) Examples of systems that would use it 562 (8) Security issues (text requested by IESG). 564 (9) Minor NiTs with written English corrected. 566 (10) Introduction starts rather strangely - can we fix this? 568 (11) Security AD Text Revised, and now OK. 570 (12) Revised security note: 572 When IPSEC is used with ESP payload encryption, there is no 573 visibility of the transport header, and therefore a link can not 574 determine which transport layer protocol is used, and would not be 575 able to determine the value of the Checksum Coverage field. UDP-Lite 576 provides no benefit in this case, and the link MUST provide a 577 standard integrity check. 579 [END OF NOTE]