idnits 2.17.1 draft-fairhurst-tsvwg-6man-udpzero-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 686 has weird spacing: '... in in ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 22, 2010) is 5142 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'RFC1071' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'RFC1141' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'UDPTT' is defined on line 937, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-09 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 3 errors (**), 0 flaws (~~), 11 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: September 23, 2010 Ericsson Research 6 March 22, 2010 8 IPv6 UDP Checksum Considerations 9 draft-fairhurst-tsvwg-6man-udpzero-02 11 Abstract 13 This document examines the role of the transport checksum when used 14 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 to 17 indicate that no checksum is present. The document describes issues 18 and design principles that need to be considered and provides 19 recommendations. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 23, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 5 64 1.2.1. Motivation for new approaches . . . . . . . . . . . . 5 65 1.2.2. Reducing forwarding cost . . . . . . . . . . . . . . . 6 66 1.2.3. Need to inspect the entire packet . . . . . . . . . . 6 67 1.2.4. Interactions with middleboxes . . . . . . . . . . . . 7 68 1.2.5. Support for load balancing . . . . . . . . . . . . . . 7 69 2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 7 70 2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 8 71 2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 8 73 2.3. IP in IPv6 Tunnel Encapsulations . . . . . . . . . . . . . 9 74 3. Evaluation of proposal to update to RFC 2460 to support 75 zero checksum . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1. Alternatives to the Standard Checksum . . . . . . . . . . 10 77 3.2. Applicability of method . . . . . . . . . . . . . . . . . 11 78 3.3. Effect of packet modification in the network . . . . . . . 11 79 3.3.1. Corruption of the destination IP address . . . . . . . 12 80 3.3.2. Corruption of the source IP address . . . . . . . . . 12 81 3.3.3. Delivery to an unexpected port . . . . . . . . . . . . 13 82 3.3.4. Validating the network path . . . . . . . . . . . . . 14 83 3.4. Comparision . . . . . . . . . . . . . . . . . . . . . . . 15 84 4. Requirements on the specification of transported protocols . . 15 85 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Appendix A. Document Change History . . . . . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 95 1. Introduction 97 The User Datagram Protocol (UDP) transport was defined by RFC768 98 [RFC0768] for IPv4 RFC791 [RFC0791] and is defined in RFC2460 99 [RFC2460] for IPv6 hosts and routers. A UDP transport endpoint may 100 be either a host or a router. The UDP Usage Guidelines [RFC5405] 101 provides overall guidance for application designers, including the 102 use of UDP to support tunneling. These guidelines are applicable to 103 this discussion. 105 This section provides a background to key issues, and introduces the 106 use of UDP as a tunnel transport protocol. 108 Section 2 describes a set of standards-track datagram transport 109 protocols that may be used to support tunnels. 111 Section 3 evaluates proposals to update the UDP transport behaviour 112 to allow for better support of tunnel protocols. It focuses on a 113 proposal to eliminate the checksum for this use-case with IPv6 and 114 assess the trade-offs that would arise. 116 Section 4 reviews the trade offs and provides recommendations. 118 1.1. Background 120 An Internet transport endpoint should concern itself with the 121 following issues: 123 o Protection of the endpoint transport state from unnecessary extra 124 state (i.e. Invalid state from rogue packets). 126 o Protection of the endpoint transport state from corruption of 127 internal state. 129 o Pre-filtering by the endpoint of erroneous data, to protect the 130 transport from unnecessary processing and from corruption that it 131 can not itself reject. 133 o Pre-filter of incorrectly addressed destination packets, before 134 responding to a source address. 136 UDP, as defined in [RFC0768], supports two checksum behaviours when 137 used with IPv4. The normal behaviour is for the sender to calculate 138 a checksum over a block of data that includes a pseudo header and the 139 UDP datagram payload. The UDP header includes a 16-bit one's 140 complement checksum that provides a statistical guarantee that the 141 payload was not corrupted in transit. This also allows a receiver to 142 verify that the endpoint was the intended destination of the 143 datagram, because the pseudo header covers the IP addresses, port 144 numbers, transport payload length, and Next Header/Protocol value 145 corresponding to the UDP transport protocol. The length field 146 verifies that the datagram is not truncated or padded. The checksum 147 therefore protects an application against receiving corrupted payload 148 data in place of, or in addition to, the data that was sent. 149 Although the IPv4 UDP [RFC0768] checksum may be disabled, 150 applications are recommended to enable UDP checksums [RFC5405]. 152 IPv4 UDP checksum control is often a kernel-wide configuration 153 control (e.g. In Linux and BSD), rather than a per socket call. 154 There are Networking Interface Cards (NICs) that automatically 155 calculate TCP/UDP checksums on transmission if a checksum of zero is 156 sent to the NIC, using a method known as checksum offloading. 158 The network-layer fields that are validated by a transport checksum 159 are: 161 o Endpoint IP source address (always included in pseudo header of 162 checksum) 164 o Endpoint IP destination address (always included in pseudo header 165 of checksum) 167 o Upper Layer Payload type (always included in pseudo header of 168 checksum) 170 o IP length of payload (always included in pseudo header of 171 checksum) 173 o Length of the network layer extension headers (i.e. By correct 174 position of checksum bytes) 176 The transport-layer fields that are validated by a transport checksum 177 are: 179 o Transport demultiplexing, i.e. ports (always included in checksum) 181 o Transport payload size (always included in checksum) 183 Transport endpoints also need to verify correctness of reassembly of 184 any fragmented packets (unless the application use of the payload is 185 corruption tolerant as indicated by UDP-Lite's checksum coverage 186 field). For UDP, this is normally provided as a part of the 187 integrity check. Disabling the IPv4 checksum prevents this check. A 188 lack of checksum can lead to issues in a translator or middlebox 189 (e.g. Many IPv4 Network Address Translators, NATs, rely on port 190 numbers to find the mappings, packet fragments do not carry port 191 numbers, so fragments get dropped). RFC2765 [RFC2765] provides some 192 guidance on the processing of fragmented IPv4 UDP datagrams that do 193 not carry a UDP checksum. 195 IPv6 does not provide a network-layer integrity check. The removal 196 of the IPv6 header checksum released routers from a need to update a 197 network-layer checksum on a hop-by-hop basis when they changed the 198 IPv4 Time-To-Live (TTL) or IPv6 Hop Count. The IP header checksum 199 calculation was seen as redundant for most traffic (TCP and UDP with 200 checksums enabled), and people wanted to avoid this extra processing. 201 However, there was concern that the removal of the IP header checksum 202 in IPv6 would lessen the protection of the source/destination IP 203 addresses and result in a significant (a multiplier of ~32,000) 204 increase in the number of times that a UDP packet was accidentally 205 delivered to the wrong destination address and/or apparently sourced 206 from the wrong source address when UDP checksums were set to zero. 207 This would have had implications on the detectability of mis-delivery 208 of a packet to an incorrect endpoint/socket, and the robustness of 209 the Internet infrastructure. The use of the UDP checksum is 210 required[RFC2460] when applications transmit UDP over IPv6. 212 1.2. Use of UDP Tunnels 214 One increasingly popular use of UDP is as a tunneling protocol, where 215 a tunnel endpoint encapsulates the packets of another protocol inside 216 UDP datagrams and transmits them to another tunnel endpoint. Using 217 UDP as a tunneling protocol is attractive when the payload protocol 218 is not supported by middleboxes that may exist along the path, 219 because many middleboxes support transmission using UDP. In this 220 use, the receiving endpoint decapsulates the UDP datagrams and 221 forwards the original packets contained in the payload [RFC5405]. 222 Tunnels establish virtual links that appear to directly connect 223 locations that are distant in the physical Internet topology and can 224 be used to create virtual (private) networks. 226 1.2.1. Motivation for new approaches 228 A number of tunnel protocols are currently being defined (e.g.. 229 Automated Multicast Tunnels, AMT [AMT], and the Locator/Identifier 230 Separation Protocol, LISP [LISP]). These protocols have proposed an 231 update to IPv6 UDP checksum processing. These tunnel protocols could 232 benefit from simpler checksum processing for various reasons: 234 o Reducing forwarding costs, motivated by redundancy present in the 235 encapsulated packet header, since in tunnel encapsulations, 236 payload integrity and length verification may be provided by 237 higher layer tunnel encapsulations (often using the IPv4, UDP, 238 UDP-Lite, or TCP checksums). 240 o Eliminating a need to access the entire packet when forwarding the 241 packet. 243 o Enhancing ability to traverse middleboxes, especially NATs. 245 o A desire to use the port number space to enable load-sharing. 247 1.2.2. Reducing forwarding cost 249 It is a common requirement to terminate a large number of tunnels on 250 a single router/host. Processing costs per tunnel concern both state 251 (memory requirements) and processing costs. 253 Automatic IP Multicast Without Explicit Tunnels, known as AMT [AMT] 254 currently specifies UDP as the transport protocol for tunneled 255 packets carrying tunneled IP multicast packets. The current 256 specification for AMT requires that the UDP checksum in the outer 257 packet header SHOULD be 0 (see Section 6.6). It argues that the 258 computation of an additional checksum, when an inner packet is 259 already adequately protected, is an unwarranted burden on nodes 260 implementing lightweight tunneling protocols. The AMT protocol needs 261 to replicate a multicast packet to each gateway tunnel. In this case 262 the outer IP addresses are different for each tunnel and therefore 263 require a different pseudo header to be built for each UDP replicated 264 encapsulation. 266 The argument concerning redundant processing costs is valid regarding 267 the integrity of a tunneled packet. In some architectures (e.g. PC- 268 based routers), other mechanisms may also significantly reduce 269 checksum processing costs: There are implementations that have 270 optimised checksum processing algorithms, including the use of 271 checksum-offloading. This processing is readily available for IPv4 272 packets at high line rates. Such processing may be anticipated for 273 IPv6 endpoints, allowing them to reject corrupted packets without 274 further processing. Relaxing RFC 2460 to minimise the processing 275 impact for existing hardware is a transition policy decision, which 276 seems undesirable if at the same time it yields a solution that may 277 reduce stability and functionality in future network scenarios. 279 1.2.3. Need to inspect the entire packet 281 The currently-deployed hardware in many routers uses a fast-path 282 processing that only provides the first n bytes of a packet to the 283 forwarding engine, where typically n < 128. This prevents fast 284 processing of a transport checksum over an entire (large) packet. 285 Hence the currently defined IPv6 UDP checksum is poorly suited to use 286 within routers that are unable to access the entire packet and do not 287 provide checksum-offloading. 289 1.2.4. Interactions with middleboxes 291 In IPv4, UDP-encapsulation may be desirable for NAT traversal, since 292 UDP support is commonly provided. 294 IPv6 NAT traversal does not necessarily present the same protocol 295 issues as for IPv4. It is not clear that NATs will work the same way 296 for IPv6. Any change to RFC 2460 is going to require rewriting IPv6 297 (or defining it) NAT behaviour to achieve consistent widescale 298 deployment. 300 The requirements for IPv6 firewall traversal are likely be to be 301 similar to those for IPv4. In addition, it can be reasonably 302 expected that a firewall conforming to RFC 2460 will not regard UDP 303 datagrams with a zero checksum as valid packets, and if such a mode 304 were to be defined for IPv6 these may also need to be updated. 306 Key questions in this space include: 308 o What types of middleboxes does the protocol need to cross 309 (routers, NAT boxes, firewalls, etc.), and how will those 310 middleboxes deal with these packets? 312 o What do IPv6 routers do today with zero-checksum UDP packets? 314 o What other IPv6 middleboxes exist today, and what would they do? 316 1.2.5. Support for load balancing 318 The UDP port number fields have been used as a basis to design load- 319 balancing solutions for IPv4. This approach could also be leveraged 320 for IPv6. However, support for extension headers would increase the 321 complexity of providing standards-compliant solutions for IPv6. 323 An alternate method could utilise the IPv6 Flow Label to perform load 324 balancing. This would release IPv6 load-balancing devices from the 325 need to assume semantics for the use of the transport port field. 326 This use of the flow-label is consistent with the intended use, 327 although further clarity may be needed to ensure the field can be 328 consistently used for this purpose, (e.g. ECMP [ECMP]). Router 329 vendors could be encouraged to start using the IPv6 Flow Label as a 330 part of the flow hash. 332 2. Standards-Track Transports 333 2.1. UDP with Standard Checksum 335 UDP with standard checksum behaviour is defined in RFC 2460, and 336 should be the default choice. Guidelines are provided in [RFC5405]. 338 2.2. UDP-Lite 340 UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as 341 a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and 342 unicast usage guidelines in [RFC5405]. UDP-Lite has been 343 implemented, e.g. as a part of the Linux kernel since version 2.6.20. 345 UDP-Lite provides a checksum with an optional partial coverage. When 346 using this option, a datagram is divided into a sensitive part 347 (covered by the checksum) and an insensitive part (not covered by the 348 checksum). Errors/corruption in the insensitive part will not cause 349 the datagram to be discarded by the transport layer at the receiving 350 host. A minor side-effect of using UDP-Lite is that this was 351 specified for damage-tolerant payloads, and some link-layers may 352 employ different link encapsulations when forwarding UDP-Lite 353 segments (e.g. Over radio access bearers). When the checksum covers 354 the entire packet, which should be the default, UDP-Lite is 355 semantically identical to UDP and is specified for use with IPv4 and 356 IPv6. It uses an IP protocol type (or IPv6 next header) with a value 357 of 136 decimal. This value is different to that used by UDP. 359 2.2.1. Using UDP-Lite as a Tunnel Encapsulation 361 Tunnel encapsulations can use UDP-Lite (e.g. Control And 362 Provisioning of Wireless Access Points, CAPWAP), since UDP-Lite 363 provides a transport-layer checksum, including an IP pseudo header 364 checksum, in IPv6, without the need to traverse the entire packet. 366 In the LISP case, the bytes that would need to be "checksummed" for 367 UDP-Lite would be the set of bytes that are added to the packet by 368 the LISP encapsulating router. When an IPv4/UDP header is per-pended 369 by a LISP router, the LISP ETR needs to calculate the IP header 370 checksum over 20 bytes (the IP header). If an IPv6/UDP-Lite header 371 were per-pended by a LISP router, the ETR would need to calculate an 372 IP header checksum over 48 bytes (the IP pseudo header and the UDP 373 header). This results in an increase in the number of bytes to be 374 the checksummed for IPv6 (48 bytes rather than 20), but this is not 375 thought to be a major processing overhead for a well-optimized 376 implementation where the pre-pended header bytes are already in 377 memory. 379 2.3. IP in IPv6 Tunnel Encapsulations 381 The IETF has defined a set of tunneling protocols. These do not 382 include a checksum, since tunnel encapsulations are typically layered 383 directly over the Internet layer (identified by the upper layer type 384 field) and are also not used as endpoint transport protocols. That 385 is, there is little chance of confusing a tunnel-encapsulated packet 386 with other application data that would result in corruption of 387 application state or data. 389 From the end-to-end perspective, the principal difference is that the 390 Next Header field identifies a separate transport, which reduces the 391 probability that corruption could result in the packet being 392 delivered to the wrong endpoint or application. Specifically, 393 packets are only delivered to protocol modules that process a 394 specific next header value. The next header field therefore provides 395 a first-level check of correct demultiplexing. In contrast, the UDP 396 port space is shared by many diverse application and therefore UDP de 397 multiplexing relies solely on the port numbers. 399 3. Evaluation of proposal to update to RFC 2460 to support zero 400 checksum 402 This section evaluates a proposal to update IPv6 [RFC2460], to 403 provide the option that some nodes may suppress generation and 404 checking of the UDP transport checksum. The decision to omit an 405 integrity check at the IPv6 level means that the transport check is 406 overloaded with many functions including validating: 408 o the endpoint address was not corrupted within a router - this 409 packet was meant for this destination and a wrong header has not 410 been spliced to a different payload. 412 o the extension header processing is correctly delimited - the start 413 of data has not been corrupted. The protocol type field also 414 provides some protection. 416 o reassembly processing, when used. 418 o the length of the payload. 420 o the port values - i.e. The correct application gets the payload 421 (applications should also check source ports/address). 423 o the payload integrity. 425 In IPv4, the first 4 checks are performed using the IPv4 header 426 checksum. 428 In IPv6, these checks occur within the endpoint stack using the UDP 429 checksum information. An IPv6 node also relies on the header 430 information to determine whether to send an ICMPv6 error message and 431 to determine the node to which this is sent. Corrupted information 432 may lead to misdelivery to an unintended application socket on an 433 unexpected host. 435 3.1. Alternatives to the Standard Checksum 437 There are several alternatives to the normal method for calculating 438 the UDP Checksum that do not require a tunnel endpoint to inspect the 439 entire packet when computing a checksum. These include (in 440 decreasing complexity): 442 o Delta computation of the checksum from an encapsulated checksum 443 field. Since the checksum is a cumulative sum (RFC 1624), an 444 encapsulating header checksum can be derived from the new pseudo 445 header, the inner checksum and the sum of the other network-layer 446 fields not included in the pseudo header of the encapsulated 447 packet. This would not require access to the whole packet, but 448 does require header fields to be collected across the header, and 449 arithmetic operations on each packet. The method would only work 450 for packets that contain a 2's complement transport checksum (i.e. 451 it would not be appropriate for SCTP or when IP fragmentation is 452 used). The process may be easier for IPv4 over IPv6 453 encapsulation, where the encapsulated IPv4 header checksum could 454 be used as a basis. 456 o UDP-Lite. Where the checksum coverage may be set to only the 457 header portion of a packet. This requires a pseudo header 458 checksum calculation only on the encapsulating packet header, 459 which includes extracting the UDP payload length for the pseudo 460 header, however this is expected to be also known when performing 461 packet forwarding. The value may be cached per flow/destination, 462 and subsequently combined only with the Length field to minimise 463 per-packet processing. 465 o The UDP Tunnel Transport, UDPTT [UDPTT](if progressed), where UDP 466 is modified to derive the checksum only from the encapsulating 467 packet protocol header. This value does not change between 468 packets in a flow. The value may be cached per flow/destination 469 to minimise per-packet processing. 471 o UDP modified to disable checksum processing [UDPZ](if progressed). 472 This requires no checksum calculation. 474 These options are discussed further in later sections. 476 3.2. Applicability of method 478 The expectation of the present proposal to permit omission of UDP 479 checksums [UDPZ] is that this would apply only to IPv6 router nodes 480 that implement specific protocols. However, the distinction between 481 a router and a host is not always clear, especially at the transport 482 level. Systems (such as unix-based operating systems) routinely 483 provide both functions. There is no way to identify the role of a 484 receiver from a received packet. 486 Any new method would therefore need a specific applicability 487 statement indicating when this mechanism can (and can not). There 488 are additional requirements, e.g. that fragmentation is not 489 performed, since correct reassembly can not be verified at the 490 receiver without a checksum. This would also open the receiver to a 491 wide range of mis-behaviours. This implies disabling host-based 492 fragmentation. Policing this and ensuring correct interactions with 493 the stack implies much more than simply disabling the checksum 494 algorithm for specific packets at the transport interface. There are 495 also proposals to simply ignore a specific received UDP checksum 496 value, however this also can result in problems (e.g. when used with 497 a NAT that always adjusts the checksum value). 499 The IETF should carefully consider constraints on sanctioning the use 500 of this mode. If this is specified and widely available, it may be 501 expected to be used by applications that are perceived to gain 502 benefit. Any solution that uses an end-to-end transport protocol 503 (rather than an IP in IP encapsulation) also needs to minimise the 504 possibility that end-hosts could confuse a corrupted or wrongly 505 delivered packet with that of data addressed to an application 506 running on their endpoint. 508 3.3. Effect of packet modification in the network 510 When a checksum is used with UDP/IPv6, this significantly reduces the 511 impact of such errors, reducing the probability of undetected 512 corruption of state (and data) on both the host stack and the 513 applications using the transport service. 515 P packets may be corrupted as they travers an Internet path. 516 Evidence has been presented [Sigcomm2000] to show that this was once 517 an issue with IPv4 routers, and occasional corruption could result 518 from bad internal router processing in routers or hosts. These 519 errors are not detected by the strong frame checksums employed at the 520 link-layer (RFC 3819). There is no current evidence that such cases 521 are rare in the modern Internet, nor that they may not be applicable 522 to IPv6. It therefore seems prudent not to relax this constraint. 523 The emergence of low-end IPv6 routers and the proposed use of NAT 524 with IPv6 further motivate the need to protect from this type of 525 error. 527 Corruption in the network may result in: 529 o a datagram being mis-delivered to the wrong host/router or the 530 wring transport entity within a host/router. Such a datagram 531 needs to be discarded. 533 o a datagram payload being corrupted and delivered to the intended 534 host/router transport entity. Such a datagram needs to be either 535 discarded or correctly processed by an application that has its 536 own integrity checks. 538 o a datagram payload being truncated by corruption of the length 539 field. Such a datagram needs to be discarded. 541 3.3.1. Corruption of the destination IP address 543 An IP endpoint destination address could be modified in the network 544 (corrupted by errors). This modification can not be detected in the 545 network when using IPv6. This is not a concern in IPv4, because the 546 IP header checksum will result in this packet being discarded by the 547 receiving IP stack. 549 There are two possible outcomes: 551 o Delivery to an address that is not in use (the packet will not be 552 delivered, but could result in an error report). 554 o Delivery to a different address. This modification will normally 555 be detected by the transport checksum, resulting in silent 556 discard. Without this checksum, the packet would be passed to the 557 port demultiplexing function. If an application is bound to the 558 associated ports, the packet payload will be passed to the 559 application (see the subsequent section on port processing). 561 3.3.2. Corruption of the source IP address 563 This section examines what happens when the source IPv6 address is 564 corrupted in transit. (This is not a concern in IPv4, because the IP 565 header checksum will result in this packet being discarded by the 566 receiving IP stack). 568 Corruption of an IPv6 packet's source address does not result in the 569 IP packet being delivered to a different endpoint protocol or 570 destination address. If only the source address is corrupted, the 571 packet will likely be processed in the intended context, although 572 with erroneous origin information. The result will depend on the 573 application or protocol that processes the packet. Some examples 574 are: 576 o An application that requires pre-established context may disregard 577 the packet as invalid, or could map this to another context (if a 578 context for the modified source address was already activated). 580 o A stateless application will process the packet outside of any 581 context, a simple example is the ECHO server, which will respond 582 with a packet to the modified source address. This would create 583 unwanted additional processing load, and generate traffic to the 584 modified endpoint address. 586 o Some applications build state using the information from packet 587 headers. A previously unused source address would result in 588 receiver processing and the creation of unnecessary transport- 589 layer state at the receiver. For example, RTP flows commonly 590 employ a source independent receiver port. State is created for 591 each received flow. Reception of a packet with a corrupted source 592 address would result in accumulation of unnecessary state in the 593 RTP state machine, including collision detection and response 594 (since the same Synchronization source, SSRC, value will appear to 595 arrive from multiple source IP addresses). 597 In general, the effect of corrupting the source address will depend 598 upon the protocol that processes the packet and its robustness to 599 this error. For the case where the packet is received by a tunnel 600 endpoint, the application is expected to correctly handle a corrupted 601 source address. 603 This effect is more difficult to quantify when several fields have 604 been modified in transit, and the receiving application is not that 605 originally intended. 607 3.3.3. Delivery to an unexpected port 609 This section considers what happens if one or both of the UDP port 610 values are corrupted in transit. (This can also happen with IPv4 in 611 the zero checksum case, but not when UDP checksums are enabled or 612 with UDP-Lite). If the ports were corrupted in transit, packets may 613 be delivered to the wrong process (on the intended machine) and/or 614 responses or errors sent to the wrong application process (on the 615 intended machine). 617 There are several possible outcomes for a packet that passes and does 618 not use the UDP checksum validation: 620 o Delivery to a port that is not in use. This is discarded, but 621 could generate an ICMPv6 message (e.g. port unreachable). 623 o It could be delivered to a different node that implements the same 624 application, where the packet may be accepted, generating side- 625 effects or accumulated state. 627 o It could be delivered to an application that does not implement 628 the tunnel protocol, where the packet may be incorrectly parsed, 629 and misinterpreted, generating side-effects or accumulated state. 631 The probability of this happening depends on the statistical 632 probability that the source address and the destination port of the 633 datagram (the source port is not always used in UDP) match those of 634 an existing connection. 636 Unfortunately, this may be more likely for UDP than for connection- 637 oriented transports: (a) There is no handshake prior to communication 638 and no sequence numbers (as in TCP, DCCP, SCTP). Together this makes 639 it hard to verify that an application is given only the data 640 associated with a session. (b) Applications writers often bind to 641 wild-card values in endpoint identifiers and do not always validate 642 correctness of datagrams they receive. While we could revise these 643 rules and declare naive applications as Historic, this is not 644 realistic - the transport owes it to the stack to do its best to 645 reject bogus datagrams. 647 If checksum coverage is suppressed, the application needs to provide 648 a method to detect and discard the unwanted data. The encapsulated 649 tunnel protocol would need to perform its own integrity checks on any 650 control information and ensure an integrity check is applied to the 651 tunneled packet. It is not reasonable to assume that it is safe for 652 one application to use a zero checksum value and that other 653 applications will not. It is important to consider the possibility 654 that a packet will be received by a different node to that for which 655 it was intended, or that it will arrive at the correct tunnel 656 destination with the wrong source address in the external header. 658 3.3.4. Validating the network path 660 IP transports designed for use in the general Internet should not 661 assume specific characteristics. Network protocols may reroute 662 packets and change the set of routers and middleboxes along a path. 663 Therefore transports such as TCP, SCTP and DCCP are designed to 664 negotiate protocol parameters, adapt to different characteristics, 665 and receive feedback that the current path is suited to the intended 666 application. Applications using UDP and UDP-Lite need to provide 667 their own mechanisms to confirm the validity of the current network 668 path. 670 Any application/tunnel that seeks to make use of zero checksum must 671 include functionality to both negotiate and verify that the zero 672 checksum support is provided by the path and validate that this 673 continues to work (e.g., in the case of re-routing events) between 674 the intended parties. This increases the complexity of using such a 675 solution. 677 3.4. Comparision 679 This section compares different methods. This includes two proposals 680 for updating the behaviour of UDP. These are provided as examples, 681 and do not seek to endorse any specific method or suggest that these 682 proposals are ready to be standardised. 684 Comparison of functions for selected methods 685 UDP UDPv4 UDPL IP IP UDPv6 UDPv6 UDPTT 686 zero in in zero 687 IPv4 IPv6 689 Incremental cksum update? X - X N/A N/A X - X 690 Verification of IP length? X X X X X X X X 691 Detect dest addr corruption? X X X X - X - X 692 Detect NH addr corruption? - - - X - - - - 693 Flow demux fields present? X X X - X X X X 694 Detect port corruption? X - X N/A N/A X - X 695 Detect illegal pay length? X X - N/A N/A X X - 696 Detect pay corruption? X - ? N/A N/A X - - 697 Static cksum per flow? - X - N/A N/A - X X 698 Partial/full midbox support? X * ? ? ? X ? ? 699 Restricted tunnel behaviour X * X X ? X - X 701 X = Provided/supported 702 - = Not provided/supported 703 N/A = Not applicable 704 ? = Partial support 705 * = Supports a subset of functions (i.e. not all combinations) 706 Table 1 708 4. Requirements on the specification of transported protocols 710 If the IETF were to revise the standard for UDP using IPv6 for 711 specific use-cases there are a set of questions that would need to be 712 answered. These include: 714 Is there a reason why IP in IP is not a reasonable choice for 715 encapsulation? 717 o Examples of arguments for requiring an encapsulation beyond 718 IP-in-IP include the need for NAT traversal and/or firewall 719 traversal. However, the use of any non-standard transport 720 protocol or variant would also require specific support in 721 middleboxes. 723 o Another example is a need to perform port-demultiplexing (e.g. for 724 load balancing). This need could be met using UDP, UDP-Lite, or 725 other transports, or by utilising the IPv6 flow label. 727 Is there a reason why UDP-Lite is not a reasonable choice for 728 encapsulation? 730 o One argument against using UDP-Lite is that this transport is that 731 this transport is not implemented on all endpoints. However, 732 there is at least one open source implementation. 734 o Another argument against using UDP-Lite is that it uses a 735 different IPv6 Next Header, which is currently not widely 736 supported in middleboxes (see previous). 738 o It has also been argued that UDP-Lite requires a checksum 739 computation. The UDP-Lite checksum, for instance includes the 740 length field, but need not include the IP payload, and therefore 741 would not require access to the full datagram payload by the 742 tunnel endpoints. 744 If the IETF needs to revise the rationale for UDP checksums in RFC 745 2460, should we remove the checksum or replace it with one closer to 746 UDP-Lite (e.g. UDPTT)? 748 Topics to be considered in making this decision: 750 o The role of a router and host are not fixed, and a consistent 751 method must be specified that can be used on all nodes. It can 752 not be assumed that a particular protocol (or transport mode) will 753 only be used on a specific type of network node (e.g. permitting 754 the UDP checksum to be disabled only on a router). In IPv6, a 755 node selects the role of a router or host on a per interface 756 basis. It is important to note that protocol changes intended for 757 one specific use are often re-used for different applications. 759 o Behaviour of NAT/Middleboxes needs to be updated for UDPTT and for 760 UDP cksum==0. 762 o Load balancing may not be enabled for all transport protocols. 764 o Implications on host acting as routers and transport end points. 766 o Appropriate mechanisms to negotiate and validate the properties of 767 the network path, including consideration of the impact of 768 rerouting. 770 o Whether this requires restrictions on recursive tunnels (e.g. 771 Necessary when the endpoint is not verified). 773 If a zero checksum approach were to be adopted by the IETF, the 774 specification should consider adding the following constraints on 775 usage: 777 1. The method must be specified to verify the integrity of the inner 778 (tunneled) packet. 780 2. The tunneling protocol must not allow fragmentation of the inner 781 packets being carried. We would suggest the following 782 elaborations of the above restrictions, if a change in the IPv6 783 specification moves forward: That is, an inner IPv4 packet with a 784 UDP checksum equal to 0 must not be tunneled 786 3. If a method proposes selective ignoring of the checksum on 787 reception, it needs to provide guidance that is appropriate for 788 all use-cases, including defining how currently standardised 789 nodes handle any new use. 791 4. Other tunneling protcocols that use the UDP checksum equal to 0 792 must not be tunneled themselves, even if more deeply encapsulated 793 packets have checksums or other integrity checking mechanisms. 795 5. Non-IP inner (tunneled) packets must have a CRC or other 796 mechanism for checking packet integrity. 798 6. The specification needs to consider whether to prevent recursive 799 tunnels (e.g. necessary when the endpoint is not verified). 801 7. It is recommended that general protocol stack implementations do 802 not by default allow the new method. The new method should 803 remain restricted to devices serving as endpoints of the 804 lightweight tunneling protocol adopting the change. 806 5. Summary 808 This document examines the role of the transport checksum when used 809 with IPv6, as defined in RFC2460. 811 It presents a summary of the trade-offs for evaluating the safety of 812 updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value 813 in the checksum field to indicate that no checksum is present. A 814 decision not to include a UDP checksum in received IPv6 datagrams 815 could impact a tunnel application that receives these packets. 816 However, a well-designed tunnel application should include 817 consistency checks to validate any header information encapsulated 818 with a packet and ensure that a an integrity check is included for 819 each tunneled packet. When correctly implemented, such a tunnel 820 endpoint will not be negatively impacted by omission of the 821 transport-layer checksum. However, other applications at the 822 intended destination node or another IPv6 node can be impacted if 823 they are allowed to receive datagrams without a transport-layer 824 checksum. 826 In particular, it is important that already deployed applications are 827 not impacted by any change at the transport layer. If these 828 applications execute on nodes that implement RFC 2460, they will 829 reject all datagrams without a UDP checksum. 831 The implications on firewalls, NATs and other middleboxes need to be 832 considered. It should not be expected that NATs handle IPv6 UDP 833 datagrams in the same way as they handle IPv4 UDP datagrams. 834 Firewalls are intended to be configured, and therefore may need to be 835 explicitly updated to allow new services or protocols. 837 If the use of UDP transport without a checksum were to become 838 prevalent for IPv6 (e.g. tunnel protocols using this are widely 839 deployed), there would also be a significant danger of the Internet 840 carrying an increased volume of packets without a transport checksum 841 for other applications, potentially including applications that have 842 traditionally used IPv4 UDP transport without a checksum. This 843 result is highly undesirable. In general, UDP-based applications 844 need to employ a mechanism that allows a large percentage of the 845 corrupted packets to be removed before they reach an application, 846 both to protect the applications data stream and the control plane of 847 higher layer protocols. These checks are currently performed by the 848 UDP checksum for IPv6, or the reduced checksum for UDP-Lite when used 849 with IPv6. 851 Although the use of UDP over IPv6 with no checksum may have merits 852 for use as a tunnel encapsulation and is widely used in IPv4, it is 853 considered dangerous for all IPv6 nodes (hosts and routers). Other 854 solutions need to be found. This requires rthat the IPv4 and IPv6 855 solutions to differ, since there are different deployed 856 infrastructures. 858 6. Acknowledgements 860 Brian Haberman, Brian Carpenter, Magaret Wasserman, Lars Eggert, 861 Magnus Westerlund, others in the TSV directorate. 863 Thanks also to: Remi Denis-Courmont, Pekka Savola and many others who 864 contributed comments and ideas via the 6man, behave, lisp and mboned 865 lists. 867 7. IANA Considerations 869 This document does not require IANA considerations. 871 8. Security Considerations 873 Transport checksums provide the first stage of protection for the 874 stack, although they can not be considered authentication mechanisms. 875 These checks are also desirable to ensure packet counters correctly 876 log actual activity, and can be used to detect unusual behaviours. 878 9. References 880 9.1. Normative References 882 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 883 September 1981. 885 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 886 RFC 793, September 1981. 888 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 889 "Computing the Internet checksum", RFC 1071, 890 September 1988. 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, March 1997. 895 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 896 (IPv6) Specification", RFC 2460, December 1998. 898 9.2. Informative References 900 [AMT] Internet draft, draft-ietf-mboned-auto-multicast-09, 901 "Automatic IP Multicast Without Explicit Tunnels (AMT)", 902 June 2008. 904 [ECMP] "Using the IPv6 flow label for equal cost multipath 905 routing in tunnels (draft-carpenter-flow-ecmp)". 907 [LISP] Internet draft, draft-farinacci-lisp-12.txt, "Locator/ID 908 Separation Protocol (LISP)", March 2009. 910 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 911 August 1980. 913 [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the 914 Internet checksum", RFC 1141, January 1990. 916 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 917 (SIIT)", RFC 2765, February 2000. 919 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 920 G. Fairhurst, "The Lightweight User Datagram Protocol 921 (UDP-Lite)", RFC 3828, July 2004. 923 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 924 December 2005. 926 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 927 RFC 4303, December 2005. 929 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 930 for Application Designers", BCP 145, RFC 5405, 931 November 2008. 933 [Sigcomm2000] 934 http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/ 935 9-1.htm, "When the CRC and TCP Checksum Disagree", 2000. 937 [UDPTT] "The UDP Tunnel Transport mode", Feb 2010. 939 [UDPZ] "UDP Checksums for Tunneled Packets", (Oct 2009. 941 Appendix A. Document Change History 943 {RFC EDITOR NOTE: This section must be deleted prior to publication} 944 Individual Draft 00 This is the first DRAFT of this document - It 945 contains a compilation of various discussions and contributions 946 from a variety of IETF WGs, including: mboned, tsv, 6man, lisp, 947 and behave. This includes contributions from Magnus with text on 948 RTP, and various updates. 950 Individual Draft 01 952 * This version corrects some typos and editorial NiTs and adds 953 discussion of the need to negotiate and verify operation of a 954 new mechanism (3.3.4). 956 Individual Draft 02 958 * Version -02 corrects some typos and editorial NiTs. 960 * Added reference to ECMP for tunnels. 962 * Clarifies the recommendations at the end of the document. 964 Authors' Addresses 966 Godred Fairhurst 967 University of Aberdeen 968 School of Engineering 969 Aberdeen, AB24 3UE, 970 Scotland, UK 972 Phone: 973 Email: gorry@erg.abdn.ac.uk 974 URI: http://www.erg.abdn.ac.uk/users/gorry 976 Magnus Westerlund 977 Ericsson Research 978 Torshamgatan 23 979 Stockholm, SE-164 80 980 Sweden 982 Phone: 983 Fax: 984 Email: magnus.westerlund@ericsson.com 985 URI: