idnits 2.17.1 draft-ietf-6man-udpzero-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-00 == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-14 -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Standards Track M. Westerlund 5 Expires: August 29, 2013 Ericsson 6 February 25, 2013 8 Applicability Statement for the use of IPv6 UDP Datagrams with Zero 9 Checksums 10 draft-ietf-6man-udpzero-12 12 Abstract 14 This document provides an applicability statement for the use of UDP 15 transport checksums with IPv6. It defines recommendations and 16 requirements for the use of IPv6 UDP datagrams with a zero UDP 17 checksum. It describes the issues and design principles that need to 18 be considered when UDP is used with IPv6 to support tunnel 19 encapsulations and examines the role of the IPv6 UDP transport 20 checksum. The document also identifies issues and constraints for 21 deployment on network paths that include middleboxes. An appendix 22 presents a summary of the trade-offs that were considered in 23 evaluating the safety of the update to RFC 2460 that updates use of 24 the UDP checksum with IPv6. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 29, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5 64 1.3.1. Motivation for new approaches . . . . . . . . . . . . 6 65 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 66 1.3.3. Need to inspect the entire packet . . . . . . . . . . 7 67 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 7 68 1.3.5. Support for load balancing . . . . . . . . . . . . . . 8 69 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9 70 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9 71 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10 73 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10 74 2.4. Relation to UDP-Lite and UDP with checksum . . . . . . . . 10 75 3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12 76 3.1. Effect of packet modification in the network . . . . . . . 13 77 3.1.1. Corruption of the destination IP address . . . . . . . 14 78 3.1.2. Corruption of the source IP address . . . . . . . . . 15 79 3.1.3. Corruption of Port Information . . . . . . . . . . . . 16 80 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 16 81 3.1.5. Corruption of Fragmentation Information . . . . . . . 17 82 3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 19 83 3.3. Validating the network path . . . . . . . . . . . . . . . 20 84 3.4. Applicability of method . . . . . . . . . . . . . . . . . 21 85 3.5. Impact on non-supporting devices or applications . . . . . 21 86 4. Constraints on implementation of IPv6 nodes supporting 87 zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 22 88 5. Requirements on usage of the zero UDP checksum . . . . . . . . 24 89 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 97 Appendix A. Evaluation of proposal to update RFC 2460 to 98 support zero checksum . . . . . . . . . . . . . . . . 31 99 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 31 100 A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 33 101 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 33 102 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 34 103 A.2.3. Ingress and Egress Performance Implications . . . . . 34 104 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 34 105 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 35 106 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 35 107 Appendix B. Document Change History . . . . . . . . . . . . . . . 38 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 110 1. Introduction 112 The User Datagram Protocol (UDP) [RFC0768] transport is defined for 113 the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet 114 Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The 115 UDP transport protocol has a minimal set of features. This limited 116 set has enabled a wide range of applications to use UDP, but these 117 application do need to provide many important transport functions on 118 top of UDP. The UDP Usage Guidelines [RFC5405] provides overall 119 guidance for application designers, including the use of UDP to 120 support tunneling. The key difference between UDP usage with IPv4 121 and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, 122 i.e. a non-zero value, due to the lack of an IPv6 header checksum. 123 The inclusion of the pseudo header in the checksum computation 124 provides a statistical check that datagrams have been delivered to 125 the intended IPv6 destination node. Algorithms for checksum 126 computation are described in [RFC1071]. 128 The lack of a possibility to use an IPv6 datagram with a zero UDP 129 checksum has been observed as a real problem for certain classes of 130 application, primarily tunnel applications. This class of 131 application has been deployed with a zero UDP checksum using IPv4. 132 The design of IPv6 raises different issues when considering the 133 safety of using a UDP checksum with IPv6. These issues can 134 significantly affect applications, both when an endpoint is the 135 intended user and when an innocent bystander (when a packet is 136 received by a different endpoint to that intended). 138 This document examines the issues and an appendix compares the 139 strengths and weaknesses of a number of proposed solutions. This 140 identifies a set of issues that must be considered and mitigated to 141 be able to safely deploy IPv6 applications that use a zero UDP 142 checksum. The provided comparison of methods is expected to also be 143 useful when considering applications that have different goals from 144 the ones that initiated the writing of this document, especially the 145 use of already standardized methods. The analysis concludes that 146 using a zero UDP checksum is the best method of the proposed 147 alternatives to meet the goals for certain tunnel applications. 149 This document defines recommendations and requirements for use of 150 IPv6 datagrams with a zero UDP checksum. This usage is expected to 151 have initial deployment issues related to middleboxes, limiting the 152 usability more than desired in the currently deployed Internet. 153 However, this limitation will be largest initially and will reduce as 154 updates are provided in middleboxes that support the zero UDP 155 checksum for IPv6. The document therefore derives a set of 156 constraints required to ensure safe deployment of a zero UDP 157 checksum. 159 Finally, the document also identifies some issues that require future 160 consideration and possibly additional research. 162 1.1. Document Structure 164 Section 1 provides a background to key issues, and introduces the use 165 of UDP as a tunnel transport protocol. 167 Section 2 describes a set of standards-track datagram transport 168 protocols that may be used to support tunnels. 170 Section 3 discusses issues with a zero UDP checksum for IPv6. It 171 considers the impact of corruption, the need for validation of the 172 path and when it is suitable to use a zero UDP checksum. 174 Section 4 is an applicability statement that defines requirements and 175 recommendations on the implementation of IPv6 nodes that support the 176 use of a zero UDP checksum. 178 Section 5 provides an applicability statement that defines 179 requirements and recommendations for protocols and tunnel 180 encapsulations that are transported over an IPv6 transport that does 181 not perform a UDP checksum calculation to verify the integrity at the 182 transport endpoints. 184 Section 6 provides the recommendations for standardization of zero 185 UDP checksum with a summary of the findings and notes remaining 186 issues needing future work. 188 Appendix A evaluates the set of proposals to update the UDP transport 189 behaviour and other alternatives intended to improve support for 190 tunnel protocols. It concludes by assessing the trade-offs of the 191 various methods, identifying advantages and disadvantages for each 192 method. 194 1.2. Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 1.3. Use of UDP Tunnels 202 One increasingly popular use of UDP is as a tunneling protocol, where 203 a tunnel endpoint encapsulates the packets of another protocol inside 204 UDP datagrams and transmits them to another tunnel endpoint. Using 205 UDP as a tunneling protocol is attractive when the payload protocol 206 is not supported by the middleboxes that may exist along the path, 207 because many middleboxes support transmission using UDP. In this 208 use, the receiving endpoint decapsulates the UDP datagrams and 209 forwards the original packets contained in the payload [RFC5405]. 210 Tunnels establish virtual links that appear to directly connect 211 locations that are distant in the physical Internet topology and can 212 be used to create virtual (private) networks. 214 1.3.1. Motivation for new approaches 216 A number of tunnel encapsulations deployed over IPv4 have used the 217 UDP transport with a zero checksum. Users of these protocols expect 218 a similar solution for IPv6. 220 A number of tunnel protocols are also currently being defined (e.g. 221 Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast], 222 and the Locator/Identifier Separation Protocol, LISP [LISP]). These 223 protocols motivated an update to IPv6 UDP checksum processing to 224 benefit from simpler checksum processing for various reasons: 226 o Reducing forwarding costs, motivated by redundancy present in the 227 encapsulated packet header, since in tunnel encapsulations, 228 payload integrity and length verification may be provided by 229 higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, 230 or TCP checksums). 232 o Eliminating a need to access the entire packet when forwarding the 233 packet by a tunnel endpoint. 235 o Enhancing ability to traverse and function with middleboxes. 237 o A desire to use the port number space to enable load-sharing. 239 1.3.2. Reducing forwarding cost 241 It is a common requirement to terminate a large number of tunnels on 242 a single router/host. The processing cost per tunnel includes both 243 state (memory requirements) and per-packet processing at the tunnel 244 ingress and egress. 246 Automatic IP Multicast Tunneling, known as AMT 247 [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the 248 transport protocol for packets carrying tunneled IP multicast 249 packets. The current specification for AMT states that the UDP 250 checksum in the outer packet header should be zero (see Section 6.6 251 of [I-D.ietf-mboned-auto-multicast]). This argues that the 252 computation of an additional checksum is an unwarranted burden on 253 nodes implementing lightweight tunneling protocols when an inner 254 packet is already adequately protected, . The AMT protocol needs to 255 replicate a multicast packet to each gateway tunnel. In this case, 256 the outer IP addresses are different for each tunnel and therefore 257 require a different pseudo header to be built for each UDP replicated 258 encapsulation. 260 The argument concerning redundant processing costs is valid regarding 261 the integrity of a tunneled packet. In some architectures (e.g. PC- 262 based routers), other mechanisms may also significantly reduce 263 checksum processing costs: There are implementations that have 264 optimised checksum processing algorithms, including the use of 265 checksum-offloading. This processing is readily available for IPv4 266 packets at high line rates. Such processing may be anticipated for 267 IPv6 endpoints, allowing receivers to reject corrupted packets 268 without further processing. However, there are certain classes of 269 tunnel end-points where this off-loading is not available and 270 unlikely to become available in the near future. 272 1.3.3. Need to inspect the entire packet 274 The currently-deployed hardware in many routers uses a fast-path 275 processing that only provides the first n bytes of a packet to the 276 forwarding engine, where typically n <= 128. 278 When this design is used to support a tunnel ingress and egress, it 279 prevents fast processing of a transport checksum over an entire 280 (large) packet. Hence the currently defined IPv6 UDP checksum is 281 poorly suited to use within a router that is unable to access the 282 entire packet and does not provide checksum-offloading. Thus 283 enabling checksum calculation over the complete packet can impact 284 router design, performance improvement, energy consumption and/or 285 cost. 287 1.3.4. Interactions with middleboxes 289 Many paths in the Internet include one or more middleboxes of various 290 types. There exist large classes of middleboxes that will handle 291 zero UDP checksum packets, which would not support UDP-Lite or the 292 other investigated proposals. These middleboxes includes load 293 balancers (see Section 1.3.5) including Equal Cost Multipath Routing, 294 traffic classifiers and other functions that reads some fields in the 295 UDP headers but does not validate the UDP checksum. 297 There are also middleboxes that either validates or modify the UDP 298 checksum. The two most common classes are Firewalls and NATs. In 299 IPv4, UDP-encapsulation may be desirable for NAT traversal, since UDP 300 support is commonly provided. It is also necessary due to the almost 301 ubiquitous deployment of IPv4 NATs. There has also been discussion 302 of NAT for IPv6, although not for the same reason as in IPv4. If 303 IPv6 NAT becomes a reality they hopefully do not present the same 304 protocol issues as for IPv4. If NAT is defined for IPv6, it should 305 take into consideration the use of a zero UDP checksum. 307 The requirements for IPv6 firewall traversal are likely be to be 308 similar to those for IPv4. In addition, it can be reasonably 309 expected that a firewall conforming to RFC 2460 will not regard 310 datagrams with a zero UDP checksum as valid. Use of a zero UDP 311 checksum with IPv6 requires firewalls to be updated before the full 312 utility of the change is available. 314 It can be expected that datagrams with zero UDP checksum will 315 initially not have the same middlebox traversal characteristics as 316 regular UDP (RFC 2460). However when implementations follow the 317 requirements specified in this document, we expect the traversal 318 capabilities to improve over time. We also note that deployment of 319 IPv6-capable middleboxes is still in its initial phases. Thus, it 320 might be that the number of non-updated boxes quickly become a very 321 small percentage of the deployed middleboxes. 323 1.3.5. Support for load balancing 325 The UDP port number fields have been used as a basis to design load- 326 balancing solutions for IPv4. This approach has also been leveraged 327 for IPv6. An alternate method would be to utilise the IPv6 Flow 328 Label [RFC6437] as a basis for entropy for load balancing. This 329 would have the desirable effect of releasing IPv6 load-balancing 330 devices from the need to assume semantics for the use of the 331 transport port field and also works for all type of transport 332 protocols. 334 This use of the flow-label for load balancing is consistent with the 335 intended use, although further clarity was needed to ensure the field 336 can be consistently used for this purpose, therefore an updated IPv6 337 Flow Label [RFC6437] and Equal-Cost Multi-Path routing usage, (ECMP) 338 [RFC6438] was produced. Router vendors could be encouraged to start 339 using the IPv6 Flow Label as a part of the flow hash, providing 340 support for ECMP without requiring use of UDP. 342 However, the method for populating the outer IPv6 header with a value 343 for the flow label is not trivial: If the inner packet uses IPv6, 344 then the flow label value could be copied to the outer packet header. 345 However, many current end-points set the flow label to a zero value 346 (thus no entropy). The ingress of a tunnel seeking to provide good 347 entropy in the flow label field would therefore need to create a 348 random flow label value and keep corresponding state, so that all 349 packets that were associated with a flow would be consistently given 350 the same flow label. Although possible, this complexity may not be 351 desirable in a tunnel ingress. 353 The end-to-end use of flow labels for load balancing is a long-term 354 solution. Even if the usage of the flow label is clarified, there 355 would be a transition time before a significant proportion of end- 356 points start to assign a good quality flow label to the flows that 357 they originate, with continued use of load balancing using the 358 transport header fields until any widespread deployment is finally 359 achieved. 361 2. Standards-Track Transports 363 The IETF has defined a set of transport protocols that may be 364 applicable for tunnels with IPv6. There are also a set of network 365 layer encapsulation tunnels such as IP-in-IP and GRE. These already 366 standardized solutions are discussed here prior to the issues, as 367 background for the issue description and some comparison of where the 368 issue may already occur. 370 2.1. UDP with Standard Checksum 372 UDP [RFC0768] with standard checksum behaviour, as defined in RFC 373 2460, has already been discussed. UDP usage guidelines are provided 374 in [RFC5405]. 376 2.2. UDP-Lite 378 UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as 379 a proposed standard, RFC 3828. A MIB is defined in [RFC5097] and 380 unicast usage guidelines in [RFC5405]. There is at least one open 381 source implementation as a part of the Linux kernel since version 382 2.6.20. 384 UDP-Lite provides a checksum with optional partial coverage. When 385 using this option, a datagram is divided into a sensitive part 386 (covered by the checksum) and an insensitive part (not covered by the 387 checksum). When the checksum covers the entire packet, UDP-Lite is 388 fully equivalent with UDP, with the exception that it uses a 389 different value in the Next Header field in the IPv6 header. Errors/ 390 corruption in the insensitive part will not cause the datagram to be 391 discarded by the transport layer at the receiving endpoint. A minor 392 side-effect of using UDP-Lite is that this was specified for damage- 393 tolerant payloads and some link-layers may employ different link 394 encapsulations when forwarding UDP-Lite segments (e.g. radio access 395 bearers). Most link-layers will cover the insensitive part with the 396 same strong layer 2 frame CRC that covers the sensitive part. 398 2.2.1. Using UDP-Lite as a Tunnel Encapsulation 400 Tunnel encapsulations can use UDP-Lite (e.g. Control And 401 Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- 402 Lite provides a transport-layer checksum, including an IP pseudo 403 header checksum, in IPv6, without the need for a router/middlebox to 404 traverse the entire packet payload. This provides most of the 405 verification required for delivery and still keeps a low complexity 406 for the checksumming operation. UDP-Lite may set the length of 407 checksum coverage on a per packet basis. This feature could be used 408 if a tunnel protocol is designed to only verify delivery of the 409 tunneled payload and uses a calculated checksum for control 410 information. 412 There is currently poor support for middlebox traversal using UDP- 413 Lite, because UDP-Lite uses a different IPv6 network-layer Next 414 Header value to that of UDP, and few middleboxes are able to 415 interpret UDP-Lite and take appropriate actions when forwarding the 416 packet. This makes UDP-Lite less suited to protocols needing general 417 Internet support, until such time that UDP-Lite has achieved better 418 support in middleboxes and end-points. 420 2.3. General Tunnel Encapsulations 422 The IETF has defined a set of tunneling protocols or network layer 423 encapsulations, e.g., IP-in-IP and GRE. These either do not include 424 a checksum or use a checksum that is optional, since tunnel 425 encapsulations are typically layered directly over the Internet layer 426 (identified by the upper layer type in the IPv6 Next Header field) 427 and are also not used as endpoint transport protocols. There is 428 little chance of confusing a tunnel-encapsulated packet with other 429 application data that could result in corruption of application state 430 or data. 432 From the end-to-end perspective, the principal difference is that the 433 network-layer Next Header field identifies a separate transport, 434 which reduces the probability that corruption could result in the 435 packet being delivered to the wrong endpoint or application. 436 Specifically, packets are only delivered to protocol modules that 437 process a specific Next Header value. The Next Header field 438 therefore provides a first-level check of correct demultiplexing. In 439 contrast, the UDP port space is shared by many diverse applications 440 and therefore UDP demultiplexing relies solely on the port numbers. 442 2.4. Relation to UDP-Lite and UDP with checksum 444 The operation of IPv6 with UDP with a zero-checksum is not the same 445 as IPv4 with UDP with a zero-checksum. Protocol designers should not 446 be fooled into thinking the two are the same. The requirements below 447 list a set of additional considerations. 449 Where possible, existing general tunnel encapsulations, such as GRE, 450 IP-in-IP, should be used. This section assumes that such existing 451 tunnel encapsulations do not offer the functionally required to 452 satisfy the protocol designer's goals. The section considers the 453 standardized alternative solutions, rather than the full set of ideas 454 evaluated in Appendix A. The alternatives to UDP with a zero 455 checksum are UDP with a (calculated) checksum, and UDP-Lite. 457 UDP with a checksum has the advantage of close to universal support 458 in both endpoints and middleboxes. It also provides statistical 459 verification of delivery to the intended destination (address and 460 port). However, some classes of device have limited support for 461 calculation of a checksum that covers a full datagram. For these 462 devices, this can incur significant processing cost (e.g. requiring 463 processing in the router slow-path) and can hence reduce capacity or 464 fail to function. 466 UDP-Lite has the advantage of using a checksum that is calculated 467 only over the pseudo header and the UDP header. This provides a 468 statistical verification of delivery to the intended destination 469 (address and port). The checksum can be calculated without access to 470 the datagram payload, only requiring access to the part to be 471 protected. A drawback is that UDP-Lite has currently limited support 472 in both end-points (i.e. is not supported on all operating system 473 platforms) and middleboxes (that require support for the UDP-Lite 474 header type). A path verification method is therefore recommended. 476 IPv6 and UDP with a zero-checksum can also be used by nodes that do 477 not permit calculation of a payload checksum. Many existing classes 478 of middleboxes do not verify or change the transport checksum. For 479 these middleboxes, IPv6 with a zero UDP checksum is expected to 480 function where UDP-Lite would not. However, support for the zero UDP 481 checksum in middleboxes that do change or verify the checksum is 482 currently limited, and this may result in datagrams with a zero UDP 483 checksum being discarded, therefore a path verification method is 484 recommended. 486 There are sets of constrains for which no solution exist: A protocol 487 designer that needs to originate or receive datagrams on a device 488 that can not efficiently calculate a checksum over a full datagram 489 and also needs these packets to pass through a middlebox that 490 verifies or changes a UDP checksum, but does not support a zero UDP 491 checksum, can not use the zero UDP checksum method. Similarly, one 492 that originates datagrams on a device with UDP-Lite support, but 493 needs the packets to pass through a middlebox that does not support 494 UDP-Lite, can not use UDP-Lite. For such cases, there is no optimal 495 solution and the current recommendation is to use or fall-back to 496 using UDP with full checksum coverage. 498 3. Issues Requiring Consideration 500 This informative section evaluates issues around the proposal to 501 update IPv6 [RFC2460], to enable the UDP transport checksum to be set 502 to zero. Some of the identified issues are shared with other 503 protocols already in use. The section also provides background to 504 the requirements and recommendations that follow. 506 The decision in RFC 2460 to omit an integrity check at the network 507 level meant that the IPv6 transport checksum was overloaded with many 508 functions, including validating: 510 o the endpoint address was not corrupted within a router, i.e., a 511 packet was intended to be received by this destination and 512 validate that the packet does not consist of a wrong header 513 spliced to a different payload; 515 o that extension header processing is correctly delimited - i.e., 516 the start of data has not been corrupted. In this case, reception 517 of a valid Next Header value provides some protection; 519 o reassembly processing, when used; 521 o the length of the payload; 523 o the port values - i.e., the correct application receives the 524 payload (applications should also check the expected use of source 525 ports/addresses); 527 o the payload integrity. 529 In IPv4, the first four checks are performed using the IPv4 header 530 checksum. 532 In IPv6, these checks occur within the endpoint stack using the UDP 533 checksum information. An IPv6 node also relies on the header 534 information to determine whether to send an ICMPv6 error message 535 [RFC4443] and to determine the node to which this is sent. Corrupted 536 information may lead to misdelivery to an unintended application 537 socket on an unexpected host. 539 3.1. Effect of packet modification in the network 541 IP packets may be corrupted as they traverse an Internet path. Older 542 evidence in "When the CRC and TCP Checksum Disagree" [Sigcomm2000] 543 show that this was once an issue in year 2000 with IPv4 routers, and 544 occasional corruption could result from bad internal router 545 processing in routers or hosts. These errors are not detected by the 546 strong frame checksums employed at the link-layer [RFC3819]. During 547 the development of this document in 2009, individuals provided 548 reports of observed rates for received UDP datagrams using IPv4 where 549 the UDP checksum had been detected as corrupt. These rates where as 550 high as 1.39E-4 for some paths, but also close to zero for some other 551 paths. 553 There is extensive experience of deployment using tunnel protocols in 554 well-managed networks (e.g. corporate networks or service provider 555 core networks). This has shown the robustness of methods such as PWE 556 and MPLS that do not employ a transport protocol checksum and have 557 not specified mechanisms to protect from corruption of the 558 unprotected headers (such as the VPN Identifier in MPLS). Reasons 559 for the robustness may include: 561 o A reduced probability of corruption on paths through well-managed 562 networks. 564 o IP form the majority of the inner traffic carried by these tunnel. 565 Hence from a transport perspective, endpoint verification is 566 already being performed when processing a received IPv4 packet or 567 by the transport pseudo-header for an IPv6 packet. This update to 568 UDP does not change this behaviour. 570 o In certain cases, a combination of additional filtering (e.g. 571 filter of a MAC destination address in a L2 tunnel) significantly 572 reduces the probability of final mis-delivery to the IP stack. 574 o The tunnel protocols did not use a UDP transport header, any 575 corruption is therefore unlikely to result in misdelivery to 576 another UDP-based application. This concern is specific to the 577 use of UDP with IPv6. 579 While this experience can guide the present recommendations, any 580 update to UDP must preserve operation in the general Internet. This 581 is heterogeneous and can include links and systems of very varying 582 characteristics. Transport protocols used by hosts need to be 583 designed with this in mind, especially when there is need to traverse 584 edge networks, where middlebox deployments are common. 586 For the general Internet, there is no current evidence that 587 corruption is rare, nor that this may not be applicable to IPv6. It 588 therefore seems prudent not to relax checks on misdelivery . The 589 emergence of low-end IPv6 routers and the proposed use of NAT with 590 IPv6 further motivate the need to protect from misdelivery. 592 Corruption in the network may result in: 594 o A datagram being misdelivered to the wrong host/router or the 595 wrong transport entity within an endpoint. Such a datagram needs 596 to be discarded; 598 o A datagram payload being corrupted, but still delivered to the 599 intended host/router transport entity. Such a datagram needs to 600 be either discarded or correctly processed by an application that 601 provides its own integrity checks; 603 o A datagram payload being truncated by corruption of the length 604 field. Such a datagram needs to be discarded. 606 When a checksum is used, this significantly reduces the impact of 607 errors, reducing the probability of undetected corruption of state 608 (and data) on both the host stack and the applications using the 609 transport service. 611 The following sections examine the impact of modifying each of these 612 header fields. 614 3.1.1. Corruption of the destination IP address 616 An IPv6 endpoint destination address could be modified in the network 617 (e.g. corrupted by an error). This is not a concern for IPv4, 618 because the IP header checksum will result in this packet being 619 discarded by the receiving IP stack. Such modification in the 620 network can not be detected at the network layer when using IPv6. 621 Detection of this corruption by a UDP receiver relies on the IPv6 622 pseudo header incorporated in the transport checksum. 624 There are two possible outcomes: 626 o Delivery to a destination address that is not in use (the packet 627 will not be delivered, but could result in an error report); 629 o Delivery to a different destination address. This modification 630 will normally be detected by the transport checksum, resulting in 631 silent discard. Without a computed checksum, the packet would be 632 passed to the endpoint port demultiplexing function. If an 633 application is bound to the associated ports, the packet payload 634 will be passed to the application (see the subsequent section on 635 port processing). 637 3.1.2. Corruption of the source IP address 639 This section examines what happens when the source address is 640 corrupted in transit. This is not a concern in IPv4, because the IP 641 header checksum will normally result in this packet being discarded 642 by the receiving IP stack. Detection of this corruption by a UDP 643 receiver relies on the IPv6 pseudo header incorporated in the 644 transport checksum. 646 Corruption of an IPv6 source address does not result in the IP packet 647 being delivered to a different endpoint protocol or destination 648 address. If only the source address is corrupted, the datagram will 649 likely be processed in the intended context, although with erroneous 650 origin information. When using Unicast Reverse Path Forwarding 651 [RFC2827], a change in address may result in the router discarding 652 the packet when the route to the modified source address is different 653 to that of the source address of the original packet. 655 The result will depend on the application or protocol that processes 656 the packet. Some examples are: 658 o An application that requires a per-established context may 659 disregard the datagram as invalid, or could map this to another 660 context (if a context for the modified source address was already 661 activated). 663 o A stateless application will process the datagram outside of any 664 context, a simple example is the ECHO server, which will respond 665 with a datagram directed to the modified source address. This 666 would create unwanted additional processing load, and generate 667 traffic to the modified endpoint address. 669 o Some datagram applications build state using the information from 670 packet headers. A previously unused source address would result 671 in receiver processing and the creation of unnecessary transport- 672 layer state at the receiver. For example, Real Time Protocol 673 (RTP) [RFC3550] sessions commonly employ a source independent 674 receiver port. State is created for each received flow. 675 Reception of a datagram with a corrupted source address will 676 therefore result in accumulation of unnecessary state in the RTP 677 state machine, including collision detection and response (since 678 the same synchronization source, SSRC, value will appear to arrive 679 from multiple source IP addresses). 681 o ICMP messages relating to a corrupted packet can be misdirected to 682 the wrong source node. 684 In general, the effect of corrupting the source address will depend 685 upon the protocol that processes the packet and its robustness to 686 this error. For the case where the packet is received by a tunnel 687 endpoint, the tunnel application is expected to correctly handle a 688 corrupted source address. 690 The impact of source address modification is more difficult to 691 quantify when the receiving application is not that originally 692 intended and several fields have been modified in transit. 694 3.1.3. Corruption of Port Information 696 This section describes what happens if one or both of the UDP port 697 values are corrupted in transit. This can also happen with IPv4 is 698 used with a zero UDP checksum, but not when UDP checksums are 699 calculated or when UDP-Lite is used. If the ports carried in the 700 transport header of an IPv6 packet were corrupted in transit, packets 701 may be delivered to the wrong application process (on the intended 702 machine) and/or responses or errors sent to the wrong application 703 process (on the intended machine). 705 3.1.4. Delivery to an unexpected port 707 If one combines the corruption effects, such as destination address 708 and ports, there is a number of potential outcomes when traffic 709 arrives at an unexpected port. This section discusses these 710 possibilities and their outcomes for a packet that does not use the 711 UDP checksum validation: 713 o Delivery to a port that is not in use. The packet is discarded, 714 but could generate an ICMPv6 message (e.g. port unreachable). 716 o It could be delivered to a different node that implements the same 717 application, where the packet may be accepted, generating side- 718 effects or accumulated state. 720 o It could be delivered to an application that does not implement 721 the tunnel protocol, where the packet may be incorrectly parsed, 722 and may be misinterpreted, generating side-effects or accumulated 723 state. 725 The probability of each outcome depends on the statistical 726 probability that the address or the port information for the source 727 or destination becomes corrupt in the datagram such that they match 728 those of an existing flow or server port. Unfortunately, such a 729 match may be more likely for UDP than for connection-oriented 730 transports, because: 732 1. There is no handshake prior to communication and no sequence 733 numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard 734 to verify that an application process is given only the 735 application data associated with a specific transport session. 737 2. Applications writers often bind to wild-card values in endpoint 738 identifiers and do not always validate correctness of datagrams 739 they receive (guidance on this topic is provided in [RFC5405]). 741 While these rules could, in principle, be revised to declare naive 742 applications as "Historic". This remedy is not realistic: the 743 transport owes it to the stack to do its best to reject bogus 744 datagrams. 746 If checksum coverage is suppressed, the application therefore needs 747 to provide a method to detect and discard the unwanted data. A 748 tunnel protocol would need to perform its own integrity checks on any 749 control information if transported in datagrams with a zero UDP 750 checksum. If the tunnel payload is another IP packet, the packets 751 requiring checksums can be assumed to have their own checksums 752 provided that the rate of corrupted packets is not significantly 753 larger due to the tunnel encapsulation. If a tunnel transports other 754 inner payloads that do not use IP, the assumptions of corruption 755 detection for that particular protocol must be fulfilled, this may 756 require an additional checksum/CRC and/or integrity protection of the 757 payload and tunnel headers. 759 A protocol that uses a zero UDP checksum can not assume that it is 760 the only protocol using a zero UDP checksum. Therefore, it needs to 761 gracefully handle misdelivery. It must be robust to reception of 762 malformed packets received on a listening port and expect that these 763 packets may contain corrupted data or data associated with a 764 completely different protocol. 766 3.1.5. Corruption of Fragmentation Information 768 The fragmentation information in IPv6 employs a 32-bit identity 769 field, compared to only a 16-bit field in IPv4, a 13-bit fragment 770 offset and a 1-bit flag, indicating if there are more fragments. 771 Corruption of any of these field may result in one of two outcomes: 773 Reassembly failure: An error in the "More Fragments" field for the 774 last fragment will for example result in the packet never being 775 considered complete and will eventually be timed out and 776 discarded. A corruption in the ID field will result in the 777 fragment not being delivered to the intended context thus leaving 778 the rest incomplete, unless that packet has been duplicated prior 779 to corruption. The incomplete packet will eventually be timed out 780 and discarded. 782 Erroneous reassembly: The re-assembled packet did not match the 783 original packet. This can occur when the ID field of a fragment 784 is corrupted, resulting in a fragment becoming associated with 785 another packet and taking the place of another fragment. 786 Corruption in the offset information can cause the fragment to be 787 misaligned in the reassembly buffer, resulting in incorrect 788 reassembly. Corruption can cause the packet to become shorter or 789 longer, however completion of reassembly is much less probable, 790 since this would require consistent corruption of the IPv6 headers 791 payload length field and the offset field. The possibility of 792 mis-assembly requires the reassembling stack to provide strong 793 checks that detect overlap or missing data, note however that this 794 is not guaranteed and has been clarified in "Handling of 795 Overlapping IPv6 Fragments" [RFC5722]. 797 The erroneous reassembly of packets is a general concern and such 798 packets should be discarded instead of being passed to higher layer 799 processes. The primary detector of packet length changes is the IP 800 payload length field, with a secondary check by the transport 801 checksum. The Upper-Layer Packet length field included in the pseudo 802 header assists in verifying correct reassembly, since the Internet 803 checksum has a low probability of detecting insertion of data or 804 overlap errors (due to misplacement of data). The checksum is also 805 incapable of detecting insertion or removal of all zero-data that 806 occurs in a multiple of a 16-bit chunk. 808 The most significant risk of corruption results following mis- 809 association of a fragment with a different packet. This risk can be 810 significant, since the size of fragments is often the same (e.g. 811 fragments resulting when the path MTU results in fragmentation of a 812 larger packet, common when addition of a tunnel encapsulation header 813 expands the size of a packet). Detection of this type of error 814 requires a checksum or other integrity check of the headers and the 815 payload. Such protection is anyway desirable for tunnel 816 encapsulations using IPv4, since the small fragmentation ID can 817 easily result in wrap-around [RFC4963], this is especially the case 818 for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels]. 820 Tunnel fragmentation behavior matters. There can be outer or inner 821 fragmentation "Tunnels in the Internet Architecture" 822 [I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the 823 tunnel, the outer headers will never be fragmented and thus a zero 824 UDP checksum in the outer header will not affect the reassembly 825 process. When a tunnel performs outer header fragmentation, the 826 tunnel egress needs to perform reassembly of the outer fragments into 827 an inner packet. The inner packet is either a complete packet or a 828 fragment. If it is a fragment, the destination endpoint of the 829 fragment will perform reassembly of the received fragments. The 830 complete packet or the reassembled fragments will then be processed 831 according to the packet Next Header field. The receiver may only 832 detect reassembly anomalies when it uses a protocol with a checksum. 833 The larger the number of reassembly processes to which a packet has 834 been subjected, the greater the probability of an error. 836 o An IP-in-IP tunnel that performs inner fragmentation has similar 837 properties to a UDP tunnel with a zero UDP checksum that also 838 performs inner fragmentation. 840 o An IP-in-IP tunnel that performs outer fragmentation has similar 841 properties to a UDP tunnel with a zero UDP checksum that performs 842 outer fragmentation. 844 o A tunnel that performs outer fragmentation can result in a higher 845 level of corruption due to both inner and outer fragmentation, 846 enabling more chances for reassembly errors to occur. 848 o Recursive tunneling can result in fragmentation at more than one 849 header level, even for inner fragmentation unless it goes to the 850 inner-most IP header. 852 o Unless there is verification at each reassembly, the probability 853 for undetected error will increase with the number of times 854 fragmentation is recursively applied, making IP-in-IP and UDP with 855 zero UDP checksum both vulnerable to undetected errors. 857 In conclusion, fragmentation of datagrams with a zero UDP checksum 858 does not worsen the performance compared to some other commonly used 859 tunnel encapsulations. However, caution is needed for recursive 860 tunneling without any additional verification at the different tunnel 861 layers. 863 3.2. Where Packet Corruption Occurs 865 Corruption of IP packets can occur at any point along a network path, 866 during packet generation, during transmission over the link, in the 867 process of routing and switching, etc. Some transmission steps 868 include a checksum or Cyclic Redundancy Check (CRC) that reduces the 869 probability for corrupted packets being forwarded, but there still 870 exists a probability that errors may propagate undetected. 872 Unfortunately the community lacks reliable information to identify 873 the most common functions or equipment that result in packet 874 corruption. However, there are indications that the place where 875 corruption occurs can vary significantly from one path to another. 877 There is therefore a risk in applying evidence from one domain of 878 usage to infer characteristics for another. Methods intended for 879 general Internet usage must therefore assume that corruption can 880 occur and deploy mechanisms to mitigate the effect of corruption 881 and/or resulting misdelivery. 883 3.3. Validating the network path 885 IP transports designed for use in the general Internet should not 886 assume specific path characteristics. Network protocols may reroute 887 packets that change the set of routers and middleboxes along a path. 888 Therefore transports such as TCP, SCTP and DCCP have been designed to 889 negotiate protocol parameters, adapt to different network path 890 characteristics, and receive feedback to verify that the current path 891 is suited to the intended application. Applications using UDP and 892 UDP-Lite need to provide their own mechanisms to confirm the validity 893 of the current network path. 895 A zero value in the UDP checksum field is explicitly disallowed in 896 RFC2460. Thus it may be expected that any device on the path that 897 has a reason to look beyond the IP header, for example to validate 898 the UDP checksum, will consider such a packet as erroneous or illegal 899 and may discard it, unless the device is updated to support the new 900 behavior. Any middlebox that modifies the UDP checksum, for example 901 a NAT that changes the values of the IP and UDP header in such a way 902 that the checksum over the pseudo header changes value, will need to 903 be updated to support this behavior. Until then, a zero UDP checksum 904 packet is likely to be discarded either directly in the middlebox or 905 at the destination, when a zero UDP checksum has been modified to a 906 non-zero by an incremental update. 908 A pair of end-points intending to use a new behavior will therefore 909 not only need to ensure support at each end-point, but also that the 910 path between them will deliver packets with the new behavior. This 911 may require using negotiation or an explicit mandate to use the new 912 behavior by all nodes that support the new protocol. 914 Enabling the use of a zero checksum places new requirements on 915 equipment deployed within the network, such as middleboxes. A 916 middlebox (e.g. Firewalls, Network Address Translators) may enable 917 zero checksum usage for a particular range of ports. Note that 918 checksum off-loading and operating system design may result in all 919 IPv6 UDP traffic being sent with a calculated checksum. This 920 requires middleboxes that are configured to enable a zero UDP 921 checksum to continue to work with bidirectional UDP flows that use a 922 zero UDP checksum in only one direction, and therefore they must not 923 maintain separate state for a UDP flow based on its checksum usage. 925 Support along the path between end points can be guaranteed in 926 limited deployments by appropriate configuration. In general, it can 927 be expected to take time for deployment of any updated behaviour to 928 become ubiquitous. 930 A sender will need to probe the path to verify the expected behavior. 931 Path characteristics may change, and usage therefore should be robust 932 and able to detect a failure of the path under normal usage and re- 933 negotiate. Note that a bidirectional path does not necessarily 934 support the same checksum usage in both the forward and return 935 directions: Receipt of a datagram with a zero UDP checksum, does not 936 imply that the remote endpoint can also receive a datagram with a 937 zero UDP checksum. This will require periodic validation of the 938 path, adding complexity to any solution using the new behavior. 940 3.4. Applicability of method 942 The update to the IPv6 specification defined in 943 [I-D.ietf-6man-udpchecksums] only modifies IPv6 nodes that implement 944 specific protocols designed to permit omission of a UDP checksum. 945 This document therefore provides an applicability statement for the 946 updated method indicating when the mechanism can (and can not) be 947 used. Enabling this, and ensuring correct interactions with the 948 stack, implies much more than simply disabling the checksum algorithm 949 for specific packets at the transport interface. 951 When the method is widely available, it may be expected to be used by 952 applications that are perceived to gain benefit. Any solution that 953 uses an end-to-end transport protocol, rather than an IP-in-IP 954 encapsulation, needs to minimise the possibility that application 955 processes could confuse a corrupted or wrongly delivered UDP datagram 956 with that of data addressed to the application running on their 957 endpoint. 959 The protocol or application that uses the zero checksum method must 960 ensure that the lack of checksum does not affect the protocol 961 operation. This includes being robust to receiving a unintended 962 packet from another protocol or context following corruption of a 963 destination or source address and/or port value. It also includes 964 considering the need for additional implicit protection mechanisms 965 required when using the payload of a UDP packet received with a zero 966 checksum. 968 3.5. Impact on non-supporting devices or applications 970 It is important to consider the potential impact of using a zero UDP 971 checksum on end-point devices or applications that are not modified 972 to support the new behavior or by default or preference, use the 973 regular behavior. These applications must not be significantly 974 impacted by the update. 976 To illustrate why this necessary, consider the implications of a node 977 that enables use of a zero UDP checksum at the interface level: This 978 would result in all applications that listen to a UDP socket 979 receiving datagrams where the checksum was not verified. This could 980 have a significant impact on an application that was not designed 981 with the additional robustness needed to handle received packets with 982 corruption, creating state or destroying existing state in the 983 application. 985 A zero UDP checksum therefore needs to be enabled only for individual 986 ports using an explicit request by the application. In this case, 987 applications using other ports would maintain the current IPv6 988 behavior, discarding incoming datagrams with a zero UDP checksum. 989 These other applications would not be affected by this changed 990 behavior. An application that allows the changed behavior should be 991 aware of the risk of corruption and the increased level of 992 misdirected traffic, and can be designed robustly to handle this 993 risk. 995 4. Constraints on implementation of IPv6 nodes supporting zero checksum 997 This section is an applicability statement that defines requirements 998 and recommendations on the implementation of IPv6 nodes that support 999 use of a zero value in the checksum field of a UDP datagram. 1001 All implementations that support this zero UDP checksum method MUST 1002 conform to the requirements defined below. 1004 1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for 1005 all datagrams that it sends. This explicitly permits an 1006 interface that supports checksum offloading to insert an updated 1007 UDP checksum value in all UDP datagrams that it forwards, 1008 however note that sending a calculated checksum requires the 1009 receiver to also perform the checksum calculation. Checksum 1010 offloading can normally be switched off for a particular 1011 interface to ensure that datagrams are sent with a zero UDP 1012 checksum. 1014 2. IPv6 nodes SHOULD by default NOT allow the zero UDP checksum 1015 method for transmission. 1017 3. IPv6 nodes MUST provide a way for the application/protocol to 1018 indicate the set of ports that will be enabled to send datagrams 1019 with a zero UDP checksum. This may be implemented by enabling a 1020 transport mode using a socket API call when the socket is 1021 established, or a similar mechanism. It may also be implemented 1022 by enabling the method for a pre-assigned static port used by a 1023 specific tunnel protocol. 1025 4. IPv6 nodes MUST provide a method to allow an application/ 1026 protocol to indicate that a particular UDP datagram is required 1027 to be sent with a UDP checksum. This needs to be allowed by the 1028 operating system at any time (e.g. to send keep-alive 1029 datagrams), not just when a socket is established in the zero 1030 checksum mode. 1032 5. The default IPv6 node receiver behaviour MUST discard all IPv6 1033 packets carrying datagrams with a zero UDP checksum. 1035 6. IPv6 nodes MUST provide a way for the application/protocol to 1036 indicate the set of ports that will be enabled to receive 1037 datagrams with a zero UDP checksum. This may be implemented via 1038 a socket API call, or similar mechanism. It may also be 1039 implemented by enabling the method for a pre-assigned static 1040 port used by a specific tunnel protocol. 1042 7. IPv6 nodes supporting usage of zero UDP checksums MUST also 1043 allow reception using a calculated UDP checksum on all ports 1044 configured to allow zero UDP checksum usage. (The sending 1045 endpoint, e.g. encapsulating ingress, may choose to compute the 1046 UDP checksum, or may calculate this by default.) The receiving 1047 endpoint MUST use the reception method specified in RFC2460 when 1048 the checksum field is not zero. 1050 8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams 1051 with a zero UDP checksum. This remains the case for any 1052 datagram received on a port that does not explicitly enable 1053 processing of a zero UDP checksum. A port for which the zero 1054 UDP checksum has been enabled MUST NOT log the datagram solely 1055 because the checksum value is zero. 1057 9. IPv6 nodes MAY separately identify received UDP datagrams that 1058 are discarded with a zero UDP checksum. It SHOULD NOT add these 1059 to the standard log, since the endpoint has not been verified. 1060 This may be used to support other functions (such as a security 1061 policy). 1063 10. IPv6 nodes that receive ICMPv6 messages that refer to packets 1064 with a zero UDP checksum MUST provide appropriate checks 1065 concerning the consistency of the reported packet to verify that 1066 the reported packet actually originated from the node, before 1067 acting upon the information (e.g. validating the address and 1068 port numbers in the ICMPv6 message body). 1070 5. Requirements on usage of the zero UDP checksum 1072 This section is an applicability statement that identifies 1073 requirements and recommendations for protocols and tunnel 1074 encapsulations that are transported over an IPv6 transport flow (e.g. 1075 tunnel) that does not perform a UDP checksum calculation to verify 1076 the integrity at the transport endpoints. Before deciding to use the 1077 zero UDP checksum and loose the integrity verification provided, a 1078 protocol developer should seriously consider if they can use 1079 checksummed UDP packets or UDP-Lite [RFC3828], because IPv6 with a 1080 zero UDP checksum is not equivalent in behavior to IPv4 with zero UDP 1081 checksum. 1083 The requirements and recommendations for protocols and tunnel 1084 encapsulations using an IPv6 transport flow that does not perform a 1085 UDP checksum calculation to verify the integrity at the transport 1086 endpoints are: 1088 1. Transported protocols that enable the use of zero UDP checksum 1089 MUST only enable this for a specific port or port-range. This 1090 needs to be enabled at the sending and receiving endpoints for a 1091 UDP flow. 1093 2. An integrity mechanism is always RECOMMENDED at the transported 1094 protocol layer to ensure that corruption rates of the delivered 1095 payload is not increased (e.g. the inner-most packet of a UDP 1096 tunnel). A mechanism that isolates the causes of corruption 1097 (e.g. identifying misdelivery, IPv6 header corruption, tunnel 1098 header corruption) is expected to also provide additional 1099 information about the status of the tunnel (e.g. to suggest a 1100 security attack). 1102 3. A transported protocol that encapsulates Internet Protocol (IPv4 1103 or IPv6) packets MAY rely on the inner packet integrity checks, 1104 provided that the tunnel protocol will not significantly 1105 increase the rate of corruption of the inner IP packet. If a 1106 significantly increased corruption rate can occur, then the 1107 tunnel protocol MUST provide an additional integrity 1108 verification mechanism. Early detection is desirable to avoid 1109 wasting unnecessary computation, transmission capacity or 1110 storage for packets that will subsequently be discarded. 1112 4. A transported protocol that supports use of a zero UDP checksum, 1113 MUST be designed so that corruption of this information does not 1114 result in accumulated state for the protocol. 1116 5. A transported protocol with a non-tunnel payload or one that 1117 encapsulates non-IP packets MUST have a CRC or other mechanism 1118 for checking packet integrity, unless the non-IP packet is 1119 specifically designed for transmission over a lower layer that 1120 does not provide a packet integrity guarantee. 1122 6. A transported protocol with control feedback SHOULD be robust to 1123 changes in the network path, since the set of middleboxes on a 1124 path may vary during the life of an association. The UDP 1125 endpoints need to discover paths with middleboxes that drop 1126 packets with a zero UDP checksum. Therefore, transported 1127 protocols SHOULD send keep-alive messages with a zero UDP 1128 checksum. An endpoint that discovers an appreciable loss rate 1129 for keep-alive packets MAY terminate the UDP flow (e.g. tunnel). 1130 Section 3.1.3 of RFC 5405 describes requirements for congestion 1131 control when using a UDP-based transport. 1133 7. A protocol with control feedback that can fall-back to using UDP 1134 with a calculated RFC 2460 checksum is expected to be more 1135 robust to changes in the network path. Therefore, keep-alive 1136 messages SHOULD include both UDP datagrams with a checksum and 1137 datagrams with a zero UDP checksum. This will enable the remote 1138 endpoint to distinguish between a path failure and dropping of 1139 datagrams with a zero UDP checksum. 1141 8. A middlebox implementation MUST allow forwarding of an IPv6 UDP 1142 datagram with both a zero and standard UDP checksum using the 1143 same UDP port. 1145 9. A middlebox MAY configure a restricted set of specific port 1146 ranges that forward UDP datagrams with a zero UDP checksum. The 1147 middlebox MAY drop IPv6 datagrams with a zero UDP checksum that 1148 are outside a configured range. 1150 10. When a middlebox forwards an IPv6 UDP flow containing datagrams 1151 with both a zero and standard UDP checksum, the middlebox MUST 1152 NOT maintain separate state for flows depending on the value of 1153 their UDP checksum field. (This requirement is necessary to 1154 enable a sender that always calculates a checksum to communicate 1155 via a middlebox with a remote endpoint that uses a zero UDP 1156 checksum.) 1158 Special considerations are required when designing a UDP tunnel 1159 protocol, where the tunnel ingress or egress may be a router that may 1160 not have access to the packet payload. When the node is acting as a 1161 host (i.e., sending or receiving a packet addressed to itself), the 1162 checksum processing is similar to other hosts. However, when the 1163 node (e.g. a router) is acting as a tunnel ingress or egress that 1164 forwards a packet to or from a UDP tunnel, there may be restricted 1165 access to the packet payload. This prevents calculating (or 1166 verifying) a UDP checksum. In this case, the tunnel protocol may use 1167 a zero UDP checksum and must: 1169 o Ensure that tunnel ingress and tunnel egress router are both 1170 configured to use a zero UDP checksum. For example, this may 1171 include ensuring that hardware checksum offloading is disabled. 1173 o The tunnel operator must ensure that middleboxes on the network 1174 path are updated to support use of a zero UDP checksum. 1176 o A tunnel egress should implement appropriate security techniques 1177 to protect from overload, including source address filtering to 1178 prevent traffic injection by an attacker, and rate-limiting of any 1179 packets that incur additional processing, such as UDP datagrams 1180 used for control functions that require verification of a 1181 calculated checksum to verify the network path. Usage of common 1182 control traffic for multiple tunnels between a pair of nodes can 1183 assist in reducing the number of packets to be processed. 1185 6. Summary 1187 This document provides an applicability statement for the use of UDP 1188 transport checksums with IPv6. 1190 It examines the role of the UDP transport checksum when used with 1191 IPv6 and presents a summary of the trade-offs in evaluating the 1192 safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero 1193 UDP checksum field to indicate that no checksum is present. 1195 Application designers should first examine whether their transport 1196 goals may be met using standard UDP (with a calculated checksum) or 1197 by using UDP-Lite. The use of UDP with a zero UDP checksum has 1198 merits for some applications, such as tunnel encapsulation, and is 1199 widely used in IPv4. However, there are different dangers for IPv6: 1200 There is an increased risk of corruption and misdelivery when using 1201 zero UDP checksum in IPv6 compared to using IPv4 due to the lack of 1202 an IPv6 header checksum. Thus, applications need to evaluate the 1203 risks of enabling use of a zero UDP checksum and consider a solution 1204 that at least provides the same delivery protection as for IPv4, for 1205 example by utilizing UDP-Lite, or by enabling the UDP checksum. The 1206 use of checksum off-loading may help alleviate the cost of checksum 1207 processing and permit use of a checksum using method defined in RFC 1208 2460. 1210 Tunnel applications using UDP for encapsulation can in many cases use 1211 a zero UDP checksum without significant impact on the corruption 1212 rate. A well-designed tunnel application should include consistency 1213 checks to validate the header information encapsulated with a 1214 received packet. In most cases, tunnels encapsulating IP packets can 1215 rely on the integrity protection provided by the transported protocol 1216 (or tunneled inner packet). When correctly implemented, such an 1217 endpoint will not be negatively impacted by omission of the 1218 transport-layer checksum. Recursive tunneling and fragmentation is a 1219 potential issue that can raise corruption rates significantly, and 1220 requires careful consideration. 1222 Other UDP applications at the intended destination node or another 1223 node can be impacted if they are allowed to receive datagrams that 1224 have a zero UDP checksum. It is important that already deployed 1225 applications are not impacted by a change at the transport layer. If 1226 these applications execute on nodes that implement RFC 2460, they 1227 will discard (and log) all datagrams with a zero UDP checksum. This 1228 is not an issue. 1230 In general, UDP-based applications need to employ a mechanism that 1231 allows a large percentage of the corrupted packets to be removed 1232 before they reach an application, both to protect the data stream of 1233 the application and the control plane of higher layer protocols. 1234 These checks are currently performed by the UDP checksum for IPv6, or 1235 the reduced checksum for UDP-Lite when used with IPv6. 1237 The transport of recursive tunneling and the use of fragmentation 1238 pose difficult issues that need to be considered in the design of 1239 tunnel protocols. There is an increased risk of an error in the 1240 inner-most packet when fragmentation when several layers of tunneling 1241 and several different reassembly processes are run without 1242 verification of correctness. This requires extra thought and careful 1243 consideration in the design of transported tunnels. 1245 Any use of the updated method must consider the implications on 1246 firewalls, NATs and other middleboxes. It is not expected that IPv6 1247 NATs handle IPv6 UDP datagrams in the same way that they handle IPv4 1248 UDP datagrams. In many deployed cases this will require an update to 1249 support an IPv6 zero UDP checksum. Firewalls are intended to be 1250 configured, and therefore may need to be explicitly updated to allow 1251 new services or protocols. IPv6 middlebox deployment is not yet as 1252 prolific as it is in IPv4, and therefore new devices are expected to 1253 follow the methods specified in this document. 1255 Each application should consider the implications of choosing an IPv6 1256 transport that uses a zero UDP checksum, and consider whether other 1257 standard methods may be more appropriate, and may simplify 1258 application design. 1260 7. Acknowledgements 1262 Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert, 1263 others in the TSV directorate. Barry Leiba, Ronald Bonica, Pete 1264 Resnick, and Stewart Bryant are thanked for resulting in a document 1265 with much greater applicability. Thanks to P.F. Chimento for careful 1266 review and editorial corrections. 1268 Thanks also to: Remi Denis-Courmont, Pekka Savola, Glen Turner, and 1269 many others who contributed comments and ideas via the 6man, behave, 1270 lisp and mboned lists. 1272 8. IANA Considerations 1274 This document does not require any actions by IANA. 1276 9. Security Considerations 1278 Transport checksums provide the first stage of protection for the 1279 stack, although they can not be considered authentication mechanisms. 1280 These checks are also desirable to ensure packet counters correctly 1281 log actual activity, and can be used to detect unusual behaviours. 1283 Depending on the hardware design, the processing requirements may 1284 differ for tunnels that have a zero UDP checksum and those that 1285 calculate a checksum. This processing overhead may need to be 1286 considered when deciding whether to enable a tunnel and to determine 1287 an acceptable rate for transmission. This can become a security risk 1288 for designs that can handle a significantly larger number of packets 1289 with zero UDP checksums compared to datagrams with a non-zero 1290 checksum, such as tunnel egress. An attacker could attempt to inject 1291 non-zero checksummed UDP packets into a tunnel forwarding zero 1292 checksum UDP packets and cause overload in the processing of the non- 1293 zero checksums, e.g. if this happens in a routers slow path. 1294 Protection mechanisms should therefore be employed when this threat 1295 exists. Protection may include source address filtering to prevent 1296 an attacker injecting traffic, as well as throttling the amount of 1297 non-zero checksum traffic. The latter may impact the function of the 1298 tunnel protocol. 1300 Transmission of IPv6 packets with a zero UDP checksum could reveal 1301 additional information to an on-path attacker to identify the 1302 operating system or configuration of a sending node. There is a need 1303 to probe the network path to determine whether the current path 1304 supports using IPv6 packets with a zero UDP checksum. The details of 1305 the probing mechanism may differ for different tunnel encapsulations 1306 and if visible in the network (e.g. if not using IPsec in encryption 1307 mode) could reveal additional information to an on-path attacker to 1308 identify the type of tunnel being used. 1310 IP-in-IP or GRE tunnels offer good traversal of middleboxes that have 1311 not been designed for security, e.g. firewalls. However, firewalls 1312 may be expected to be configured to block general tunnels as they 1313 present a large attack surface. This applicability statement 1314 therefore permits this method to be enabled only for specific ranges 1315 of ports. 1317 When the zero UDP checksum mode is enabled for a range of ports, 1318 nodes and middleboxes must forward received UDP datagrams that have 1319 either a calculated checksum or a zero checksum. 1321 10. References 1323 10.1. Normative References 1325 [I-D.ietf-6man-udpchecksums] 1326 Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1327 UDP Checksums for Tunneled Packets", 1328 draft-ietf-6man-udpchecksums-08 (work in progress), 1329 February 2013. 1331 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1332 August 1980. 1334 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1335 September 1981. 1337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1338 Requirement Levels", BCP 14, RFC 2119, March 1997. 1340 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1341 (IPv6) Specification", RFC 2460, December 1998. 1343 10.2. Informative References 1345 [I-D.ietf-intarea-tunnels] 1346 Touch, J. and M. Townsley, "Tunnels in the Internet 1347 Architecture", draft-ietf-intarea-tunnels-00 (work in 1348 progress), March 2010. 1350 [I-D.ietf-mboned-auto-multicast] 1351 Bumgardner, G., "Automatic Multicast Tunneling", 1352 draft-ietf-mboned-auto-multicast-14 (work in progress), 1353 June 2012. 1355 [LISP] D. Farinacci et al, "Locator/ID Separation Protocol 1356 (LISP)", November 2012. 1358 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1359 "Computing the Internet checksum", RFC 1071, 1360 September 1988. 1362 [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the 1363 Internet checksum", RFC 1141, January 1990. 1365 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 1366 Incremental Update", RFC 1624, May 1994. 1368 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1369 Defeating Denial of Service Attacks which employ IP Source 1370 Address Spoofing", BCP 38, RFC 2827, May 2000. 1372 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1373 Jacobson, "RTP: A Transport Protocol for Real-Time 1374 Applications", STD 64, RFC 3550, July 2003. 1376 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1377 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1378 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1379 RFC 3819, July 2004. 1381 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1382 G. Fairhurst, "The Lightweight User Datagram Protocol 1383 (UDP-Lite)", RFC 3828, July 2004. 1385 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1386 Message Protocol (ICMPv6) for the Internet Protocol 1387 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1389 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1390 Errors at High Data Rates", RFC 4963, July 2007. 1392 [RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite 1393 protocol", RFC 5097, January 2008. 1395 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1396 for Application Designers", BCP 145, RFC 5405, 1397 November 2008. 1399 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 1400 Provisioning of Wireless Access Points (CAPWAP) Protocol 1401 Specification", RFC 5415, March 2009. 1403 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1404 RFC 5722, December 2009. 1406 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1407 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1409 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 1410 for Equal Cost Multipath Routing and Link Aggregation in 1411 Tunnels", RFC 6438, November 2011. 1413 [Sigcomm2000] 1414 Jonathan Stone and Craig Partridge , "When the CRC and TCP 1415 Checksum Disagree", 2000. 1417 [UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. 1419 Appendix A. Evaluation of proposal to update RFC 2460 to support zero 1420 checksum 1422 This informative appendix documents the evaluation of the proposal to 1423 update IPv6 [RFC2460], to provide the option that some nodes may 1424 suppress generation and checking of the UDP transport checksum. It 1425 also compares the proposal with other alternatives, and notes that 1426 for a particular application some standard methods may be more 1427 appropriate than using IPv6 with a zero UDP checksum. 1429 A.1. Alternatives to the Standard Checksum 1431 There are several alternatives to the normal method for calculating 1432 the UDP Checksum [RFC1071] that do not require a tunnel endpoint to 1433 inspect the entire packet when computing a checksum. These include 1434 (in decreasing order of complexity): 1436 o Delta computation of the checksum from an encapsulated checksum 1437 field. Since the checksum is a cumulative sum [RFC1624], an 1438 encapsulating header checksum can be derived from the new pseudo 1439 header, the inner checksum and the sum of the other network-layer 1440 fields not included in the pseudo header of the encapsulated 1441 packet, in a manner resembling incremental checksum update 1442 [RFC1141]. This would not require access to the whole packet, but 1443 does require fields to be collected across the header, and 1444 arithmetic operations on each packet. The method would only work 1445 for packets that contain a 2's complement transport checksum 1446 (i.e., it would not be appropriate for SCTP or when IP 1447 fragmentation is used). 1449 o UDP-Lite with the checksum coverage set to only the header portion 1450 of a packet. This requires a pseudo header checksum calculation 1451 only on the encapsulating packet header. The computed checksum 1452 value may be cached (before adding the Length field) for each 1453 flow/destination and subsequently combined with the Length of each 1454 packet to minimise per-packet processing. This value is combined 1455 with the UDP payload length for the pseudo header, however this 1456 length is expected to be known when performing packet forwarding. 1458 o The proposed UDP Tunnel Transport [UDPTT] suggested a method where 1459 UDP would be modified to derive the checksum only from the 1460 encapsulating packet protocol header. This value does not change 1461 between packets in a single flow. The value may be cached per 1462 flow/destination to minimise per-packet processing. 1464 o There has been a proposal to simply ignore the UDP checksum value 1465 on reception at the tunnel egress, allowing a tunnel ingress to 1466 insert any value correct or false. For tunnel usage, a non 1467 standard checksum value may be used, forcing an RFC 2460 receiver 1468 to drop the packet. The main downside is that it would be 1469 impossible to identify a UDP datagram (in the network or an 1470 endpoint) that is treated in this way compared to a packet that 1471 has actually been corrupted. 1473 o A method has been proposed that uses a new (to be defined) IPv6 1474 Destination Options Header to provide an end-to-end validation 1475 check at the network layer. This would allow an endpoint to 1476 verify delivery to an appropriate end point, but would also 1477 require IPv6 nodes to correctly handle the additional header, and 1478 would require changes to middlebox behavior (e.g. when used with a 1479 NAT that always adjusts the checksum value). 1481 o UDP modified to disable checksum processing 1482 [I-D.ietf-6man-udpchecksums]. This eliminates the need for a 1483 checksum calculation, but would require constraints on appropriate 1484 usage and updates to end-points and middleboxes. 1486 o IP-in-IP tunneling. As this method completely dispenses with a 1487 transport protocol in the outer-layer it has reduced overhead and 1488 complexity, but also reduced functionality. There is no outer 1489 checksum over the packet and also no ports to perform 1490 demultiplexing between different tunnel types. This reduces the 1491 information available upon which a load balancer may act. 1493 These options are compared and discussed further in the following 1494 sections. 1496 A.2. Comparison 1498 This section compares the above listed methods to support datagram 1499 tunneling. It includes proposals for updating the behaviour of UDP. 1501 While this comparison focuses on applications that are expected to 1502 execute on routers, the distinction between a router and a host is 1503 not always clear, especially at the transport level. Systems (such 1504 as unix-based operating systems) routinely provide both functions. 1505 There is no way to identify the role of the receiving node from a 1506 received packet. 1508 A.2.1. Middlebox Traversal 1510 Regular UDP with a standard checksum or the delta encoded 1511 optimization for creating correct checksums have the best 1512 possibilities for successful traversal of a middlebox. No new 1513 support is required. 1515 A method that ignores the UDP checksum on reception is expected to 1516 have a good probability of traversal, because most middleboxes 1517 perform an incremental checksum update. UDPTT would also have been 1518 able to traverse a middlebox with this behaviour. However, a 1519 middlebox on the path that attempts to verify a standard checksum 1520 will not forward packets using either of these methods, preventing 1521 traversal. A method that ignores the checksum has an additional 1522 downside in that it prevents improvement of middlebox traversal, 1523 because there is no way to identify UDP datagrams that use the 1524 modified checksum behaviour. 1526 IP-in-IP or GRE tunnels offer good traversal of middleboxes that have 1527 not been designed for security, e.g. firewalls. However, firewalls 1528 may be expected to be configured to block general tunnels as they 1529 present a large attack surface. 1531 A new IPv6 Destination Options header will suffer traversal issues 1532 with middleboxes, especially Firewalls and NATs, and will likely 1533 require them to be updated before the extension header is passed. 1535 Datagrams with a zero UDP checksum will not be passed by any 1536 middlebox that validates the checksum using RFC 2460 or updates the 1537 checksum field, such as NAT or firewalls. This would require an 1538 update to correctly handle a datagram with a zero UDP checksum. 1540 UDP-Lite will require an update of almost all type of middleboxes, 1541 because it requires support for a separate network-layer protocol 1542 number. Once enabled, the method to support incremental checksum 1543 update would be identical to that for UDP, but different for checksum 1544 validation. 1546 A.2.2. Load Balancing 1548 The usefulness of solutions for load balancers depends on the 1549 difference in entropy in the headers for different flows that can be 1550 included in a hash function. All the proposals that use the UDP 1551 protocol number have equal behavior. UDP-Lite has the potential for 1552 equally good behavior as for UDP. However, UDP-Lite is currently 1553 unlikely to be supported by deployed hashing mechanisms, which could 1554 cause a load balancer to not use the transport header in the computed 1555 hash. A load balancer that only uses the IP header will have low 1556 entropy, but could be improved by including the IPv6 the flow label, 1557 providing that the tunnel ingress ensures that different flow labels 1558 are assigned to different flows. However, a transition to the common 1559 use of good quality flow labels is likely to take time to deploy. 1561 A.2.3. Ingress and Egress Performance Implications 1563 IP-in-IP tunnels are often considered efficient, because they 1564 introduce very little processing and low data overhead. The other 1565 proposals introduce a UDP-like header incurring associated data 1566 overhead. Processing is minimised for the method that uses a zero 1567 UDP checksum, ignoring the UDP checksum on reception, and only 1568 slightly higher for UDPTT, the extension header and UDP-Lite. The 1569 delta-calculation scheme operates on a few more fields, but also 1570 introduces serious failure modes that can result in a need to 1571 calculate a checksum over the complete datagram. Regular UDP is 1572 clearly the most costly to process, always requiring checksum 1573 calculation over the entire datagram. 1575 It is important to note that the zero UDP checksum method, ignoring 1576 checksum on reception, the Option Header, UDPTT and UDP-Lite will 1577 likely incur additional complexities in the application to 1578 incorporate a negotiation and validation mechanism. 1580 A.2.4. Deployability 1582 The major factors influencing deployability of these solutions are a 1583 need to update both end-points, a need for negotiation and the need 1584 to update middleboxes. These are summarised below: 1586 o The solution with the best deployability is regular UDP. This 1587 requires no changes and has good middlebox traversal 1588 characteristics. 1590 o The next easiest to deploy is the delta checksum solution. This 1591 does not modify the protocol on the wire and only needs changes in 1592 tunnel ingress. 1594 o IP-in-IP tunnels should not require changes to the end-points, but 1595 raise issues when traversing firewalls and other security devices, 1596 which are expected to require updates. 1598 o Ignoring the checksum on reception will require changes at both 1599 end-points. The never ceasing risk of path failure requires 1600 additional checks to ensure this solution is robust and will 1601 require changes or additions to the tunnel control protocol to 1602 negotiate support and validate the path. 1604 o The remaining solutions (including the zero checksum method) offer 1605 similar deployability. UDP-Lite requires support at both end- 1606 points and in middleboxes. UDPTT and the zero UDP checksum method 1607 with or without an extension header require support at both end- 1608 points and in middleboxes. UDP-Lite, UDPTT, and the zero UDP 1609 checksum method and use of extension headers may additionally 1610 require changes or additions to the tunnel control protocol to 1611 negotiate support and path validation. 1613 A.2.5. Corruption Detection Strength 1615 The standard UDP checksum and the delta checksum can both provide 1616 some verification at the tunnel egress. This can significantly 1617 reduce the probability that a corrupted inner packet is forwarded. 1618 UDP-Lite, UDPTT and the extension header all provide some 1619 verification against corruption, but do not verify the inner packet. 1620 They only provide a strong indication that the delivered packet was 1621 intended for the tunnel egress and was correctly delimited. 1623 The methods using a zero UDP checksum, ignoring the UDP checksum on 1624 reception and IP-and-IP encapsulation all provide no verification 1625 that a received datagram was intended to be processed by a specific 1626 tunnel egress or that the inner encapsulated packet was correct. 1627 Section 3.1 discusses experience using specific protocols in well- 1628 managed networks. 1630 A.2.6. Comparison Summary 1632 The comparisons above may be summarised as "there is no silver bullet 1633 that will slay all the issues". One has to select which down side(s) 1634 can best be lived with. Focusing on the existing solutions, this can 1635 be summarized as: 1637 Regular UDP: The method defined in RFC 2460 has good middlebox 1638 traversal and load balancing and multiplexing, requiring a 1639 checksum in the outer headers covering the whole packet. 1641 IP in IP: A low complexity encapsulation, with limited middlebox 1642 traversal, no multiplexing support, and currently poor load 1643 balancing support that could improve over time. 1645 UDP-Lite: A medium complexity encapsulation, with good multiplexing 1646 support, limited middlebox traversal, but possible to improve over 1647 time, currently poor load balancing support that could improve 1648 over time, in most cases requiring application level negotiation 1649 to select the protocol and validation to confirm the path forwards 1650 UDP-Lite. 1652 The delta-checksum is an optimization in the processing of UDP, as 1653 such it exhibits some of the drawbacks of using regular UDP. 1655 The remaining proposals may be described in similar terms: 1657 Zero-Checksum: A low complexity encapsulation, with good 1658 multiplexing support, limited middlebox traversal that could 1659 improve over time, good load balancing support, in most cases 1660 requiring application level negotiation and validation to confirm 1661 the path forwards a zero UDP checksum. 1663 UDPTT: A medium complexity encapsulation, with good multiplexing 1664 support, limited middlebox traversal, but possible to improve over 1665 time, good load balancing support, in most cases requiring 1666 application level negotiation to select the transport and 1667 validation to confirm the path forwards UDPTT datagrams. 1669 IPv6 Destination Option IP in IP tunneling: A medium complexity, 1670 with no multiplexing support, limited middlebox traversal, 1671 currently poor load balancing support that could improve over 1672 time, in most cases requiring negotiation to confirm the option is 1673 supported and validation to confirm the path forwards the option. 1675 IPv6 Destination Option combined with UDP Zero-checksuming: A medium 1676 complexity encapsulation, with good multiplexing support, limited 1677 load balancing support that could improve over time, in most cases 1678 requiring negotiation to confirm the option is supported and 1679 validation to confirm the path forwards the option. 1681 Ignore the checksum on reception: A low complexity encapsulation, 1682 with good multiplexing support, medium middlebox traversal that 1683 never can improve, good load balancing support, in most cases 1684 requiring negotiation to confirm the option is supported by the 1685 remote endpoint and validation to confirm the path forwards a zero 1686 UDP checksum. 1688 There is no clear single optimum solution. If the most important 1689 need is to traverse middleboxes, then the best choice is to stay with 1690 regular UDP and consider the optimizations that may be required to 1691 perform the checksumming. If one can live with limited middlebox 1692 traversal, low complexity is necessary and one does not require load 1693 balancing, then IP-in-IP tunneling is the simplest. If one wants 1694 strengthened error detection, but with currently limited middlebox 1695 traversal and load-balancing. UDP-Lite is appropriate. Zero UDP 1696 checksum addresses another set of constraints, low complexity and a 1697 need for load balancing from the current Internet, providing it can 1698 live with currently limited middlebox traversal. 1700 Techniques for load balancing and middlebox traversal do continue to 1701 evolve. Over a long time, developments in load balancing have good 1702 potential to improve. This time horizon is long since it requires 1703 both load balancer and end-point updates to get full benefit. The 1704 challenges of middlebox traversal are also expected to change with 1705 time, as device capabilities evolve. Middleboxes are very prolific 1706 with a larger proportion of end-user ownership, and therefore may be 1707 expected to take long time cycles to evolve. 1709 One potential advantage is that the deployment of IPv6-capable 1710 middleboxes are still in its initial phase and the quicker a new 1711 method becomes standardized, the fewer boxes will be non-compliant. 1713 Thus, the question of whether to permit use of datagrams with a zero 1714 UDP checksum for IPv6 under reasonable constraints, is therefore best 1715 viewed as a trade-off between a number of more subjective questions: 1717 o Is there sufficient interest in using a zero UDP checksum with the 1718 given constraints (summarised below)? 1720 o Are there other avenues of change that will resolve the issue in a 1721 better way and sufficiently quickly ? 1723 o Do we accept the complexity cost of having one more solution in 1724 the future? 1726 The analysis concludes that the IETF should carefully consider 1727 constraints on sanctioning the use of any new transport mode. The 1728 6man working group of the IETF has determined that the answer to the 1729 above questions are sufficient to update IPv6 to standardise use of a 1730 zero UDP checksum for use by tunnel encapsulations for specific 1731 applications. 1733 Each application should consider the implications of choosing an IPv6 1734 transport that uses a zero UDP checksum. In many cases, standard 1735 methods may be more appropriate, and may simplify application design. 1736 The use of checksum off-loading may help alleviate the checksum 1737 processing cost and permit use of a checksum using method defined in 1738 RFC 2460. 1740 Appendix B. Document Change History 1742 {RFC EDITOR NOTE: This section must be deleted prior to publication} 1744 Individual Draft 00 This is the first DRAFT of this document - It 1745 contains a compilation of various discussions and contributions 1746 from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, 1747 and behave. This includes contributions from Magnus with text on 1748 RTP, and various updates. 1750 Individual Draft 01 1752 * This version corrects some typos and editorial NiTs and adds 1753 discussion of the need to negotiate and verify operation of a 1754 new mechanism (3.3.4). 1756 Individual Draft 02 1758 * Version -02 corrects some typos and editorial NiTs. 1760 * Added reference to ECMP for tunnels. 1762 * Clarifies the recommendations at the end of the document. 1764 Working Group Draft 00 1766 * Working Group Version -00 corrects some typos and removes much 1767 of rationale for UDPTT. It also adds some discussion of IPv6 1768 extension header. 1770 Working Group Draft 01 1772 * Working Group Version -01 updates the rules and incorporates 1773 off-list feedback. This version is intended for wider review 1774 within the 6man working group. 1776 Working Group Draft 02 1778 * This version is the result of a major rewrite and re-ordering 1779 of the document. 1781 * A new section comparing the results have been added. 1783 * The constraints list has been significantly altered by removing 1784 some and rewording other constraints. 1786 * This contains other significant language updates to clarify the 1787 intent of this draft. 1789 Working Group Draft 03 1791 * Editorial updates 1793 Working Group Draft 04 1795 * Resubmission only updating the AMT and RFC2765 references. 1797 Working Group Draft 05 1799 * Resubmission to correct editorial NiTs - thanks to Bill Atwood 1800 for noting these.Group Draft 05. 1802 Working Group Draft 06 1804 * Resubmission to keep draft alive (spelling updated from 05). 1806 Working Group Draft 07 1808 * Interim Version 1810 * Submission after IESG Feedback Added 1812 * Updates to enable the document to become a PS Applicability 1813 Statement 1815 Working Group Draft 08 1817 * First Version written as a PS Applicability Statement 1819 * Changes to reflect decision to update RFC 2460, rather than 1820 recommend decision 1822 * Updates to requirements for middleboxes 1823 * Inclusion of requirements for security, API, and tunnel 1825 * Move of the rationale for the update to an Annex (former 1826 section 4) 1828 Working Group Draft 09 1830 * Submission after second WGLC (note mistake corrected in -09). 1832 * Clarified role of API for supporting full checksum. 1834 * Clarified that full checksum is required in security 1835 considerations, and therefore noting that full checksum should 1836 not be treated as an attack - consistent with remainder of 1837 document. 1839 * Added mention that API can set a mode in transport stack - to 1840 link to similar statement in RFC 2460 update. 1842 * Fixed typos. 1844 Working Group Draft 10 1846 * Submission to correct unwanted removal of text from section 5 1847 bullets 5-7 by GF. 1849 * Replaced section 5 text with the text from 08, and reapplied 1850 the editorial correction. 1852 * Note to reviewers: Please compare this revision with -08 used 1853 in the IETF LC). 1855 Working Group Draft 11 1857 * Added REF for 5097 (Noted by S.Turner) 1859 * Added text in response to P. Resnick on place where checksum is 1860 calculated. 1862 * Added text to note experience with MPLS/PWE; Appendix updated 1863 to refer to this (S. Bryant) 1865 * Added text in response to P.Resnick's 2nd comments. 1867 * Request to make UDP-Lite more clearly recommended (J Touch, 1868 P.Resnick) 1870 * Added considerations around usage of zero checksum in routers. 1872 * Added text in response to Stewart Bryant's comments on router 1873 requirements. 1875 Authors' Addresses 1877 Godred Fairhurst 1878 University of Aberdeen 1879 School of Engineering 1880 Aberdeen, AB24 3UE 1881 Scotland, UK 1883 Email: gorry@erg.abdn.ac.uk 1884 URI: http://www.erg.abdn.ac.uk/users/gorry 1886 Magnus Westerlund 1887 Ericsson 1888 Farogatan 6 1889 Stockholm, SE-164 80 1890 Sweden 1892 Phone: +46 8 719 0000 1893 Email: magnus.westerlund@ericsson.com