idnits 2.17.1 draft-ietf-6man-udpzero-04.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 (October 25, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-08) exists of draft-ietf-6man-udpchecksums-00 == 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-11 -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: Informational M. Westerlund 5 Expires: April 27, 2012 Ericsson 6 October 25, 2011 8 IPv6 UDP Checksum Considerations 9 draft-ietf-6man-udpzero-04 11 Abstract 13 This document examines the role of the UDP transport checksum when 14 used with IPv6, as defined in RFC2460. It presents a summary of the 15 trade-offs for evaluating the safety of updating RFC 2460 to permit 16 an IPv6 UDP endpoint to use a zero value in the checksum field as an 17 indication that no checksum is present. This method is compared with 18 some other possibilities. The document also describes the issues and 19 design principles that need to be considered when UDP is used with 20 IPv6 to support tunnel encapsulations. It concludes that UDP with a 21 zero checksum in IPv6 can safely be used for this purpose, provided 22 that this usage is governed by a set of constraints. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 27, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.2.1. The Role of a Transport Endpoint . . . . . . . . . . . 5 62 1.2.2. The UDP Checksum . . . . . . . . . . . . . . . . . . . 5 63 1.2.3. Differences between IPv6 and IPv4 . . . . . . . . . . 7 64 1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 7 65 1.3.1. Motivation for new approaches . . . . . . . . . . . . 8 66 1.3.2. Reducing forwarding cost . . . . . . . . . . . . . . . 8 67 1.3.3. Need to inspect the entire packet . . . . . . . . . . 9 68 1.3.4. Interactions with middleboxes . . . . . . . . . . . . 9 69 1.3.5. Support for load balancing . . . . . . . . . . . . . . 10 70 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 10 71 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 10 72 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 11 74 2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 11 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 . . . . . . . . . 14 79 3.1.3. Corruption of Port Information . . . . . . . . . . . . 15 80 3.1.4. Delivery to an unexpected port . . . . . . . . . . . . 15 81 3.1.5. Corruption of Fragmentation Information . . . . . . . 16 82 3.2. Validating the network path . . . . . . . . . . . . . . . 18 83 3.3. Applicability of method . . . . . . . . . . . . . . . . . 19 84 3.4. Impact on non-supporting devices or applications . . . . . 20 85 4. Evaluation of proposal to update RFC 2460 to support zero 86 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 4.1. Alternatives to the Standard Checksum . . . . . . . . . . 20 88 4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 22 89 4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 22 90 4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 23 91 4.2.3. Ingress and Egress Performance Implications . . . . . 23 92 4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 23 93 4.2.5. Corruption Detection Strength . . . . . . . . . . . . 24 94 4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 24 95 5. Requirements on the specification of transported protocols . . 26 96 5.1. Constraints required on usage of a zero checksum . . . . . 26 97 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 104 Appendix A. Document Change History . . . . . . . . . . . . . . . 32 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 107 1. Introduction 109 The User Datagram Protocol (UDP) [RFC0768] transport is defined for 110 the Internet Protocol (IPv4) [RFC0791] and is defined in Internet 111 Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The 112 UDP transport protocol has a minimal set of features. This limited 113 set has enabled a wide range of applications to use UDP, but these 114 application do need to provide many important transport functions on 115 top of UDP. The UDP Usage Guidelines [RFC5405] provides overall 116 guidance for application designers, including the use of UDP to 117 support tunneling. The key difference between UDP usage with IPv4 118 and IPv6 is that IPv6 mandates use of the UDP checksum, i.e. a non- 119 zero value, due to the lack of an IPv6 header checksum. 121 The lack of a possibility to use UDP with a zero-checksum in IPv6 has 122 been observed as a real problem for certain classes of application, 123 primarily tunnel applications. This class of application has been 124 deployed with a zero checksum using IPv4. The design of IPv6 raises 125 different issues when considering the safety of using a zero checksum 126 for UDP with IPv6. These issues can significantly affect 127 applications, both when an endpoint is the intended user and when an 128 innocent bystander (received by a different endpoint to that 129 intended). The document examines these issues and compares the 130 strengths and weaknesses of a number of proposed solutions. This 131 analysis presents a set of issues that must be considered and 132 mitigated to be able to safely deploy UDP with a zero checksum over 133 IPv6. The provided comparison of methods is expected to also be 134 useful when considering applications that have different goals from 135 the ones that initiated the writing of this document, especially the 136 use of already standardized methods. 138 The analysis concludes that using UDP with a zero checksum is the 139 best method of the proposed alternatives to meet the goals for 140 certain tunnel applications. Unfortunately, this usage is expected 141 to have some deployment issues related to middleboxes, limiting the 142 usability more than desired in the currently deployed internet. 143 However, this limitation will be largest initially and will reduce as 144 updates for support of UDP zero checksum for IPv6 are provided to 145 middleboxes. The document therefore derives a set of constraints 146 required to ensure safe deployment of zero checksum in UDP. It also 147 identifies some issues that require future consideration and possibly 148 additional research. 150 1.1. Document Structure 152 Section 1 provides a background to key issues, and introduces the use 153 of UDP as a tunnel transport protocol. 155 Section 2 describes a set of standards-track datagram transport 156 protocols that may be used to support tunnels. 158 Section 3 discusses issues with a zero checksum in UDP for IPv6. It 159 considers the impact of corruption, the need for validation of the 160 path and when it is suitable to use a zero checksum. 162 Section 4 evaluates a set of proposals to update the UDP transport 163 behaviour and other alternatives intended to improve support for 164 tunnel protocols. It focuses on a proposal to allow a zero checksum 165 for this use-case with IPv6 and assess the trade-offs that would 166 arise. 168 Section 5.1 lists the constraints perceived for safe deployment of 169 zero-checksum. 171 Section 6 provides the recommendations for standardization of zero- 172 checksum with a summary of the findings and notes remaining issues 173 needing future work. 175 1.2. Background 177 This section provides a background on topics relevant to the 178 following discussion. 180 1.2.1. The Role of a Transport Endpoint 182 An Internet transport endpoint should concern itself with the 183 following issues: 185 o Protection of the endpoint transport state from unnecessary extra 186 state (e.g. Invalid state from rogue packets). 188 o Protection of the endpoint transport state from corruption of 189 internal state. 191 o Pre-filtering by the endpoint of erroneous data, to protect the 192 transport from unnecessary processing and from corruption that it 193 can not itself reject. 195 o Pre-filtering of incorrectly addressed destination packets, before 196 responding to a source address. 198 1.2.2. The UDP Checksum 200 UDP, as defined in [RFC0768], supports two checksum behaviours when 201 used with IPv4. The normal behaviour is for the sender to calculate 202 a checksum over a block of data that includes a pseudo header and the 203 UDP datagram payload. The UDP header includes a 16-bit one's 204 complement checksum that provides a statistical guarantee that the 205 payload was not corrupted in transit. This also allows a receiver to 206 verify that the endpoint was the intended destination of the 207 datagram, because the transport pseudo header covers the IP 208 addresses, port numbers, transport payload length, and Next Header/ 209 Protocol value corresponding to the UDP transport protocol [RFC1071]. 210 The length field verifies that the datagram is not truncated or 211 padded. The checksum therefore protects an application against 212 receiving corrupted payload data in place of, or in addition to, the 213 data that was sent. Although the IPv4 UDP [RFC0768] checksum may be 214 disabled, applications are recommended to enable UDP checksums 215 [RFC5405]. 217 The network-layer fields that are validated by a transport checksum 218 are: 220 o Endpoint IP source address (always included in the pseudo header 221 of the checksum) 223 o Endpoint IP destination address (always included in the pseudo 224 header of the checksum) 226 o Upper layer payload type (always included in the pseudo header of 227 the checksum) 229 o IP length of payload (always included in the pseudo header of the 230 checksum) 232 o Length of the network layer extension headers (i.e. by correct 233 position of the checksum bytes) 235 The transport-layer fields that are validated by a transport checksum 236 are: 238 o Transport demultiplexing, i.e. ports (always included in the 239 checksum) 241 o Transport payload size (always included in the checksum) 243 Transport endpoints also need to verify the correctness of reassembly 244 of any fragmented datagram. For UDP, this is normally provided as a 245 part of the integrity check. Disabling the IPv4 checksum prevents 246 this check. A lack of the UDP header and checksum in fragments can 247 lead to issues in a translator or middlebox. For example, many IPv4 248 Network Address Translators, NATs, rely on port numbers to find the 249 mappings, packet fragments do not carry port numbers, so fragments 250 get dropped. IP/ICMP Translation Algorithm [RFC6145] provides some 251 guidance on the processing of fragmented IPv4 UDP datagrams that do 252 not carry a UDP checksum. 254 IPv4 UDP checksum control is often a kernel-wide configuration 255 control (e.g. In Linux and BSD), rather than a per socket call. 256 There are also Networking Interface Cards (NICs) that automatically 257 calculate TCP [RFC0793] and UDP checksums on transmission when a 258 checksum of zero is sent to the NIC, using a method known as checksum 259 offloading. 261 1.2.3. Differences between IPv6 and IPv4 263 IPv6 does not provide a network-layer integrity check. The removal 264 of the header checksum from the IPv6 specification released routers 265 from a need to update a network-layer checksum for each router hop as 266 the IPv6 Hop Count is changed (in contrast to the checksum update 267 needed when an IPv4 router modifies the Time-To-Live (TTL)). 269 The IP header checksum calculation was seen as redundant for most 270 traffic (with UDP or TCP checksums enabled), and people wanted to 271 avoid this extra processing. However, there was concern that the 272 removal of the IP header checksum in IPv6 combined with a UDP 273 checksum set to zero would lessen the protection of the source/ 274 destination IP addresses and result in a significant (a multiplier of 275 ~32,000) increase in the number of times that a UDP packet was 276 accidentally delivered to the wrong destination address and/or 277 apparently sourced from the wrong source address. This would have 278 had implications on the detectability of mis-delivery of a packet to 279 an incorrect endpoint/socket, and the robustness of the Internet 280 infrastructure. The use of the UDP checksum is therefore required 281 [RFC2460] when endpoint applications transmit UDP datagrams over 282 IPv6. 284 1.3. Use of UDP Tunnels 286 One increasingly popular use of UDP is as a tunneling protocol, where 287 a tunnel endpoint encapsulates the packets of another protocol inside 288 UDP datagrams and transmits them to another tunnel endpoint. Using 289 UDP as a tunneling protocol is attractive when the payload protocol 290 is not supported by the middleboxes that may exist along the path, 291 because many middleboxes support transmission using UDP. In this 292 use, the receiving endpoint decapsulates the UDP datagrams and 293 forwards the original packets contained in the payload [RFC5405]. 294 Tunnels establish virtual links that appear to directly connect 295 locations that are distant in the physical Internet topology and can 296 be used to create virtual (private) networks. 298 1.3.1. Motivation for new approaches 300 A number of tunnel encapsulations deployed over IPv4 have used the 301 UDP transport with a zero checksum. Users of these protocols expect 302 a similar solution for IPv6. 304 A number of tunnel protocols are also currently being defined (e.g. 305 Automated Multicast Tunnels, AMT [I-D.ietf-mboned-auto-multicast], 306 and the Locator/Identifier Separation Protocol, LISP [LISP]). These 307 protocols have proposed an update to IPv6 UDP checksum processing. 308 These tunnel protocols could benefit from simpler checksum processing 309 for various reasons: 311 o Reducing forwarding costs, motivated by redundancy present in the 312 encapsulated packet header, since in tunnel encapsulations, 313 payload integrity and length verification may be provided by 314 higher layer encapsulations (often using the IPv4, UDP, UDP-Lite, 315 or TCP checksums). 317 o Eliminating a need to access the entire packet when forwarding the 318 packet by a tunnel endpoint. 320 o Enhancing ability to traverse middleboxes, especially Network 321 Address Translators, NATs. 323 o A desire to use the port number space to enable load-sharing. 325 1.3.2. Reducing forwarding cost 327 It is a common requirement to terminate a large number of tunnels on 328 a single router/host. Processing per tunnel concerns both state 329 (memory requirements) and per-packet processing costs. 331 Automatic IP Multicast Without Explicit Tunnels, known as AMT 332 [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the 333 transport protocol for packets carrying tunneled IP multicast 334 packets. The current specification for AMT requires that the UDP 335 checksum in the outer packet header should be 0 (see Section 6.6 of 336 [I-D.ietf-mboned-auto-multicast]). It argues that the computation of 337 an additional checksum, when an inner packet is already adequately 338 protected, is an unwarranted burden on nodes implementing lightweight 339 tunneling protocols. The AMT protocol needs to replicate a multicast 340 packet to each gateway tunnel. In this case, the outer IP addresses 341 are different for each tunnel and therefore require a different 342 pseudo header to be built for each UDP replicated encapsulation. 344 The argument concerning redundant processing costs is valid regarding 345 the integrity of a tunneled packet. In some architectures (e.g. PC- 346 based routers), other mechanisms may also significantly reduce 347 checksum processing costs: There are implementations that have 348 optimised checksum processing algorithms, including the use of 349 checksum-offloading. This processing is readily available for IPv4 350 packets at high line rates. Such processing may be anticipated for 351 IPv6 endpoints, allowing receivers to reject corrupted packets 352 without further processing. However, there are certain classes of 353 tunnel end-points where this off-loading is not available and 354 unlikely to become available in the near future. 356 1.3.3. Need to inspect the entire packet 358 The currently-deployed hardware in many routers uses a fast-path 359 processing that only provides the first n bytes of a packet to the 360 forwarding engine, where typically n <= 128. This prevents fast 361 processing of a transport checksum over an entire (large) packet. 362 Hence the currently defined IPv6 UDP checksum is poorly suited to use 363 within a router that is unable to access the entire packet and does 364 not provide checksum-offloading. Thus enabling checksum calculation 365 over the complete packet can impact router design, performance 366 improvement, energy consumption and/or cost. 368 1.3.4. Interactions with middleboxes 370 In IPv4, UDP-encapsulation may be desirable for NAT traversal, since 371 UDP support is commonly provided. It is also necessary due to the 372 almost ubiquitous deployment of IPv4 NATs. There has also been 373 discussion of NAT for IPv6, although not for the same reason as in 374 IPv4. If IPv6 NAT becomes a reality they hopefully do not present 375 the same protocol issues as for IPv4. If NAT is defined for IPv6, it 376 should take UDP zero checksum into consideration. 378 The requirements for IPv6 firewall traversal are likely be to be 379 similar to those for IPv4. In addition, it can be reasonably 380 expected that a firewall conforming to RFC 2460 will not regard UDP 381 datagrams with a zero checksum as valid packets. If an zero-checksum 382 for UDP were to be allowed for IPv6, this would need firewalls to be 383 updated before full utility of the change is available. 385 It can be expected that UDP with zero-checksum will initially not 386 have the same middlebox traversal characteristics as regular UDP. 387 However, if standardized we can expect an improvement over time of 388 the traversal capabilities. We also note that deployment of IPv6- 389 capable middleboxes is still in its initial phases. Thus, it might 390 be that the number of non-updated boxes quickly become a very small 391 percentage of the deployed middleboxes. 393 1.3.5. Support for load balancing 395 The UDP port number fields have been used as a basis to design load- 396 balancing solutions for IPv4. This approach has also been leveraged 397 for IPv6. An alternate method would be to utilise the IPv6 Flow 398 Label as basis for entropy for the load balancing. This would have 399 the desirable effect of releasing IPv6 load-balancing devices from 400 the need to assume semantics for the use of the transport port field 401 and also works for all type of transport protocols. This use of the 402 flow-label is consistent with the intended use, although further 403 clarity may be needed to ensure the field can be consistently used 404 for this purpose, (e.g. Equal-Cost Multi-Path routing, ECMP [ECMP]). 406 Router vendors could be encouraged to start using the IPv6 Flow Label 407 as a part of the flow hash, providing support for ECMP without 408 requiring use of UDP. However, the method for populating the outer 409 IPv6 header with a value for the flow label is not trivial: If the 410 inner packet uses IPv6, then the flow label value could be copied to 411 the outer packet header. However, many current end-points set the 412 flow label to a zero value (thus no entropy). The ingress of a 413 tunnel seeking to provide good entropy in the flow label field would 414 therefore need to create a random flow label value and keep 415 corresponding state, so that all packets that were associated with a 416 flow would be consistently given the same flow label. Although 417 possible, this complexity may not be desirable in a tunnel ingress. 419 The end-to-end use of flow labels for load balancing is a long-term 420 solution. Even if the usage of the flow label is clarified, there 421 would be a transition time before a significant proportion of end- 422 points start to assign a good quality flow label to the flows that 423 they originate, with continued use of load balancing using the 424 transport header fields until any widespread deployment is finally 425 achieved. 427 2. Standards-Track Transports 429 The IETF has defined a set of transport protocols that may be 430 applicable for tunnels with IPv6. There are also a set of network 431 layer encapsulation tunnels such as IP-in-IP and GRE. These already 432 standardized solutions are discussed here prior to the issues, as 433 background for the issue description and some comparison of where the 434 issue may already occur. 436 2.1. UDP with Standard Checksum 438 UDP [RFC0768] with standard checksum behaviour is defined in RFC 2460 439 has already been discussed. UDP usage guidelines are provided in 441 [RFC5405]. 443 2.2. UDP-Lite 445 UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as 446 a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and 447 unicast usage guidelines in [RFC5405]. There is at least one open 448 source implementation as a part of the Linux kernel since version 449 2.6.20. 451 UDP-Lite provides a checksum with optional partial coverage. When 452 using this option, a datagram is divided into a sensitive part 453 (covered by the checksum) and an insensitive part (not covered by the 454 checksum). When the checksum covers the entire packet, UDP-Lite is 455 fully equivalent with UDP. Errors/corruption in the insensitive part 456 will not cause the datagram to be discarded by the transport layer at 457 the receiving endpoint. A minor side-effect of using UDP-Lite is 458 that this was specified for damage-tolerant payloads, and some link- 459 layers may employ different link encapsulations when forwarding UDP- 460 Lite segments (e.g. radio access bearers). Most link-layers will 461 cover the insensitive part with the same strong layer 2 frame CRC 462 that covers the sensitive part. 464 2.2.1. Using UDP-Lite as a Tunnel Encapsulation 466 Tunnel encapsulations can use UDP-Lite (e.g. Control And 467 Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- 468 Lite provides a transport-layer checksum, including an IP pseudo 469 header checksum, in IPv6, without the need for a router/middelbox to 470 traverse the entire packet payload. This provides most of the 471 delivery verifications and still keep the complexity of the 472 checksumming operation low. UDP-Lite may set the length of checksum 473 coverage on a per packet basis. This feature could be used if a 474 tunnel protocol is designed to only verify delivery of the tunneled 475 payload and uses full checksumming for control information. 477 There is currently poor support for middlebox traversal using UDP- 478 Lite, because UDP-Lite uses a different IPv6 network-layer Next 479 Header value to that of UDP, and few middleboxes are able to 480 interpret UDP-Lite and take appropriate actions when forwarding the 481 packet. This makes UDP-Lite less suited to protocols needing general 482 Internet support, until such time that UDP-Lite has achieved better 483 support in middleboxes and end-points. 485 2.3. General Tunnel Encapsulations 487 The IETF has defined a set of tunneling protocols or network layer 488 encapsulations, like IP-in-IP and GRE. These either do not include a 489 checksum or use a checksum that is optional, since tunnel 490 encapsulations are typically layered directly over the Internet layer 491 (identified by the upper layer type in the IPv6 Next Header field) 492 and are also not used as endpoint transport protocols. There is 493 little chance of confusing a tunnel-encapsulated packet with other 494 application data that could result in corruption of application state 495 or data. 497 From the end-to-end perspective, the principal difference is that the 498 network-layer Next Header field identifies a separate transport, 499 which reduces the probability that corruption could result in the 500 packet being delivered to the wrong endpoint or application. 501 Specifically, packets are only delivered to protocol modules that 502 process a specific next header value. The next header field 503 therefore provides a first-level check of correct demultiplexing. In 504 contrast, the UDP port space is shared by many diverse applications 505 and therefore UDP demultiplexing relies solely on the port numbers. 507 3. Issues Requiring Consideration 509 This section evaluates issues around the proposal to update IPv6 510 [RFC2460], to provide the option of using a UDP transport checksum 511 set to zero. Some of the identified issues are shared with other 512 protocols already in use. 514 The decision by IPv6 to omit an integrity check at the network level 515 has meant that the transport check was overloaded with many 516 functions, including validating: 518 o the endpoint address was not corrupted within a router - i.e. A 519 packet was intended to be received by this destination and a wrong 520 header has not been spliced to a different payload; 522 o that extension header processing is correctly delimited - i.e. 523 The start of data has not been corrupted. In this case, reception 524 of a valid next header value provides some protection; 526 o reassembly processing, when used; 528 o the length of the payload; 530 o the port values - i.e. The correct application receives the 531 payload (applications should also check the expected use of source 532 ports/addresses); 534 o the payload integrity. 536 In IPv4, the first four checks are performed using the IPv4 header 537 checksum. 539 In IPv6, these checks occur within the endpoint stack using the UDP 540 checksum information. An IPv6 node also relies on the header 541 information to determine whether to send an ICMPv6 error message 542 [RFC4443] and to determine the node to which this is sent. Corrupted 543 information may lead to misdelivery to an unintended application 544 socket on an unexpected host. 546 3.1. Effect of packet modification in the network 548 IP packets may be corrupted as they traverse an Internet path. 549 Evidence has been presented [Sigcomm2000] to show that this was once 550 an issue with IPv4 routers, and occasional corruption could result 551 from bad internal router processing in routers or hosts. These 552 errors are not detected by the strong frame checksums employed at the 553 link-layer [RFC3819]. There is no current evidence that such cases 554 are rare in the modern Internet, nor that they may not be applicable 555 to IPv6. It therefore seems prudent not to relax this constraint. 556 The emergence of low-end IPv6 routers and the proposed use of NAT 557 with IPv6 further motivate the need to protect from this type of 558 error. 560 Corruption in the network may result in: 562 o A datagram being mis-delivered to the wrong host/router or the 563 wrong transport entity within an endpoint. Such a datagram needs 564 to be discarded; 566 o A datagram payload being corrupted, but still delivered to the 567 intended host/router transport entity. Such a datagram needs to 568 be either discarded or correctly processed by an application that 569 provides its own integrity checks; 571 o A datagram payload being truncated by corruption of the length 572 field. Such a datagram needs to be discarded. 574 When a checksum is used, this significantly reduces the impact of 575 errors, reducing the probability of undetected corruption of state 576 (and data) on both the host stack and the applications using the 577 transport service. 579 The following sections examine the impact of modifying each of these 580 header fields. 582 3.1.1. Corruption of the destination IP address 584 An IP endpoint destination address could be modified in the network 585 (e.g. corrupted by an error). This is not a concern for IPv4, 586 because the IP header checksum will result in this packet being 587 discarded by the receiving IP stack. Such modification in the 588 network can not be detected at the network layer when using IPv6. 590 There are two possible outcomes: 592 o Delivery to a destination address that is not in use (the packet 593 will not be delivered, but could result in an error report); 595 o Delivery to a different destination address. This modification 596 will normally be detected by the transport checksum, resulting in 597 silent discard. Without this checksum, the packet would be passed 598 to the endpoint port demultiplexing function. If an application 599 is bound to the associated ports, the packet payload will be 600 passed to the application (see the subsequent section on port 601 processing). 603 3.1.2. Corruption of the source IP address 605 This section examines what happens when the source address is 606 corrupted in transit. This is not a concern in IPv4, because the IP 607 header checksum will normally result in this packet being discarded 608 by the receiving IP stack. 610 Corruption of an IPv6 source address does not result in the IP packet 611 being delivered to a different endpoint protocol or destination 612 address. If only the source address is corrupted, the datagram will 613 likely be processed in the intended context, although with erroneous 614 origin information. The result will depend on the application or 615 protocol that processes the packet. Some examples are: 617 o An application that requires a per-established context may 618 disregard the datagram as invalid, or could map this to another 619 context (if a context for the modified source address was already 620 activated). 622 o A stateless application will process the datagram outside of any 623 context, a simple example is the ECHO server, which will respond 624 with a datagram directed to the modified source address. This 625 would create unwanted additional processing load, and generate 626 traffic to the modified endpoint address. 628 o Some datagram applications build state using the information from 629 packet headers. A previously unused source address would result 630 in receiver processing and the creation of unnecessary transport- 631 layer state at the receiver. For example, Real Time Protocol 632 (RTP) [RFC3550] sessions commonly employ a source independent 633 receiver port. State is created for each received flow. 634 Reception of a datagram with a corrupted source address will 635 therefore result in accumulation of unnecessary state in the RTP 636 state machine, including collision detection and response (since 637 the same synchronization source, SSRC, value will appear to arrive 638 from multiple source IP addresses). 640 In general, the effect of corrupting the source address will depend 641 upon the protocol that processes the packet and its robustness to 642 this error. For the case where the packet is received by a tunnel 643 endpoint, the tunnel application is expected to correctly handle a 644 corrupted source address. 646 The impact of source address modification is more difficult to 647 quantify when the receiving application is not that originally 648 intended and several fields have been modified in transit. 650 3.1.3. Corruption of Port Information 652 This section describes what happens if one or both of the UDP port 653 values are corrupted in transit. This can also happen with IPv4 in 654 the zero checksum case, but not when UDP checksums are enabled or 655 with UDP-Lite. If the ports carried in the transport header of an 656 IPv6 packet were corrupted in transit, packets may be delivered to 657 the wrong process (on the intended machine) and/or responses or 658 errors sent to the wrong application process (on the intended 659 machine). 661 3.1.4. Delivery to an unexpected port 663 If one combines the corruption effects, such as destination address 664 and ports, there is a number of potential outcomes when traffic 665 arrives at an unexpected port. This section discusses these 666 possibilities and their outcomes for a packet that does not use the 667 UDP checksum validation: 669 o Delivery to a port that is not in use. The packet is discarded, 670 but could generate an ICMPv6 message (e.g. port unreachable). 672 o It could be delivered to a different node that implements the same 673 application, where the packet may be accepted, generating side- 674 effects or accumulated state. 676 o It could be delivered to an application that does not implement 677 the tunnel protocol, where the packet may be incorrectly parsed, 678 and may be misinterpreted, generating side-effects or accumulated 679 state. 681 The probability of each outcome depends on the statistical 682 probability that the address or the port information for the source 683 or destination becomes corrupt in the datagram such that they match 684 those of an existing flow or server port. Unfortunately, such a 685 match may be more likely for UDP than for connection-oriented 686 transports, because: 688 1. There is no handshake prior to communication and no sequence 689 numbers (as in TCP, DCCP, or SCTP). Together, this makes it hard 690 to verify that an application is given only the data associated 691 with a transport session. 693 2. Applications writers often bind to wild-card values in endpoint 694 identifiers and do not always validate correctness of datagrams 695 they receive (guidance on this topic is provided in [RFC5405]). 697 While these rules could, in principle, be revised to declare naive 698 applications as "Historic". This remedy is not realistic: the 699 transport owes it to the stack to do its best to reject bogus 700 datagrams. 702 If checksum coverage is suppressed, the application therefore needs 703 to provide a method to detect and discard the unwanted data. A 704 tunnel protocol would need to perform its own integrity checks on any 705 control information if transported in UDP with zero-checksum. If the 706 tunnel payload is another IP packet, the packets requiring checksums 707 can be assumed to have their own checksums provided that the rate of 708 corrupted packets is not significantly larger due to the tunnel 709 encapsulation. If a tunnel transports other inner payloads that do 710 not use IP, the assumptions of corruption detection for that 711 particular protocol must be fulfilled, this may require an additional 712 checksum/CRC and/or integrity protection of the payload and tunnel 713 headers. 715 A protocol using UDP zero-checksum can never assume that it is the 716 only protocol using a zero checksum. Therefore, it needs to 717 gracefully handle misdelivery. It must be robust to reception of 718 malformed packets received on a listening port and expect that these 719 packets may contain corrupted data or data associated with a 720 completely different protocol. 722 3.1.5. Corruption of Fragmentation Information 724 The fragmentation information in IPv6 employs a 32-bit identity 725 field, compared to only a 16-bit filed in IPv4, a 13-bit fragment 726 offset and a 1-bit flag, indicating if there are more fragments. 727 Corruption of any of these field may result in one of two outcomes: 729 Reassembly failure: An error in the "More Fragments" field for the 730 last fragment will for example result in the packet never being 731 considered complete and will eventually be timed out and 732 discarded. A corruption in the ID field will result in the 733 fragment not being delivered to the intended context thus leaving 734 the rest incomplete, unless that packet has been duplicated prior 735 to corruption. The incomplete packet will eventually be timed out 736 and discarded. 738 Erroneous reassembly: The re-assemblied packet did not match the 739 original packet. This can occur when the ID field of a fragment 740 is corrupted, resulting in a fragment becoming associated with 741 another packet and taking the place of another fragment. 742 Corruption in the offset information can cause the fragment to be 743 misaligned in the reassembly buffer, resulting in incorrect 744 reassembly. Corruption can cause the packet to become shorter or 745 longer, however completion of reassembly is much less probable, 746 since this would requires consistent corruption of the IPv6 747 headers payload length field and the offset field. The 748 possibility of mis-assembly requires the reassembling stack to 749 provide strong checks that detect overlap or missing data, note 750 however that this is not guaranteed and has recently been 751 clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722]. 753 The erroneous reassembly of packets is a general concern and such 754 packets should be discarded instead of being passed to higher layer 755 processes. The primary detector of packet length changes is the IP 756 payload length field, with a secondary check by the transport 757 checksum. The Upper-Layer Packet length field included in the pseudo 758 header assists in verifying correct reassembly, since the Internet 759 checksum has a low probability of detecting insertion of data or 760 overlap errors (due to misplacement of data). The checksum is also 761 incapable of detecting insertion or removal of all zero-data that 762 occurs in a multiple of a 16-bit chunk. 764 The most significant risk of corruption results following mis- 765 association of a fragment with a different packet. This risk can be 766 significant, since the size of fragments is often the same (e.g. 767 fragments resulting when the path MTU results in fragmentation of a 768 larger packet, common when addition of a tunnel encapsulation header 769 expands the size of a packet). Detection of this type of error 770 requires a checksum or other integrity check of the headers and the 771 payload. Such protection is anyway desirable for tunnel 772 encapsulations using IPv4, since the small fragmentation ID can 773 easily result in wrap-around [RFC4963], this is especially the case 774 for tunnels that perform flow aggregation [I-D.ietf-intarea-tunnels]. 776 Tunnel fragmentation behavior matters. There can be outer or inner 777 fragmentation "Tunnels in the Internet Architecture" 778 [I-D.ietf-intarea-tunnels]. If there is inner fragmentation by the 779 tunnel, the outer headers will never be fragmented and thus a zero- 780 checksum in the outer header will not affect the reassembly process. 781 When a tunnel performs outer header fragmentation, the tunnel egress 782 needs to perform reassembly of the outer fragments into an inner 783 packet. The inner packet is either a complete packet or a fragment. 784 If it is a fragment, the destination endpoint of the fragment will 785 perform reassembly of the received fragments. The complete packet or 786 the reassembled fragments will then be processed according to the 787 packet next header field. The receiver may only detect reassembly 788 anomalies when it uses a protocol with a checksum. The larger the 789 number of reassembly processes to which a packet has been subjected, 790 the greater the probability of an error. 792 o An IP-in-IP tunnel that performs inner fragmentation has similar 793 properties to a UDP tunnel with a zero-checksum that also performs 794 inner fragmentation. 796 o An IP-in-IP tunnel that performs outer fragmentation has similar 797 properties to a UDP tunnel with a zero checksum that performs 798 outer fragmentation. 800 o A tunnel that performs outer fragmentation can result in a higher 801 level of corruption due to both inner and outer fragmentation, 802 enabling more chances for reassembly errors to occur. 804 o Recursive tunneling can result in fragmentation at more than one 805 header level, even for inner fragmentation unless it goes to the 806 inner most IP header. 808 o Unless there is verification at each reassembly the probability 809 for undetected error will increase with the number of times 810 fragmentation is recursively applied. Making IP-in-IP and UDP 811 with zero checksum equal subject to this effect. 813 In conclusion fragmentation of packets with a zero-checksum does not 814 worsen the situation compared to some other commonly used tunnel 815 encapsulations. However, caution is needed for recursive tunneling 816 without any additional verification at the different tunnel layers. 818 3.2. Validating the network path 820 IP transports designed for use in the general Internet should not 821 assume specific path characteristics. Network protocols may reroute 822 packets that change the set of routers and middleboxes along a path. 823 Therefore transports such as TCP, SCTP and DCCP have been designed to 824 negotiate protocol parameters, adapt to different network path 825 characteristics, and receive feedback to verify that the current path 826 is suited to the intended application. Applications using UDP and 827 UDP-Lite need to provide their own mechanisms to confirm the validity 828 of the current network path. 830 The zero-checksum in UDP is explicitly disallowed in RFC2460. Thus 831 it may be expected that any device on the path that has a reason to 832 look beyond the IP header will consider such a packet as erroneous or 833 illegal and may likely discard it, unless the device is updated to 834 support a new behavior. A pair of end-points intending to use a new 835 behavior will therefore not only need to ensure support at each end- 836 point, but also that the path between them will deliver packets with 837 the new behavior. This may require negotiation or an explicit 838 mandate to use the new behavior by all nodes intended to use a new 839 protocol. 841 Support along the path between end points may be guaranteed in 842 limited deployments by appropriate configuration. In general, it can 843 be expected to take time for deployment of any updated behaviour to 844 become ubiquitous. A sender will need to probe the path to verify 845 the expected behavior. Path characteristics may change, and usage 846 therefore should be robust and able to detect a failure of the path 847 under normal usage and re-negotiate. This will require periodic 848 validation of the path, adding complexity to any solution using the 849 new behavior. 851 3.3. Applicability of method 853 The expectation of the present proposal defined in 854 [I-D.ietf-6man-udpchecksums] is that this change would only apply to 855 IPv6 router nodes that implement specific protocols that permit 856 omission of UDP checksums. However, the distinction between a router 857 and a host is not always clear, especially at the transport level. 858 Systems (such as unix-based operating systems) routinely provide both 859 functions. There is also no way to identify the role of a receiver 860 from a received packet. 862 Any new method would therefore need a specific applicability 863 statement indicating when the mechanism can (and can not) be used. 864 Enabling this, and ensuring correct interactions with the stack, 865 implies much more than simply disabling the checksum algorithm for 866 specific packets at the transport interface. 868 The IETF should carefully consider constraints on sanctioning the use 869 of any new transport mode. If this is specified and widely 870 available, it may be expected to be used by applications that are 871 perceived to gain benefit. Any solution that uses an end-to-end 872 transport protocol, rather than an IP-in-IP encapsulation, needs to 873 minimise the possibility that end-hosts could confuse a corrupted or 874 wrongly delivered packet with that of data addressed to an 875 application running on their endpoint unless they accept that 876 behavior. 878 3.4. Impact on non-supporting devices or applications 880 It is important to consider what potential impact the zero-checksum 881 behavior may have on end-points, devices or applications that are not 882 modified to support the new behavior or by default or preference, use 883 the regular behavior. These applications must not be significantly 884 impacted by the changes. 886 To illustrate a potential issue, consider the implications of a node 887 that were to enable use of a zero-checksum at the interface level: 888 This would result in all applications that listen to a UDP socket 889 receiving datagram where the checksum was not verified. This could 890 have a significant impact on an application that was not designed 891 with the additional robustness needed to handle received packets with 892 corruption, creating state or destroying existing state in the 893 application. 895 In contrast, the use of a zero-checksum could be enabled only for 896 individual ports using an explicit request by the application. In 897 this case, applications using other ports would maintain the current 898 IPv6 behavior, discarding incoming UDP datagrams with a zero- 899 checksum. These other applications would not be effected by this 900 changed behavior. An application that allows the changed behavior 901 should be aware of the risk for corruption and the increased level of 902 misdirected traffic, and can be designed robustly to handle this 903 risk. 905 4. Evaluation of proposal to update RFC 2460 to support zero checksum 907 This section evaluates the proposal to update IPv6 [RFC2460], to 908 provide the option that some nodes may suppress generation and 909 checking of the UDP transport checksum. It also compares the 910 proposal with other alternatives. 912 4.1. Alternatives to the Standard Checksum 914 There are several alternatives to the normal method for calculating 915 the UDP Checksum that do not require a tunnel endpoint to inspect the 916 entire packet when computing a checksum. These include (in 917 decreasing order of complexity): 919 o Delta computation of the checksum from an encapsulated checksum 920 field. Since the checksum is a cumulative sum [RFC1624], an 921 encapsulating header checksum can be derived from the new pseudo 922 header, the inner checksum and the sum of the other network-layer 923 fields not included in the pseudo header of the encapsulated 924 packet, in a manner resembling incremental checksum update 925 [RFC1141]. This would not require access to the whole packet, but 926 does require fields to be collected across the header, and 927 arithmetic operations on each packet. The method would only work 928 for packets that contain a 2's complement transport checksum (i.e. 929 it would not be appropriate for SCTP or when IP fragmentation is 930 used). 932 o UDP-Lite with the checksum coverage set to only the header portion 933 of a packet. This requires a pseudo header checksum calculation 934 only on the encapsulating packet header. The computed checksum 935 value may be cached (before adding the Length field) for each 936 flow/destination and subsequently combined with the Length of each 937 packet to minimise per-packet processing. This value is combined 938 with the UDP payload length for the pseudo header, however this 939 length is expected to be known when performing packet forwarding. 941 o The proposed UDP Tunnel Transport, UDPTT [UDPTT] suggested a 942 method where UDP would be modified to derive the checksum only 943 from the encapsulating packet protocol header. This value does 944 not change between packets in a single flow. The value may be 945 cached per flow/destination to minimise per-packet processing. 947 o There has been a proposal to simply ignore the UDP checksum value 948 on reception at the tunnel egress, allowing a tunnel ingress to 949 insert any value correct or false. For tunnel usage, a non 950 standard checksum value may be used, forcing an RFC 2460 receiver 951 to drop the packet. The main downside is that it would be 952 impossible to identify a UDP packet (in the network or an 953 endpoint) that is treated in this way compared to a packet that 954 has actually been corrupted. 956 o A method has been proposed that uses a new (to be defined) IPv6 957 Destination Options Header to provide an end-to-end validation 958 check at the network layer. This would allow an endpoint to 959 verify delivery to an appropriate end point, but would also 960 require IPv6 nodes to correctly handle the additional header, and 961 would require changes to middlebox behavior (e.g. when used with a 962 NAT that always adjusts the checksum value). 964 o UDP modified to disable checksum processing 965 [I-D.ietf-6man-udpchecksums]. This requires no checksum 966 calculation, but would require constraints on appropriate usage 967 and updates to end-points and middleboxes. 969 o IP-in-IP tunneling. As this method completely dispenses with a 970 transport protocol in the outer-layer it has reduced overhead and 971 complexity, but also reduced functionality. There is no outer 972 checksum over the packet and also no ports to perform 973 demultiplexing between different tunnel types. This reduces the 974 information available upon which a load balancer may act. 976 These options are compared and discussed further in the following 977 sections. 979 4.2. Comparison 981 This section compares the above listed methods to support datagram 982 tunneling. It includes proposals for updating the behaviour of UDP. 984 4.2.1. Middlebox Traversal 986 Regular UDP with a standard checksum or the delta encoded 987 optimization for creating correct checksums have the best 988 possibilities for successful traversal of a middlebox. No new 989 support is required. 991 A method that ignores the UDP checksum on reception is expected to 992 have a good probability of traversal, because most middleboxes 993 perform an incremental checksum update. UDPTT may also traverse a 994 middlebox with this behaviour. However, a middlebox on the path that 995 attempts to verify a standard checksum will not forward packets using 996 either of these methods, preventing traversal. The methods that 997 ignores the checksum has an additional downside in that middlebox 998 traversal can not be improved, because there is no way to identify 999 which packets use the modified checksum behaviour. 1001 IP-in-IP or GRE tunnels offer good traversal of middleboxes that have 1002 not been designed for security, e.g. firewalls. However, firewalls 1003 may be expected to be configured to block general tunnels as they 1004 present a large attack surface. 1006 A new IPv6 Destination Options header will suffer traversal issues 1007 with middleboxes, especially Firewalls and NATs, and will likely 1008 require them to be updated before the extension header is passed. 1010 Packets using UDP with a zero checksum will not be passed by any 1011 middlebox that validates the checksum using RFC 2460 or updates the 1012 checksum field, such as NAT or firewalls. This would require an 1013 update to correctly handle the zero checksum packets. 1015 UDP-Lite will require an update of almost all type of middleboxes, 1016 because it requires support for a separate network-layer protocol 1017 number. Once enabled, the method to support incremental checksum 1018 update would be identical to that for UDP, but different for checksum 1019 validation. 1021 4.2.2. Load Balancing 1023 The usefulness of solutions for load balancers depends on the 1024 difference in entropy in the headers for different flows that can be 1025 included in a hash function. All the proposals that use the UDP 1026 protocol number have equal behavior. UDP-Lite has the potential for 1027 equally good behavior as for UDP. However, UDP-Lite is currently 1028 likely to not be supported by deployed hashing mechanisms, which may 1029 cause a load balancer to not use the transport header in the computed 1030 hash. A load balancer that only uses the IP header will have low 1031 entropy, but could be improved by including the IPv6 the flow label, 1032 providing that the tunnel ingress ensures that different flow labels 1033 are assigned to different flows. However, a transition to the common 1034 use of good quality flow labels is likely to take time to deploy. 1036 4.2.3. Ingress and Egress Performance Implications 1038 IP-in-IP tunnels are often considered efficient, because they 1039 introduce very little processing and low data overhead. The other 1040 proposals introduce a UDP-like header incurring associated data 1041 overhead. Processing is minimised for the zero-checksum method, 1042 ignoring the checksum on reception, and only slightly higher for 1043 UDPTT, the extension header and UDP-Lite. The delta-calculation 1044 scheme operates on a few more fields, but also introduces serious 1045 failure modes that can result in a need to calculate a checksum over 1046 the complete packet. Regular UDP is clearly the most costly to 1047 process, always requiring checksum calculation over the entire 1048 packet. 1050 It is important to note that the zero-checksum method, ignoring 1051 checksum on reception, the Option Header, UDPTT and UDP-Lite will 1052 likely incur additional complexities in the application to 1053 incorporate a negotiation and validation mechanism. 1055 4.2.4. Deployability 1057 The major factors influencing deployability of these solutions are a 1058 need to update both end-points, a need for negotiation and the need 1059 to update middleboxes. These are summarised below: 1061 o The solution with the best deployability is regular UDP. This 1062 requires no changes and has good middlebox traversal 1063 characteristics. 1065 o The next easiest to deploy is the delta checksum solution. This 1066 does not modify the protocol on the wire and only needs changes in 1067 tunnel ingress. 1069 o IP-in-IP tunnels should not require changes to the end-points, but 1070 raise issues when traversing firewalls and other security-type 1071 devices, which are expected to require updates. 1073 o Ignoring the checksum on reception will require changes at both 1074 end-points. The never ceasing risk of path failure requires 1075 additional checks to ensure this solution is robust and will 1076 require changes or additions to the tunneling control protocol to 1077 negotiate support and validate the path. 1079 o The remaining solutions offer similar deployability. UDP-Lite 1080 requires support at both end-points and in middleboxes. UDPTT and 1081 Zero-checksum with or without an Extension header require support 1082 at both end-points and in middleboxes. UDP-Lite, UDPTT, and Zero- 1083 checksum and Extension header may additionally require changes or 1084 additions to the tunneling control protocol to negotiate support 1085 and path validation. 1087 4.2.5. Corruption Detection Strength 1089 The standard UDP checksum and the delta checksum can both provide 1090 some verification at the tunnel egress. This can significantly 1091 reduce the probability that a corrupted inner packet is forwarded. 1092 UDP-Lite, UDPTT and the extension header all provide some 1093 verification against corruption, but do not verify the inner packet. 1094 They only provide a strong indication that the delivered packet was 1095 intended for the tunnel egress and was correctly delimited. The 1096 Zero-checksum, ignoring the checksum on reception and IP-and-IP 1097 encapsulation provide no verification that a received packet was 1098 intended to be processed by a specific tunnel egress or that the 1099 inner packet was correct. 1101 4.2.6. Comparison Summary 1103 The comparisons above may be summarised as "there is no silver bullet 1104 that will slay all the issues". One has to select which down side(s) 1105 can best be lived with. Focusing on the existing solutions, this can 1106 be summarized as: 1108 Regular UDP: Good middlebox traversal and load balancing and 1109 multiplexing, requiring a checksum in the outer headers covering 1110 the whole packet. 1112 IP in IP: A low complexity encapsulation, with limited middlebox 1113 traversal, no multiplexing support, and currently poor load 1114 balancing support that could improve over time. 1116 UDP-Lite: A medium complexity encapsulation, with good multiplexing 1117 support, limited middlebox traversal, but possible to improve over 1118 time, currently poor load balancing support that could improve 1119 over time, in most cases requiring application level negotiation 1120 and validation. 1122 The delta-checksum is an optimization in the processing of UDP, as 1123 such it exhibits some of the drawbacks of using regular UDP. 1125 The remaining proposals may be described in similar terms: 1127 Zero-Checksum: A low complexity encapsulation, with good 1128 multiplexing support, limited middlebox traversal that could 1129 improve over time, good load balancing support, in most cases 1130 requiring application level negotiation and validation. 1132 UDPTT: A medium complexity encapsulation, with good multiplexing 1133 support, limited middlebox traversal, but possible to improve over 1134 time, good load balancing support, in most cases requiring 1135 application level negotiation and validation. 1137 IPv6 Destination Option IP in IP tunneling: A medium complexity, 1138 with no multiplexing support, limited middlebox traversal, 1139 currently poor load balancing support that could improve over 1140 time, in most cases requiring application level negotiation and 1141 validation. 1143 IPv6 Destination Option combined with UDP Zero-checksuming: A medium 1144 complexity encapsulation, with good multiplexing support, limited 1145 load balancing support that could improve over time, in most cases 1146 requiring application level negotiation and validation. 1148 Ignore the checksum on reception: A low complexity encapsulation, 1149 with good multiplexing support, medium middlebox traversal that 1150 never can improve, good load balancing support, in most cases 1151 requiring application level negotiation and validation. 1153 There is no clear single optimum solution. If the most important 1154 need is to traverse middleboxes, then the best choice is to stay with 1155 regular UDP and consider the optimizations that may be required to 1156 perform the checksumming. If one can live with limited middlebox 1157 traversal, low complexity is necessary and one does not require load 1158 balancing, then IP-in-IP tunneling is the simplest. If one wants 1159 strengthened error detection, but with currently limited middlebox 1160 traversal and load-balancing. UDP-Lite is appropriate. UDP Zero- 1161 checksum addresses another set of constraints, low complexity and a 1162 need for load balancing from the current Internet, providing it can 1163 live with currently limited middlebox traversal. 1165 Techniques for load balancing and middlebox traversal do continue to 1166 evolve. Over a long time, developments in load balancing have good 1167 potential to improve. This time horizon is long since it requires 1168 both load balancer and end-point updates to get full benefit. The 1169 challenges of middlebox traversal are also expected to change with 1170 time, as device capabilities evolve. Middleboxes are very prolific 1171 with a larger proportion of end-user ownership, and therefore may be 1172 expected to take long time cycles to evolve. One potential advantage 1173 is that the deployment of IPv6 capable middleboxes are still in its 1174 initial phase and the quicker zero-checksum becomes standardized the 1175 fewer boxes will be non-compliant. 1177 Thus, the question of whether to allow UDP with a zero-checksum for 1178 IPv6 under reasonable constraints, is therefore best viewed as a 1179 trade-off between a number of more subjective questions: 1181 o Is there sufficient interest in zero-checksum with the given 1182 constraints (summarised below)? 1184 o Are there other avenues of change that will resolve the issue in a 1185 better way and sufficiently quickly ? 1187 o Do we accept the complexity cost of having one more solution in 1188 the future? 1190 The authors do think the answer to the above questions are such that 1191 zero-checksum should be standardized for use by tunnel 1192 encapsulations. 1194 5. Requirements on the specification of transported protocols 1196 5.1. Constraints required on usage of a zero checksum 1198 If a zero checksum approach were to be adopted by the IETF, the 1199 specification should consider adding the following constraints on 1200 usage: 1202 1. IPv6 protocol stack implementations should not by default allow 1203 the new method. The default node receiver behaviour must discard 1204 all IPv6 packets carrying UDP packets with a zero checksum. 1206 2. Implementations must provide a way to signal the set of ports 1207 that will be enabled to receive UDP datagrams with a zero 1208 checksum. An IPv6 node that enables reception of UDP packets 1209 with a zero-checksum, must enable this only for a specific port 1210 or port-range. This may be implemented via a socket API call, or 1211 similar mechanism. 1213 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams with 1214 a zero-checksum. This should remain the case for any datagram 1215 received on a port that does not explicitly enable zero-checksum 1216 processing. A port for which zero-checksum has been enabled must 1217 not log the datagram. 1219 4. A stack may separately identify UDP datagrams that are discarded 1220 with a zero checksum. It should not add these to the standard 1221 log, since the endpoint has not been verified. 1223 5. Tunnels that encapsulate IP may rely on the inner packet 1224 integrity checks provided that the tunnel will not significantly 1225 increase the rate of corruption of the inner IP packet. If a 1226 significantly increased corruption rate can occur, then the 1227 tunnel must provide an additional integrity verification 1228 mechanism. An integrity mechanisms is always recommended at the 1229 tunnel layer to ensure that corruption rates of the inner most 1230 packet are not increased. 1232 6. Tunnels that encapsulate Non-IP packets must have a CRC or other 1233 mechanism for checking packet integrity, unless the Non-IP packet 1234 specifically is designed for transmission over lower layers that 1235 do not provide any packet integrity guarantee. In particular, 1236 the application must be designed so that corruption of this 1237 information does not result in accumulated state or incorrect 1238 processing of a tunneled payload. 1240 7. UDP applications that support use of a zero-checksum, should not 1241 rely upon correct reception of the IP and UDP protocol 1242 information (including the length of the packet) when decoding 1243 and processing the packet payload. In particular, the 1244 application must be designed so that corruption of this 1245 information does not result in accumulated state or incorrect 1246 processing of a tunneled payload. 1248 8. If a method proposes recursive tunnels, it needs to provide 1249 guidance that is appropriate for all use-cases. Restrictions may 1250 be needed to the use of a tunnel encapsulations and the use of 1251 recursive tunnels (e.g. Necessary when the endpoint is not 1252 verified). 1254 9. IPv6 nodes that receive ICMPv6 messages that refer to packets 1255 with a zero UDP checksum must provide appropriate checks 1256 concerning the consistency of the reported packet to verify that 1257 the reported packet actually originated from the node, before 1258 acting upon the information (e.g. validating the address and port 1259 numbers in the ICMPv6 message body). 1261 Deployment of the new method needs to remain restricted to endpoints 1262 that explicitly enable this mode and adopt the above procedures. Any 1263 middlebox that examines or interact with the UDP header over IPv6 1264 should support the new method. 1266 6. Summary 1268 This document examines the role of the transport checksum when used 1269 with IPv6, as defined in RFC2460. 1271 It presents a summary of the trade-offs for evaluating the safety of 1272 updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value 1273 in the checksum field to indicate that no checksum is present. A 1274 decision not to include a UDP checksum in received IPv6 datagrams 1275 could impact a tunnel application that receives these packets. 1276 However, a well-designed tunnel application should include 1277 consistency checks to validate any header information encapsulated 1278 with a packet. In most cases tunnels encapsulating IP packets can 1279 rely on the inner packets own integrity protection. When correctly 1280 implemented, such a tunnel endpoint will not be negatively impacted 1281 by omission of the transport-layer checksum. Recursive tunneling and 1282 fragmentation is a potential issues that can raise corruption rates 1283 significantly, and requires careful consideration. 1285 Other applications at the intended destination node or another IPv6 1286 node can be impacted if they are allowed to receive datagrams without 1287 a transport-layer checksum. It is particularly important that 1288 already deployed applications are not impacted by any change at the 1289 transport layer. If these applications execute on nodes that 1290 implement RFC 2460, they will reject all datagrams with a zero UDP 1291 checksum, thus this is not an issue. For nodes that implement 1292 support for zero-checksum it is important to ensure that only UDP 1293 applications that desire zero-checksum can receive and originate 1294 zero-checksum packets. Thus, the enabling of zero-checksum needs to 1295 be at a port level, not for the entire host or for all use of an 1296 interface. 1298 The implications on firewalls, NATs and other middleboxes need to be 1299 considered. It is not expected that IPv6 NATs handle IPv6 UDP 1300 datagrams in the same way that they handle IPv4 UDP datagrams. This 1301 possibly reduces the need to update the checksum. Firewalls are 1302 intended to be configured, and therefore may need to be explicitly 1303 updated to allow new services or protocols. IPv6 middlebox 1304 deployment is not yet as prolific as it is in IPv4. Thus, relatively 1305 few current middleboxes may actually block IPv6 UDP with a zero 1306 checksum. 1308 In general, UDP-based applications need to employ a mechanism that 1309 allows a large percentage of the corrupted packets to be removed 1310 before they reach an application, both to protect the applications 1311 data stream and the control plane of higher layer protocols. These 1312 checks are currently performed by the UDP checksum for IPv6, or the 1313 reduced checksum for UDP-Lite when used with IPv6. 1315 The use of UDP with no checksum has merits for some applications, 1316 such as tunnel encapsulation, and is widely used in IPv4. However, 1317 there are dangers for IPv6: There is a bigger risk of corruption and 1318 miss-delivery when using zero-checksum in IPv6 compared to IPv4 due 1319 to the removed IP header checksum. Thus, applications needs to make 1320 a new evaluation of the risks of enabling a zero-checksum. Some 1321 applications will need to re-consider their usage of zero-checksum, 1322 and possibly consider a solution that at least provides the same 1323 delivery protection as for IPv4, for example by utilizing UDP-Lite, 1324 or by enabling the UDP checksum. Tunnel applications using UDP for 1325 encapsulation can in many case use zero-checksum without significant 1326 impact on the corruption rate. In some cases, the use of checksum 1327 off-loading may help alleviate the checksum processing cost. 1329 Recursive tunneling and fragmentation is a difficult issue relating 1330 to tunnels in general. There is an increased risk of an error in the 1331 inner-most packet when fragmentation when several layers of tunneling 1332 and several different reassembly processes are run without any 1333 verification of correctness. This issue requires future thought and 1334 consideration. 1336 The conclusion is that UDP zero checksum in IPv6 should be 1337 standardized, as it satisfies usage requirements that are currently 1338 difficult to address. We do note that a safe deployment of zero- 1339 checksum will need to follow a set of constraints listed in 1340 Section 5.1. 1342 7. Acknowledgements 1344 Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, 1345 others in the TSV directorate. 1347 Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who 1348 contributed comments and ideas via the 6man, behave, lisp and mboned 1349 lists. 1351 8. IANA Considerations 1353 This document does not require any actions by IANA. 1355 9. Security Considerations 1357 Transport checksums provide the first stage of protection for the 1358 stack, although they can not be considered authentication mechanisms. 1359 These checks are also desirable to ensure packet counters correctly 1360 log actual activity, and can be used to detect unusual behaviours. 1362 10. References 1364 10.1. Normative References 1366 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1367 September 1981. 1369 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1370 RFC 793, September 1981. 1372 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1373 "Computing the Internet checksum", RFC 1071, 1374 September 1988. 1376 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1377 (IPv6) Specification", RFC 2460, December 1998. 1379 10.2. Informative References 1381 [ECMP] "Using the IPv6 flow label for equal cost multipath 1382 routing in tunnels (draft-carpenter-flow-ecmp)". 1384 [I-D.ietf-6man-udpchecksums] 1385 Eubanks, M., "UDP Checksums for Tunneled Packets", 1386 draft-ietf-6man-udpchecksums-00 (work in progress), 1387 March 2011. 1389 [I-D.ietf-intarea-tunnels] 1390 Touch, J. and M. Townsley, "Tunnels in the Internet 1391 Architecture", draft-ietf-intarea-tunnels-00 (work in 1392 progress), March 2010. 1394 [I-D.ietf-mboned-auto-multicast] 1395 Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., 1396 Pusateri, T., and T. Morin, "Automatic IP Multicast 1397 Tunneling", draft-ietf-mboned-auto-multicast-11 (work in 1398 progress), July 2011. 1400 [LISP] D. Farinacci et al, "Locator/ID Separation Protocol 1401 (LISP)", March 2009. 1403 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1404 August 1980. 1406 [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the 1407 Internet checksum", RFC 1141, January 1990. 1409 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 1410 Incremental Update", RFC 1624, May 1994. 1412 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1413 Jacobson, "RTP: A Transport Protocol for Real-Time 1414 Applications", STD 64, RFC 3550, July 2003. 1416 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1417 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1418 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1419 RFC 3819, July 2004. 1421 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1422 G. Fairhurst, "The Lightweight User Datagram Protocol 1423 (UDP-Lite)", RFC 3828, July 2004. 1425 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1426 Message Protocol (ICMPv6) for the Internet Protocol 1427 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1429 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1430 Errors at High Data Rates", RFC 4963, July 2007. 1432 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1433 for Application Designers", BCP 145, RFC 5405, 1434 November 2008. 1436 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 1437 Provisioning of Wireless Access Points (CAPWAP) Protocol 1438 Specification", RFC 5415, March 2009. 1440 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1441 RFC 5722, December 2009. 1443 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1444 Algorithm", RFC 6145, April 2011. 1446 [Sigcomm2000] 1447 Jonathan Stone and Craig Partridge , "When the CRC and TCP 1448 Checksum Disagree", 2000. 1450 [UDPTT] G Fairhurst, "The UDP Tunnel Transport mode", Feb 2010. 1452 Appendix A. Document Change History 1454 {RFC EDITOR NOTE: This section must be deleted prior to publication} 1456 Individual Draft 00 This is the first DRAFT of this document - It 1457 contains a compilation of various discussions and contributions 1458 from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, 1459 and behave. This includes contributions from Magnus with text on 1460 RTP, and various updates. 1462 Individual Draft 01 1464 * This version corrects some typos and editorial NiTs and adds 1465 discussion of the need to negotiate and verify operation of a 1466 new mechanism (3.3.4). 1468 Individual Draft 02 1470 * Version -02 corrects some typos and editorial NiTs. 1472 * Added reference to ECMP for tunnels. 1474 * Clarifies the recommendations at the end of the document. 1476 Working Group Draft 00 1478 * Working Group Version -00 corrects some typos and removes much 1479 of rationale for UDPTT. It also adds some discussion of IPv6 1480 extension header. 1482 Working Group Draft 01 1484 * Working Group Version -01 updates the rules and incorporates 1485 off-list feedback. This version is intended for wider review 1486 within the 6man working group. 1488 Working Group Draft 02 1490 * This version is the result of a major rewrite and re-ordering 1491 of the document. 1493 * A new section comparing the results have been added. 1495 * The constraints list has been significantly altered by removing 1496 some and rewording other constraints. 1498 * This contains other significant language updates to clarify the 1499 intent of this draft. 1501 Working Group Draft 03 1503 * Editorial updates 1505 Working Group Draft 04 1507 * Resubmission only updating the AMT and RFC2765 references. 1509 Authors' Addresses 1511 Godred Fairhurst 1512 University of Aberdeen 1513 School of Engineering 1514 Aberdeen, AB24 3UE, 1515 Scotland, UK 1517 Phone: 1518 Email: gorry@erg.abdn.ac.uk 1519 URI: http://www.erg.abdn.ac.uk/users/gorry 1520 Magnus Westerlund 1521 Ericsson 1522 Farogatan 6 1523 Stockholm, SE-164 80 1524 Sweden 1526 Phone: +46 8 719 0000 1527 Fax: 1528 Email: magnus.westerlund@ericsson.com 1529 URI: