diff options
Diffstat (limited to 'doc/rfc/rfc3828.txt')
| -rw-r--r-- | doc/rfc/rfc3828.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3828.txt b/doc/rfc/rfc3828.txt new file mode 100644 index 0000000..f9cde96 --- /dev/null +++ b/doc/rfc/rfc3828.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group L-A. Larzon +Request for Comments: 3828 Lulea University of Technology +Category: Standards Track M. Degermark + S. Pink + The University of Arizona + L-E. Jonsson, Ed. + Ericsson + G. Fairhurst, Ed. + University of Aberdeen + July 2004 + + + The Lightweight User Datagram Protocol (UDP-Lite) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes the Lightweight User Datagram Protocol (UDP- + Lite), which is similar to the User Datagram Protocol (UDP) (RFC + 768), but can also serve applications in error-prone network + environments that prefer to have partially damaged payloads delivered + rather than discarded. If this feature is not used, UDP-Lite is + semantically identical to UDP. + + + + + + + + + + + + + + + + + +Larzon, et al. Standards Track [Page 1] + +RFC 3828 UDP-Lite Protocol July 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Pseudo Header. . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. Application Interface. . . . . . . . . . . . . . . . . . 5 + 3.4. IP Interface . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5. Jumbograms . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 6 + 5. Compatibility with UDP . . . . . . . . . . . . . . . . . . . . 7 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 8 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 8.2. Informative References . . . . . . . . . . . . . . . . . 9 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 + 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + This document describes a new transport protocol, UDP-Lite, (also + known as UDPLite). This new protocol is based on three observations: + + First, there is a class of applications that benefit from having + damaged data delivered rather than discarded by the network. A + number of codecs for voice and video fall into this class (e.g., the + AMR speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC], + and error resilient H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264], and + MPEG-4 [ISO-14496] video codecs). These codecs may be designed to + cope better with errors in the payload than with loss of entire + packets. + + Second, all links that support IP transmission should use a strong + link layer integrity check (e.g., CRC-32 [RFC-3819]), and this MUST + be used by default for IP traffic. When the under-lying link + supports it, certain types of traffic (e.g., UDP-Lite) may benefit + from a different link behavior that permits partially damaged IP + packets to be forwarded when requested [RFC-3819]. Several radio + technologies (e.g., [3GPP]) support this link behavior when operating + at a point where cost and delay are sufficiently low. If error-prone + links are aware of the error sensitive portion of a packet, it is + also possible for the physical link to provide greater protection to + reduce the probability of corruption of these error sensitive bytes + (e.g., the use of unequal Forward Error Correction). + + + + +Larzon, et al. Standards Track [Page 2] + +RFC 3828 UDP-Lite Protocol July 2004 + + + Third, intermediate layers (i.e., IP and the transport layer + protocols) should not prevent error-tolerant applications from + running well in the presence of such links. IP is not a problem in + this regard, since the IP header has no checksum that covers the IP + payload. The generally available transport protocol best suited for + these applications is UDP, since it has no overhead for + retransmission of erroneous packets, in-order delivery, or error + correction. In IPv4 [RFC-791], the UDP checksum covers either the + entire packet or nothing at all. In IPv6 [RFC-2460], the UDP + checksum is mandatory and must not be disabled. The IPv6 header does + not have a header checksum and it was deemed necessary to always + protect the IP addressing information by making the UDP checksum + mandatory. + + A transport protocol is needed that conforms to the properties of + link layers and applications described above [LDP99]. The error- + detection mechanism of the transport layer must be able to protect + vital information such as headers, but also to optionally ignore + errors best dealt with by the application. The set of octets to be + verified by the checksum is best specified by the sending + application. + + UDP-Lite provides a checksum with an optional partial coverage. When + using this option, a packet is divided into a sensitive part (covered + by the checksum) and an insensitive part (not covered by the + checksum). Errors in the insensitive part will not cause the packet + to be discarded by the transport layer at the receiving end host. + When the checksum covers the entire packet, which should be the + default, UDP-Lite is semantically identical to UDP. + + Compared to UDP, the UDP-Lite partial checksum provides extra + flexibility for applications that want to define the payload as + partially insensitive to bit errors. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +3. Protocol Description + + The UDP-Lite header is shown in figure 1. Its format differs from + UDP in that the Length field has been replaced with a Checksum + Coverage field. This can be done since information about UDP packet + length can be provided by the IP module in the same manner as for TCP + [RFC-793]. + + + + +Larzon, et al. Standards Track [Page 3] + +RFC 3828 UDP-Lite Protocol July 2004 + + + 0 15 16 31 + +--------+--------+--------+--------+ + | Source | Destination | + | Port | Port | + +--------+--------+--------+--------+ + | Checksum | | + | Coverage | Checksum | + +--------+--------+--------+--------+ + | | + : Payload : + | | + +-----------------------------------+ + + Figure 1: UDP-Lite Header Format + +3.1. Fields + + The fields Source Port and Destination Port are defined as in the UDP + specification [RFC-768]. UDP-Lite uses the same set of port number + values assigned by the IANA for use by UDP. + + Checksum Coverage is the number of octets, counting from the first + octet of the UDP-Lite header, that are covered by the checksum. The + UDP-Lite header MUST always be covered by the checksum. Despite this + requirement, the Checksum Coverage is expressed in octets from the + beginning of the UDP-Lite header in the same way as for UDP. A + Checksum Coverage of zero indicates that the entire UDP-Lite packet + is covered by the checksum. This means that the value of the + Checksum Coverage field MUST be either 0 or at least 8. A UDP-Lite + packet with a Checksum Coverage value of 1 to 7 MUST be discarded by + the receiver. Irrespective of the Checksum Coverage, the computed + Checksum field MUST include a pseudo-header, based on the IP header + (see below). UDP-Lite packets with a Checksum Coverage greater than + the IP length MUST also be discarded. + + The Checksum field is the 16-bit one's complement of the one's + complement sum of a pseudo-header of information collected from the + IP header, the number of octets specified by the Checksum Coverage + (starting at the first octet in the UDP-Lite header), virtually + padded with a zero octet at the end (if necessary) to make a multiple + of two octets [RFC-1071]. Prior to computation, the checksum field + MUST be set to zero. If the computed checksum is 0, it is + transmitted as all ones (the equivalent in one's complement + arithmetic). + + Since the transmitted checksum MUST NOT be all zeroes, an application + using UDP-Lite that wishes to have no protection of the packet + payload should use a Checksum Coverage value of 8. This differs + + + +Larzon, et al. Standards Track [Page 4] + +RFC 3828 UDP-Lite Protocol July 2004 + + + from the use of UDP over IPv4 in that the minimal UDP-Lite checksum + always covers the UDP-Lite protocol header, which includes the + Checksum Coverage field. + +3.2. Pseudo Header + + UDP and UDP-Lite use the same conceptually prefixed pseudo header + from the IP layer for the checksum. This pseudo header is different + for IPv4 and IPv6. The pseudo header of UDP-Lite is different from + the pseudo header of UDP in one way: The value of the Length field of + the pseudo header is not taken from the UDP-Lite header, but rather + from information provided by the IP module. This computation is done + in the same manner as for TCP [RFC-793], and implies that the Length + field of the pseudo header includes the UDP-Lite header and all + subsequent octets in the IP payload. + +3.3. Application Interface + + An application interface should allow the same operations as for UDP. + In addition to this, it should provide a way for the sending + application to pass the Checksum Coverage value to the UDP-Lite + module. There should also be a way to pass the Checksum Coverage + value to the receiving application, or at least let the receiving + application block delivery of packets with coverage values less than + a value provided by the application. + + It is RECOMMENDED that the default behavior of UDP-Lite be set to + mimic UDP by having the Checksum Coverage field match the length of + the UDP-Lite packet and verify the entire packet. Applications that + wish to define the payload as partially insensitive to bit errors + (e.g., error tolerant codecs using RTP [RFC-3550]) should do this by + an explicit system call on the sender side. Applications that wish + to receive payloads that were only partially covered by a checksum + should inform the receiving system by an explicit system call. + + The characteristics of the links forming an Internet path may vary + greatly. It is therefore difficult to make assumptions about the + level or patterns of errors that may occur in the corruption + insensitive part of the UDP-Lite payload. Applications that use + UDP-Lite should not make any assumptions regarding the correctness of + the received data beyond the position indicated by the Checksum + Coverage field, and should, if necessary, introduce their own + appropriate validity checks. + + + + + + + + +Larzon, et al. Standards Track [Page 5] + +RFC 3828 UDP-Lite Protocol July 2004 + + +3.4. IP Interface + + As for UDP, the IP module must provide the pseudo header to the UDP- + Lite protocol module (known as the UDPLite module). The UDP-Lite + pseudo header contains the IP addresses and protocol fields of the IP + header, and also the length of the IP payload, which is derived from + the Length field in the IP header. + + The sender IP module MUST NOT pad the IP payload with extra octets, + since the length of the UDP-Lite payload delivered to the receiver + depends on the length of the IP payload. + +3.5. Jumbograms + + The Checksum Coverage field is 16 bits and can represent a Checksum + Coverage value of up to 65535 octets. This allows arbitrary checksum + coverage for IP packets, unless they are Jumbograms. For Jumbograms, + the checksum can cover either the entire payload (when the Checksum + Coverage field has the value zero), or else at most the initial 65535 + octets of the UDP-Lite packet. + +4. Lower Layer Considerations + + Since UDP-Lite can deliver packets with damaged payloads to an + application that wishes to receive them, frames carrying UDP-Lite + packets need not be discarded by lower layer protocols when there are + errors only in the insensitive part. For a link that supports + partial error detection, the Checksum Coverage field in the UDP-Lite + header MAY be used as a hint of where errors do not need to be + detected. Lower layers MUST use a strong error detection mechanism + [RFC-3819] to detect at least errors that occur in the sensitive part + of the packet, and discard damaged packets. The sensitive part + consists of the octets between the first octet of the IP header and + the last octet identified by the Checksum Coverage field. The + sensitive part would thus be treated in exactly the same way as for a + UDP packet. + + Link layers that do not support partial error detection suitable for + UDP-Lite, as described above, MUST detect errors in the entire UDP- + Lite packet, and MUST discard damaged packets [RFC-3819]. The whole + UDP-Lite packet is thus treated in exactly the same way as a UDP + packet. + + It should be noted that UDP-Lite would only make a difference to an + application if partial error detection, based on the partial checksum + feature of UDP-Lite, is implemented also by link layers, as discussed + above. Partial error detection at the link layer would only make a + difference when implemented over error-prone links. + + + +Larzon, et al. Standards Track [Page 6] + +RFC 3828 UDP-Lite Protocol July 2004 + + +5. Compatibility with UDP + + UDP and UDP-Lite have similar syntax and semantics. Applications + designed for UDP may therefore use UDP-Lite instead, and will by + default receive the same full packet coverage. The similarities also + ease implementation of UDP-Lite, since only minor modifications are + needed to an existing UDP implementation. + + UDP-Lite has been allocated a separate IP protocol identifier, 136 + (UDPLite), that allows a receiver to identify whether UDP or UDP-Lite + is used. A destination end host that is unaware of UDP-Lite will, in + general, return an ICMP "Protocol Unreachable" or an ICMPv6 "Payload + Type Unknown" error message (depending on the IP protocol type). + This simple method of detecting UDP-Lite unaware systems is the + primary benefit of having separate protocol identifiers. + + The remainder of this section provides the rationale for allocating a + separate IP protocol identifier for UDP-Lite, rather than sharing the + IP protocol identifier with UDP. + + There are no known interoperability problems between UDP and UDP-Lite + if they were to share the protocol identifier with UDP. + Specifically, there is no case where a potentially problematic packet + is delivered to an unsuspecting application; a UDP-Lite payload with + partial checksum coverage cannot be delivered to UDP applications, + and UDP packets that only partially fill the IP payload cannot be + delivered to applications using UDP-Lite. + + However, if the protocol identifier were to have been shared between + UDP and UDP-Lite, and a UDP-Lite implementation was to send a UDP- + Lite packet using a partial checksum to a UDP implementation, the UDP + implementation would silently discard the packet, because a + mismatching pseudo header would cause the UDP checksum to fail. + Neither the sending nor the receiving application would be notified. + Potential solutions to this could have been: + + 1) explicit application in-band signaling (while not using the + partial checksum coverage option) to enable the sender to learn + whether the receiver is UDP-Lite enabled or not, or + + 2) use of out-of-band signaling such as H.323, SIP, or RTCP to convey + whether the receiver is UDP-Lite enabled. + + Since UDP-Lite has been assigned its own IP protocol identifier, + there is no need to consider this possibility of delivery of a UDP- + Lite packet to an unsuspecting UDP port. + + + + + +Larzon, et al. Standards Track [Page 7] + +RFC 3828 UDP-Lite Protocol July 2004 + + +6. Security Considerations + + The security impact of UDP-Lite is related to its interaction with + authentication and encryption mechanisms. When the partial checksum + option of UDP-Lite is enabled, the insensitive portion of a packet + may change in transit. This is contrary to the idea behind most + authentication mechanisms: authentication succeeds if the packet has + not changed in transit. Unless authentication mechanisms that + operate only on the sensitive part of packets are developed and used, + authentication will always fail for UDP-Lite packets where the + insensitive part has been damaged. + + The IPsec integrity check (Encapsulation Security Protocol, ESP + [RFC-2406], or Authentication Header, AH [RFC-2402]) is applied (at + least) to the entire IP packet payload. Corruption of any bit within + the protected area will then result in the IP receiver discarding the + UDP-Lite packet. + + When IPsec is used with ESP payload encryption, a link can not + determine the specific transport protocol of a packet being forwarded + by inspecting the IP packet payload. In this case, the link MUST + provide a standard integrity check covering the entire IP packet and + payload. UDP-Lite provides no benefit in this case. + + Encryption (e.g., at the transport or application levels) may be + used. If a few bits of an encrypted packet are damaged, the + decryption transform will typically spread errors so that the packet + becomes too damaged to be of use. Many encryption transforms today + exhibit this behavior. There exist encryption transforms, and stream + ciphers, which do not cause error propagation. Note that omitting an + integrity check can, under certain circumstances, compromise + confidentiality [Bellovin98]. Proper use of stream ciphers poses its + own challenges [BB01]. In particular, an attacker can cause + predictable changes to the ultimate plaintext, even without being + able to decrypt the ciphertext. + +7. IANA Considerations + + A new IP protocol number, 136 has been assigned for UDP-Lite. The + name associated with this protocol number is "UDPLite". This ensures + compatibility across a wide range of platforms, since on some + platforms the "-" character may not form part of a protocol entity + name. + + + + + + + + +Larzon, et al. Standards Track [Page 8] + +RFC 3828 UDP-Lite Protocol July 2004 + + +8. References + +8.1. Normative References + + [RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the + Internet Checksum", RFC 1071, September 1988. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + +8.2. Informative References + + [Bellovin98] Bellovin, S.M., "Cryptography and the Internet", in + Proceedings of CRYPTO '98, August 1988. + + [BB01] Bellovin, S. and M. Blaze, "Cryptographic Modes of + Operation for the Internet", Second NIST Workshop on + Modes of Operation, August 2001. + + [3GPP] "Technical Specification Group Services and System + Aspects; Quality of Service (QoS) concept and + architecture", TS 23.107 V5.9.0, Technical Specification + 3rd Generation Partnership Project, June 2003. + + [H.264] Hannuksela, M.M., Stockhammer, T., Westerlund, M. and D. + Singer, "RTP payload Format for H.264 Video", Internet + Draft, Work in Progress, March 2003. + + [ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec", + Work in Progress, March 2003. + + [ISO-14496] ISO/IEC International Standard 1446 (MPEG-4), + "Information Technology Coding of Audio-Visual Objects", + January 2000. + + + + + +Larzon, et al. Standards Track [Page 9] + +RFC 3828 UDP-Lite Protocol July 2004 + + + [ITU-H.263] "Video Coding for Low Bit Rate Communication," ITU-T + Recommendation H.263, January 1998. + + [ITU-H.264] "Draft ITU-T Recommendation and Final Draft + International Standard of Joint Video Specification", + ITU-T Recommendation H.264, May 2003. + + [RFC-3819] Karn, Ed., P., Bormann, C., Fairhurst, G., Grossman, D., + Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and + L. Wood, "Advice for Internet Subnetwork Designers", BCP + 89, RFC 3819, July 2004. + + [RFC-3550] Schulzrinne, H., Casner, S., Frederick, R. and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", RFC 3550, July 2003. + + [RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", + RFC 2402, November 1998. + + [RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + [RFC-3267] Sjoberg, J., Westerlund, M., Lakeaniemi, A. and Q. Xie, + "Real-Time Transport Protocol (RTP) Payload Format and + File Storage Format for the Adaptive Multi-Rate (AMR) + and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", + RFC 3267, June 2002. + + [LDP99] Larzon, L-A., Degermark, M. and S. Pink, "UDP Lite for + Real-Time Multimedia Applications", Proceedings of the + IEEE International Conference of Communications (ICC), + 1999. + +9. Acknowledgements + + Thanks to Ghyslain Pelletier for significant technical and editorial + comments. Thanks also to Steven Bellovin, Elisabetta Carrara, and + Mats Naslund for reviewing the security considerations chapter, and + to Peter Eriksson for a language review, thereby improving the + clarity of this document. + + + + + + + + + + + +Larzon, et al. Standards Track [Page 10] + +RFC 3828 UDP-Lite Protocol July 2004 + + +10. Authors' Addresses + + Lars-Ake Larzon + Department of CS & EE + Lulea University of Technology + S-971 87 Lulea, Sweden + + EMail: lln@csee.ltu.se + + + Mikael Degermark + Department of Computer Science + The University of Arizona + P.O. Box 210077 + Tucson, AZ 85721-0077, USA + + EMail: micke@cs.arizona.edu + + + Stephen Pink + The University of Arizona + P.O. Box 210077 + Tucson, AZ 85721-0077, USA + + EMail: steve@cs.arizona.edu + + + Lars-Erik Jonsson + Ericsson AB + Box 920 + S-971 28 Lulea, Sweden + + EMail: lars-erik.jonsson@ericsson.com + + + Godred Fairhurst + Department of Engineering + University of Aberdeen + Aberdeen, AB24 3UE, UK + + EMail: gorry@erg.abdn.ac.uk + + + + + + + + + + +Larzon, et al. Standards Track [Page 11] + +RFC 3828 UDP-Lite Protocol July 2004 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Larzon, et al. Standards Track [Page 12] + |