--- 1/draft-ietf-6man-udpzero-05.txt 2012-06-20 16:14:21.197426205 +0200 +++ 2/draft-ietf-6man-udpzero-06.txt 2012-06-20 16:14:21.261427941 +0200 @@ -1,19 +1,19 @@ Internet Engineering Task Force G. Fairhurst Internet-Draft University of Aberdeen Intended status: Informational M. Westerlund -Expires: June 25, 2012 Ericsson - December 23, 2011 +Expires: December 20, 2012 Ericsson + June 20, 2012 IPv6 UDP Checksum Considerations - draft-ietf-6man-udpzero-05 + draft-ietf-6man-udpzero-06 Abstract This document examines the role of the UDP transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with @@ -29,87 +29,86 @@ 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 June 25, 2012. + This Internet-Draft will expire on December 20, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + 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 carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.2.1. The Role of a Transport Endpoint . . . . . . . . . . . 5 - 1.2.2. The UDP Checksum . . . . . . . . . . . . . . . . . . . 5 - 1.2.3. Differences between IPv6 and IPv4 . . . . . . . . . . 7 - 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 7 - 1.3.1. Motivation for new approaches . . . . . . . . . . . . 8 - 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 8 - 1.3.3. Need to inspect the entire packet . . . . . . . . . . 9 - 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 9 - 1.3.5. Support for load balancing . . . . . . . . . . . . . . 10 - 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 10 - 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 10 - 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 11 - 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 11 - 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 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.3. Corruption of Port Information . . . . . . . . . . . . 15 - 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15 - 3.1.5. Corruption of Fragmentation Information . . . . . . . 16 - 3.2. Validating the network path . . . . . . . . . . . . . . . 18 - 3.3. Applicability of method . . . . . . . . . . . . . . . . . 19 - 3.4. Impact on non-supporting devices or applications . . . . . 20 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2.1. The Role of a Transport Endpoint . . . . . . . . . . . 4 + 1.2.2. The UDP Checksum . . . . . . . . . . . . . . . . . . . 4 + 1.2.3. Differences between IPv6 and IPv4 . . . . . . . . . . 6 + 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6 + 1.3.1. Motivation for new approaches . . . . . . . . . . . . 6 + 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 7 + 1.3.3. Need to inspect the entire packet . . . . . . . . . . 8 + 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 8 + 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 . . . . . . . 10 + 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10 + 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 11 + 3.1. Effect of packet modification in the network . . . . . . . 11 + 3.1.1. Corruption of the destination IP address . . . . . . . 12 + 3.1.2. Corruption of the source IP address . . . . . . . . . 13 + 3.1.3. Corruption of Port Information . . . . . . . . . . . . 14 + 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 14 + 3.1.5. Corruption of Fragmentation Information . . . . . . . 15 + 3.2. Validating the network path . . . . . . . . . . . . . . . 17 + 3.3. Applicability of method . . . . . . . . . . . . . . . . . 18 + 3.4. Impact on non-supporting devices or applications . . . . . 19 4. Evaluation of proposal to update RFC 2460 to support zero - checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1. Alternatives to the Standard Checksum . . . . . . . . . . 20 - 4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 22 - 4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 22 - 4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 23 - 4.2.3. Ingress and Egress Performance Implications . . . . . 23 - 4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 23 - 4.2.5. Corruption Detection Strength . . . . . . . . . . . . 24 - 4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 24 - 5. Requirements on the specification of transported protocols . . 26 - 5.1. Constraints required on usage of a zero checksum . . . . . 27 - 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 - Appendix A. Document Change History . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. Alternatives to the Standard Checksum . . . . . . . . . . 19 + 4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 21 + 4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 22 + 4.2.3. Ingress and Egress Performance Implications . . . . . 22 + 4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 22 + 4.2.5. Corruption Detection Strength . . . . . . . . . . . . 23 + 4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 23 + 5. Requirements on the specification of transported protocols . . 25 + 5.1. Constraints required on usage of a zero checksum . . . . . 25 + 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 10.2. Informative References . . . . . . . . . . . . . . . . . 29 + Appendix A. Document Change History . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 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 @@ -189,24 +188,23 @@ internal state. o Pre-filtering by the endpoint of erroneous data, to protect the transport from unnecessary processing and from corruption that it can not itself reject. o Pre-filtering of incorrectly addressed destination packets, before responding to a source address. 1.2.2. The UDP Checksum - UDP, as defined in [RFC0768], supports two checksum behaviours when - used with IPv4. The normal behaviour is for the sender to calculate - a checksum over a block of data that includes a pseudo header and the + used with IPv4. The normal behaviour is for the sender to calculate a + checksum over a block of data that includes a pseudo header and the UDP datagram payload. The UDP header includes a 16-bit one's complement checksum that provides a statistical guarantee that the payload was not corrupted in transit. This also allows a receiver to verify that the endpoint was the intended destination of the datagram, because the transport pseudo header covers the IP addresses, port numbers, transport payload length, and Next Header/ Protocol value corresponding to the UDP transport protocol [RFC1071]. The length field verifies that the datagram is not truncated or padded. The checksum therefore protects an application against receiving corrupted payload data in place of, or in addition to, the @@ -281,26 +279,26 @@ [RFC2460] when endpoint applications transmit UDP datagrams over IPv6. 1.3. Use of UDP Tunnels One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by the middleboxes that may exist along the path, - because many middleboxes support transmission using UDP. In this - use, the receiving endpoint decapsulates the UDP datagrams and - forwards the original packets contained in the payload [RFC5405]. - Tunnels establish virtual links that appear to directly connect - locations that are distant in the physical Internet topology and can - be used to create virtual (private) networks. + because many middleboxes support transmission using UDP. In this use, + the receiving endpoint decapsulates the UDP datagrams and forwards + the original packets contained in the payload [RFC5405]. Tunnels + establish virtual links that appear to directly connect locations + that are distant in the physical Internet topology and can be used to + create virtual (private) networks. 1.3.1. Motivation for new approaches A number of tunnel encapsulations deployed over IPv4 have used the UDP transport with a zero checksum. Users of these protocols expect a similar solution for IPv6. A number of tunnel protocols are also currently being defined (e.g. Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast], and the Locator/Identifier Separation Protocol, LISP [LISP]). These @@ -321,32 +319,32 @@ Address Translators, NATs. 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. Processing per tunnel concerns both state (memory requirements) and per-packet processing costs. - Automatic IP Multicast Tunneling, known as AMT - [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the - transport protocol for packets carrying tunneled IP multicast - packets. The current specification for AMT requires that the UDP - checksum in the outer packet header should be 0 (see Section 6.6 of - [I-D.ietf-mboned-auto-multicast]). It argues that the computation of - an additional checksum, when an inner packet is already adequately - protected, is an unwarranted burden on nodes implementing lightweight - tunneling protocols. The AMT protocol needs to replicate a multicast - packet to each gateway tunnel. In this case, the outer IP addresses - are different for each tunnel and therefore require a different - pseudo header to be built for each UDP replicated encapsulation. + Automatic IP Multicast Tunneling, known as AMT [I-D.ietf-mboned-auto- + multicast] currently specifies UDP as the transport protocol for + packets carrying tunneled IP multicast packets. The current + specification for AMT requires that the UDP checksum in the outer + packet header should be 0 (see Section 6.6 of [I-D.ietf-mboned-auto- + multicast]). It argues that the computation of an additional + checksum, when an inner packet is already adequately protected, is an + unwarranted burden on nodes implementing lightweight tunneling + protocols. The AMT protocol needs to replicate a multicast packet to + each gateway tunnel. In this case, the outer IP addresses are + different for each tunnel and therefore require a different pseudo + header to be built for each UDP replicated encapsulation. The argument concerning redundant processing costs is valid regarding the integrity of a tunneled packet. In some architectures (e.g. PC- based routers), other mechanisms may also significantly reduce checksum processing costs: There are implementations that have optimised checksum processing algorithms, including the use of checksum-offloading. This processing is readily available for IPv4 packets at high line rates. Such processing may be anticipated for IPv6 endpoints, allowing receivers to reject corrupted packets without further processing. However, there are certain classes of @@ -364,60 +362,60 @@ 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 + 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 UDP zero checksum into consideration. 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 UDP - datagrams with a zero checksum as valid packets. If a zero-checksum - for UDP were to be allowed for IPv6, this would need firewalls to be - updated before full utility of the change is available. + similar to those for IPv4. In addition, it can be reasonably expected + that a firewall conforming to RFC 2460 will not regard UDP datagrams + with a zero checksum as valid packets. If a zero-checksum for UDP + were to be allowed for IPv6, this would need firewalls to be updated + before full utility of the change is available. It can be expected that UDP with zero-checksum will initially not have the same middlebox traversal characteristics as regular UDP. However, if standardized we can expect an improvement over time of - the traversal capabilities. We also note that deployment of IPv6- - capable middleboxes is still in its initial phases. Thus, it might - be that the number of non-updated boxes quickly become a very small - percentage of the deployed middleboxes. + the traversal capabilities. We also note that deployment of + IPv6-capable middleboxes is still in its initial phases. Thus, it + might be that the number of non-updated boxes quickly become a very + small percentage of the deployed middleboxes. 1.3.5. Support for load balancing The UDP port number fields have been used as a basis to design load- balancing solutions for IPv4. This approach has also been leveraged - for IPv6. An alternate method would be to utilise the IPv6 Flow - Label as basis for entropy for the load balancing. This would have - the desirable effect of releasing IPv6 load-balancing devices from - the need to assume semantics for the use of the transport port field - and also works for all type of transport protocols. This use of the + for IPv6. An alternate method would be to utilise the IPv6 Flow Label + as basis for entropy for the load balancing. This would have the + desirable effect of releasing IPv6 load-balancing devices from the + need to assume semantics for the use of the transport port field and + also works for all type of transport protocols. This use of the flow-label is consistent with the intended use, although further clarity may be needed to ensure the field can be consistently used for this purpose, (e.g. Equal-Cost Multi-Path routing, ECMP [ECMP]). Router vendors could be encouraged to start using the IPv6 Flow Label as a part of the flow hash, providing support for ECMP without requiring use of UDP. However, the method for populating the outer IPv6 header with a value for the flow label is not trivial: If the inner packet uses IPv6, then the flow label value could be copied to the outer packet header. However, many current end-points set the - flow label to a zero value (thus no entropy). The ingress of a - tunnel seeking to provide good entropy in the flow label field would + flow label to a zero value (thus no entropy). The ingress of a tunnel + seeking to provide good entropy in the flow label field would therefore need to create a random flow label value and keep corresponding state, so that all packets that were associated with a flow would be consistently given the same flow label. Although possible, this complexity may not be desirable in a tunnel ingress. The end-to-end use of flow labels for load balancing is a long-term solution. Even if the usage of the flow label is clarified, there would be a transition time before a significant proportion of end- points start to assign a good quality flow label to the flows that they originate, with continued use of load balancing using the @@ -460,39 +458,39 @@ cover the insensitive part with the same strong layer 2 frame CRC that covers the sensitive part. 2.2.1. Using UDP-Lite as a Tunnel Encapsulation Tunnel encapsulations can use UDP-Lite (e.g. Control And Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Lite provides a transport-layer checksum, including an IP pseudo header checksum, in IPv6, without the need for a router/middelbox to traverse the entire packet payload. This provides most of the - delivery verifications and still keeps the complexity of the - checksumming operation low. UDP-Lite may set the length of checksum - coverage on a per packet basis. This feature could be used if a - tunnel protocol is designed to only verify delivery of the tunneled - payload and uses full checksumming for control information. + verification required for delivery and still keeps the complexity of + the checksumming operation low. UDP-Lite may set the length of + checksum coverage on a per packet basis. This feature could be used + if a tunnel protocol is designed to only verify delivery of the + tunneled payload and uses full checksumming for control information. There is currently poor support for middlebox traversal using UDP- Lite, because UDP-Lite uses a different IPv6 network-layer Next Header value to that of UDP, and few middleboxes are able to interpret UDP-Lite and take appropriate actions when forwarding the packet. This makes UDP-Lite less suited to protocols needing general Internet support, until such time that UDP-Lite has achieved better support in middleboxes and end-points. 2.3. General Tunnel Encapsulations The IETF has defined a set of tunneling protocols or network layer - encapsulations, e.g., IP-in-IP and GRE. These either do not include - a checksum or use a checksum that is optional, since tunnel + encapsulations, e.g., IP-in-IP and GRE. These either do not include a + checksum or use a checksum that is optional, since tunnel encapsulations are typically layered directly over the Internet layer (identified by the upper layer type in the IPv6 Next Header field) and are also not used as endpoint transport protocols. There is little chance of confusing a tunnel-encapsulated packet with other application data that could result in corruption of application state or data. From the end-to-end perspective, the principal difference is that the network-layer Next Header field identifies a separate transport, which reduces the probability that corruption could result in the @@ -767,104 +765,104 @@ fragments resulting when the path MTU results in fragmentation of a larger packet, common when addition of a tunnel encapsulation header expands the size of a packet). Detection of this type of error requires a checksum or other integrity check of the headers and the payload. Such protection is anyway desirable for tunnel encapsulations using IPv4, since the small fragmentation ID can easily result in wrap-around [RFC4963], this is especially the case for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels]. Tunnel fragmentation behavior matters. There can be outer or inner - fragmentation "Tunnels in the Internet Architecture" - [I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the - tunnel, the outer headers will never be fragmented and thus a zero- - checksum in the outer header will not affect the reassembly process. - When a tunnel performs outer header fragmentation, the tunnel egress - needs to perform reassembly of the outer fragments into an inner - packet. The inner packet is either a complete packet or a fragment. - If it is a fragment, the destination endpoint of the fragment will - perform reassembly of the received fragments. The complete packet or - the reassembled fragments will then be processed according to the - packet next header field. The receiver may only detect reassembly - anomalies when it uses a protocol with a checksum. The larger the - number of reassembly processes to which a packet has been subjected, - the greater the probability of an error. + fragmentation "Tunnels in the Internet Architecture" [I-D.ietf- + intarea-tunnels]. If there is inner fragmentation by the tunnel, the + outer headers will never be fragmented and thus a zero-checksum in + the outer header will not affect the reassembly process. When a + tunnel performs outer header fragmentation, the tunnel egress needs + to perform reassembly of the outer fragments into an inner packet. + The inner packet is either a complete packet or a fragment. If it is + a fragment, the destination endpoint of the fragment will perform + reassembly of the received fragments. The complete packet or the + reassembled fragments will then be processed according to the packet + next header field. The receiver may only detect reassembly anomalies + when it uses a protocol with a checksum. The larger the number of + reassembly processes to which a packet has been subjected, the + greater the probability of an error. o An IP-in-IP tunnel that performs inner fragmentation has similar properties to a UDP tunnel with a zero-checksum that also performs inner fragmentation. o An IP-in-IP tunnel that performs outer fragmentation has similar properties to a UDP tunnel with a zero checksum that performs outer fragmentation. o A tunnel that performs outer fragmentation can result in a higher level of corruption due to both inner and outer fragmentation, enabling more chances for reassembly errors to occur. o Recursive tunneling can result in fragmentation at more than one header level, even for inner fragmentation unless it goes to the inner most IP header. o Unless there is verification at each reassembly, the probability for undetected error will increase with the number of times fragmentation is recursively applied, making IP-in-IP and UDP with - zero checksum both vulnberable to undetected errors. + zero checksum both vulnerable to undetected errors. In conclusion fragmentation of packets with a zero-checksum does not worsen the situation compared to some other commonly used tunnel encapsulations. However, caution is needed for recursive tunneling without any additional verification at the different tunnel layers. 3.2. Validating the network path IP transports designed for use in the general Internet should not assume specific path characteristics. Network protocols may reroute 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. - The zero-checksum in UDP 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 + The zero-checksum in UDP 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 likely discard it, unless the device is updated to support a 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 negotiation or an explicit mandate to use the new behavior by all nodes intended to use a new protocol. Support along the path between end points may be guaranteed in limited deployments by appropriate configuration. In general, it can be expected to take time for deployment of any updated behaviour to become ubiquitous. A sender will need to probe the path to verify the expected behavior. Path characteristics may change, and usage therefore should be robust and able to detect a failure of the path under normal usage and re-negotiate. This will require periodic validation of the path, adding complexity to any solution using the new behavior. 3.3. Applicability of method - The expectation of the present proposal defined in - [I-D.ietf-6man-udpchecksums] is that this change would only apply to - IPv6 router nodes that implement specific protocols that permit - omission of UDP checksums. However, the distinction between a router - and a host is not always clear, especially at the transport level. - Systems (such as unix-based operating systems) routinely provide both - functions. There is also no way to identify the role of a receiver - from a received packet. + The expectation of the present proposal defined in [I-D.ietf-6man- + udpchecksums] is that this change would only apply to IPv6 router + nodes that implement specific protocols that permit omission of UDP + checksums. However, the distinction between a router and a host is + not always clear, especially at the transport level. Systems (such + as unix-based operating systems) routinely provide both functions. + There is also no way to identify the role of a receiver from a + received packet. Any new method would therefore need a specific applicability statement indicating when the mechanism can (and can not) be used. Enabling this, and ensuring correct interactions with the stack, implies much more than simply disabling the checksum algorithm for specific packets at the transport interface. The IETF should carefully consider constraints on sanctioning the use of any new transport mode. If this is specified and widely available, it may be expected to be used by applications that are @@ -925,22 +923,22 @@ [RFC1141]. This would not require access to the whole packet, but does require fields to be collected across the header, and arithmetic operations on each packet. The method would only work for packets that contain a 2's complement transport checksum (i.e. it would not be appropriate for SCTP or when IP fragmentation is used). o UDP-Lite with the checksum coverage set to only the header portion of a packet. This requires a pseudo header checksum calculation only on the encapsulating packet header. The computed checksum - value may be cached (before adding the Length field) for each - flow/destination and subsequently combined with the Length of each + value may be cached (before adding the Length field) for each flow + /destination and subsequently combined with the Length of each packet to minimise per-packet processing. This value is combined with the UDP payload length for the pseudo header, however this length is expected to be known when performing packet forwarding. o The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a method where UDP would be modified to derive the checksum only from the encapsulating packet protocol header. This value does not change between packets in a single flow. The value may be cached per flow/destination to minimise per-packet processing. @@ -951,27 +949,27 @@ to drop the packet. The main downside is that it would be impossible to identify a UDP packet (in the network or an endpoint) that is treated in this way compared to a packet that has actually been corrupted. o A method has been proposed that uses a new (to be defined) IPv6 Destination Options Header to provide an end-to-end validation check at the network layer. This would allow an endpoint to verify delivery to an appropriate end point, but would also require IPv6 nodes to correctly handle the additional header, and - would require changes to middlebox behavior (e.g. when used with a - NAT that always adjusts the checksum value). + would require changes to middlebox behavior (e.g. when used with + a NAT that always adjusts the checksum value). - o UDP modified to disable checksum processing - [I-D.ietf-6man-udpchecksums]. This requires no checksum - calculation, but would require constraints on appropriate usage - and updates to end-points and middleboxes. + o UDP modified to disable checksum processing [I-D.ietf-6man- + udpchecksums]. This requires no checksum calculation, but would + require constraints on appropriate usage and updates to end-points + and middleboxes. o IP-in-IP tunneling. As this method completely dispenses with a transport protocol in the outer-layer it has reduced overhead and complexity, but also reduced functionality. There is no outer checksum over the packet and also no ports to perform demultiplexing between different tunnel types. This reduces the information available upon which a load balancer may act. These options are compared and discussed further in the following sections. @@ -1117,35 +1115,34 @@ support, limited middlebox traversal, but possible to improve over time, currently poor load balancing support that could improve over time, in most cases requiring application level negotiation and validation. The delta-checksum is an optimization in the processing of UDP, as such it exhibits some of the drawbacks of using regular UDP. The remaining proposals may be described in similar terms: - Zero-Checksum: A low complexity encapsulation, with good - multiplexing support, limited middlebox traversal that could - improve over time, good load balancing support, in most cases - requiring application level negotiation and validation. + Zero-Checksum: A low complexity encapsulation, with good multiplexing + support, limited middlebox traversal that could improve over time, + good load balancing support, in most cases requiring application + level negotiation and validation. UDPTT: A medium complexity encapsulation, with good multiplexing support, limited middlebox traversal, but possible to improve over time, good load balancing support, in most cases requiring application level negotiation and validation. - IPv6 Destination Option IP in IP tunneling: A medium complexity, - with no multiplexing support, limited middlebox traversal, - currently poor load balancing support that could improve over - time, in most cases requiring application level negotiation and - validation. + IPv6 Destination Option IP in IP tunneling: A medium complexity, with + no multiplexing support, limited middlebox traversal, currently + poor load balancing support that could improve over time, in most + cases requiring application level negotiation and validation. IPv6 Destination Option combined with UDP Zero-checksuming: A medium complexity encapsulation, with good multiplexing support, limited load balancing support that could improve over time, in most cases requiring application level negotiation and validation. Ignore the checksum on reception: A low complexity encapsulation, with good multiplexing support, medium middlebox traversal that never can improve, good load balancing support, in most cases requiring application level negotiation and validation. @@ -1253,22 +1250,22 @@ 8. If a method proposes recursive tunnels, it needs to provide guidance that is appropriate for all use-cases. Restrictions may be needed to the use of a tunnel encapsulations and the use of recursive tunnels (e.g. Necessary when the endpoint is not verified). 9. IPv6 nodes that receive ICMPv6 messages that refer to packets with a zero UDP checksum must provide appropriate checks concerning the consistency of the reported packet to verify that the reported packet actually originated from the node, before - acting upon the information (e.g. validating the address and port - numbers in the ICMPv6 message body). + acting upon the information (e.g. validating the address and + port numbers in the ICMPv6 message body). Deployment of the new method needs to remain restricted to endpoints that explicitly enable this mode and adopt the above procedures. Any middlebox that examines or interacts with the UDP header over IPv6 should support the new method. 6. Summary This document examines the role of the transport checksum when used with IPv6, as defined in RFC2460. @@ -1334,22 +1331,22 @@ Recursive tunneling and fragmentation is a difficult issue relating to tunnels in general. There is an increased risk of an error in the inner-most packet when fragmentation when several layers of tunneling and several different reassembly processes are run without any verification of correctness. This issue requires future thought and consideration. The conclusion is that UDP zero checksum in IPv6 should be standardized, as it satisfies usage requirements that are currently difficult to address. We do note that a safe deployment of zero- - checksum will need to follow a set of constraints listed in - Section 5.1. + checksum will need to follow a set of constraints listed in Section + 5.1. 7. Acknowledgements Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, others in the TSV directorate. Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who contributed comments and ideas via the 6man, behave, lisp and mboned lists. @@ -1361,105 +1358,103 @@ Transport checksums provide the first stage of protection for the stack, although they can not be considered authentication mechanisms. These checks are also desirable to ensure packet counters correctly log actual activity, and can be used to detect unusual behaviours. 10. References 10.1. Normative References - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. - [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, - "Computing the Internet checksum", RFC 1071, - September 1988. + [RFC1071] Braden, R., Borman, D., Partridge, C. and W. Plummer, + "Computing the Internet checksum", RFC 1071, September + 1988. - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. + [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. 10.2. Informative References [ECMP] "Using the IPv6 flow label for equal cost multipath - routing in tunnels (draft-carpenter-flow-ecmp)". + routing in tunnels (draft-carpenter-flow-ecmp)", . [I-D.ietf-6man-udpchecksums] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled - Packets", draft-ietf-6man-udpchecksums-01 (work in - progress), October 2011. + Packets", Internet-Draft draft-ietf-6man-udpchecksums-02, + March 2012. [I-D.ietf-intarea-tunnels] Touch, J. and M. Townsley, "Tunnels in the Internet - Architecture", draft-ietf-intarea-tunnels-00 (work in - progress), March 2010. + Architecture", Internet-Draft draft-ietf-intarea- + tunnels-00, March 2010. [I-D.ietf-mboned-auto-multicast] - Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., - Pusateri, T., and T. Morin, "Automatic IP Multicast - Tunneling", draft-ietf-mboned-auto-multicast-11 (work in - progress), July 2011. + Bumgardner, G., "Automatic Multicast Tunneling", Internet- + Draft draft-ietf-mboned-auto-multicast-14, June 2012. - [LISP] D. Farinacci et al, "Locator/ID Separation Protocol + [LISP] D. Farinacci et al, , "Locator/ID Separation Protocol (LISP)", March 2009. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, January 1990. [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994. - [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., - Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. + Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. - [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and + [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E. and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. - [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control + [RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. - [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly + [RFC4963] Heffner, J., Mathis, M. and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines - for Application Designers", BCP 145, RFC 5405, - November 2008. + for Application Designers", BCP 145, RFC 5405, November + 2008. - [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And + [RFC5415] Calhoun, P., Montemurro, M. and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009. - [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation + [RFC6145] Li, X., Bao, C. and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [Sigcomm2000] - Jonathan Stone and Craig Partridge , "When the CRC and TCP - Checksum Disagree", 2000. + Jonathan Stone and Craig Partridge , , "When the CRC and + TCP Checksum Disagree", 2000. - [UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. + [UDPTT] G Fairhurst, , "The UDP Tunnel Transport mode", Feb 2010. Appendix A. Document Change History {RFC EDITOR NOTE: This section must be deleted prior to publication} Individual Draft 00 This is the first DRAFT of this document - It contains a compilation of various discussions and contributions from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, and behave. This includes contributions from Magnus with text on RTP, and various updates. @@ -1507,34 +1501,34 @@ * Editorial updates Working Group Draft 04 * Resubmission only updating the AMT and RFC2765 references. Working Group Draft 05 * Resubmission to correct editorial NiTs - thanks to Bill Atwood - for noting these. + for noting these.Group Draft 05. + + Working Group Draft 06 + + * Resubmission to keep draft alive (spelling updated from 05). Authors' Addresses Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE, Scotland, UK - Phone: Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/gorry - Magnus Westerlund Ericsson Farogatan 6 Stockholm, SE-164 80 Sweden Phone: +46 8 719 0000 - Fax: Email: magnus.westerlund@ericsson.com - URI: