--- 1/draft-ietf-6man-udpzero-11.txt 2013-02-26 03:31:58.899791564 +0100 +++ 2/draft-ietf-6man-udpzero-12.txt 2013-02-26 03:31:58.967791168 +0100 @@ -1,20 +1,20 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft University of Aberdeen Intended status: Standards Track M. Westerlund -Expires: August 25, 2013 Ericsson - February 21, 2013 +Expires: August 29, 2013 Ericsson + February 25, 2013 Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums - draft-ietf-6man-udpzero-11 + draft-ietf-6man-udpzero-12 Abstract This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations and examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 25, 2013. + This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,57 +62,57 @@ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5 1.3.1. Motivation for new approaches . . . . . . . . . . . . 6 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 1.3.3. Need to inspect the entire packet . . . . . . . . . . 7 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7 1.3.5. Support for load balancing . . . . . . . . . . . . . . 8 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 9 + 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10 2.4. Relation to UDP-Lite and UDP with checksum . . . . . . . . 10 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12 - 3.1. Effect of packet modification in the network . . . . . . . 12 + 3.1. Effect of packet modification in the network . . . . . . . 13 3.1.1. Corruption of the destination IP address . . . . . . . 14 - 3.1.2. Corruption of the source IP address . . . . . . . . . 14 + 3.1.2. Corruption of the source IP address . . . . . . . . . 15 3.1.3. Corruption of Port Information . . . . . . . . . . . . 16 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 16 3.1.5. Corruption of Fragmentation Information . . . . . . . 17 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 19 3.3. Validating the network path . . . . . . . . . . . . . . . 20 3.4. Applicability of method . . . . . . . . . . . . . . . . . 21 3.5. Impact on non-supporting devices or applications . . . . . 21 4. Constraints on implementation of IPv6 nodes supporting zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 22 - 5. Requirements on usage of the zero UDP checksum . . . . . . . . 23 + 5. Requirements on usage of the zero UDP checksum . . . . . . . . 24 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Evaluation of proposal to update RFC 2460 to support zero checksum . . . . . . . . . . . . . . . . 31 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 31 - A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 32 + A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 33 - A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 33 + A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 34 A.2.3. Ingress and Egress Performance Implications . . . . . 34 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 34 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 35 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 35 - Appendix B. Document Change History . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 + Appendix B. Document Change History . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction The User Datagram Protocol (UDP) [RFC0768] transport is defined for the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The UDP transport protocol has a minimal set of features. This limited set has enabled a wide range of applications to use UDP, but these application do need to provide many important transport functions on top of UDP. The UDP Usage Guidelines [RFC5405] provides overall @@ -225,26 +225,21 @@ o Reducing forwarding costs, motivated by redundancy present in the encapsulated packet header, since in tunnel encapsulations, payload integrity and length verification may be provided by higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, or TCP checksums). o Eliminating a need to access the entire packet when forwarding the packet by a tunnel endpoint. - o Enhancing ability to traverse middleboxes, especially Network - Address Translators, NATs. However, use of the zero UDP checksum - does not fully fulfill this need, because only certain classes of - middleboxes, (i.e. ones that do not modify or evaluate the UDP - checksum) will support zero UDP checksum traffic, other - middleboxes will require an update to support this traffic. + o Enhancing ability to traverse and function with middleboxes. o A desire to use the port number space to enable load-sharing. 1.3.2. Reducing forwarding cost It is a common requirement to terminate a large number of tunnels on a single router/host. The processing cost per tunnel includes both state (memory requirements) and per-packet processing at the tunnel ingress and egress. @@ -284,27 +279,37 @@ prevents fast processing of a transport checksum over an entire (large) packet. Hence the currently defined IPv6 UDP checksum is poorly suited to use within a router that is unable to access the entire packet and does not provide checksum-offloading. Thus enabling checksum calculation over the complete packet can impact router design, performance improvement, energy consumption and/or cost. 1.3.4. Interactions with middleboxes - In IPv4, UDP-encapsulation may be desirable for NAT traversal, since - UDP support is commonly provided. It is also necessary due to the - almost ubiquitous deployment of IPv4 NATs. There has also been - discussion of NAT for IPv6, although not for the same reason as in - IPv4. If IPv6 NAT becomes a reality they hopefully do not present - the same protocol issues as for IPv4. If NAT is defined for IPv6, it - should take into consideration the use of a zero UDP checksum. + Many paths in the Internet include one or more middleboxes of various + types. There exist large classes of middleboxes that will handle + zero UDP checksum packets, which would not support UDP-Lite or the + other investigated proposals. These middleboxes includes load + balancers (see Section 1.3.5) including Equal Cost Multipath Routing, + traffic classifiers and other functions that reads some fields in the + UDP headers but does not validate the UDP checksum. + + There are also middleboxes that either validates or modify the UDP + checksum. The two most common classes are Firewalls and NATs. In + IPv4, UDP-encapsulation may be desirable for NAT traversal, since UDP + support is commonly provided. It is also necessary due to the almost + ubiquitous deployment of IPv4 NATs. There has also been discussion + of NAT for IPv6, although not for the same reason as in IPv4. If + IPv6 NAT becomes a reality they hopefully do not present the same + protocol issues as for IPv4. If NAT is defined for IPv6, it should + take into consideration the use of a zero UDP checksum. The requirements for IPv6 firewall traversal are likely be to be similar to those for IPv4. In addition, it can be reasonably expected that a firewall conforming to RFC 2460 will not regard datagrams with a zero UDP checksum as valid. Use of a zero UDP checksum with IPv6 requires firewalls to be updated before the full utility of the change is available. It can be expected that datagrams with zero UDP checksum will initially not have the same middlebox traversal characteristics as @@ -881,28 +887,36 @@ packets that change the set of routers and middleboxes along a path. Therefore transports such as TCP, SCTP and DCCP have been designed to negotiate protocol parameters, adapt to different network path characteristics, and receive feedback to verify that the current path is suited to the intended application. Applications using UDP and UDP-Lite need to provide their own mechanisms to confirm the validity of the current network path. A zero value in the UDP checksum field is explicitly disallowed in RFC2460. Thus it may be expected that any device on the path that - has a reason to look beyond the IP header will consider such a packet - as erroneous or illegal and may discard it, unless the device is - updated to support the new behavior. A pair of end-points intending - to use a new behavior will therefore not only need to ensure support - at each end-point, but also that the path between them will deliver - packets with the new behavior. This may require using negotiation or - an explicit mandate to use the new behavior by all nodes that support - the new protocol. + has a reason to look beyond the IP header, for example to validate + the UDP checksum, will consider such a packet as erroneous or illegal + and may discard it, unless the device is updated to support the new + behavior. Any middlebox that modifies the UDP checksum, for example + a NAT that changes the values of the IP and UDP header in such a way + that the checksum over the pseudo header changes value, will need to + be updated to support this behavior. Until then, a zero UDP checksum + packet is likely to be discarded either directly in the middlebox or + at the destination, when a zero UDP checksum has been modified to a + non-zero by an incremental update. + + A pair of end-points intending to use a new behavior will therefore + not only need to ensure support at each end-point, but also that the + path between them will deliver packets with the new behavior. This + may require using negotiation or an explicit mandate to use the new + behavior by all nodes that support the new protocol. Enabling the use of a zero checksum places new requirements on equipment deployed within the network, such as middleboxes. A middlebox (e.g. Firewalls, Network Address Translators) may enable zero checksum usage for a particular range of ports. Note that checksum off-loading and operating system design may result in all IPv6 UDP traffic being sent with a calculated checksum. This requires middleboxes that are configured to enable a zero UDP checksum to continue to work with bidirectional UDP flows that use a zero UDP checksum in only one direction, and therefore they must not @@ -1304,22 +1318,22 @@ nodes and middleboxes must forward received UDP datagrams that have either a calculated checksum or a zero checksum. 10. References 10.1. Normative References [I-D.ietf-6man-udpchecksums] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", - draft-ietf-6man-udpchecksums-07 (work in progress), - January 2013. + draft-ietf-6man-udpchecksums-08 (work in progress), + February 2013. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.