--- 1/draft-ietf-6man-udpchecksums-03.txt 2012-09-05 13:14:52.705342876 +0200 +++ 2/draft-ietf-6man-udpchecksums-04.txt 2012-09-05 13:14:52.733342506 +0200 @@ -1,22 +1,22 @@ Network Working Group M. Eubanks Internet-Draft AmericaFree.TV LLC Updates: 2460 (if approved) P. Chimento Intended status: Standards Track Johns Hopkins University Applied -Expires: February 8, 2013 Physics Laboratory +Expires: March 9, 2013 Physics Laboratory M. Westerlund Ericsson - August 7, 2012 + September 5, 2012 UDP Checksums for Tunneled Packets - draft-ietf-6man-udpchecksums-03 + draft-ietf-6man-udpchecksums-04 Abstract This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance of IPv6 in the use case when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 8, 2013. + This Internet-Draft will expire on March 9, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect @@ -71,49 +71,49 @@ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction - This work constitutes the first update of the Internet Protocol - Version 6 (IPv6) Specification [RFC2460], in the use case when a - tunnel protocol uses UDP with IPv6 to tunnel packets. With the rapid - growth of the Internet, tunneling protocols have become increasingly - important to enable the deployment of new tunnel protocols. Tunneled + This work constitutes an update of the Internet Protocol Version 6 + (IPv6) Specification [RFC2460], in the use case when a tunnel + protocol uses UDP with IPv6 to tunnel packets. With the rapid growth + of the Internet, tunneling protocols have become increasingly + important to enable the deployment of new protocols. Tunneled protocols can be deployed rapidly, while the time to upgrade and deploy a critical mass of routers, switches and end hosts on the - global Internet for a new tunnel protocol is now measured in decades. - At the same time, the increasing use of firewalls and other security + global Internet for a new protocol is now measured in decades. At + the same time, the increasing use of firewalls and other security related middleboxes means that truly new tunnel protocols, with new protocol numbers, are also unlikely to be deployable in a reasonable time frame, which has resulted in an increasing interest in and use of UDP-based tunneling protocols. In such protocols, there is an encapsulated "inner" packet, and the "outer" packet carrying the tunneled inner packet is a UDP packet, which can pass through firewalls and other middleboxes filtering that is a fact of life on the current Internet. Tunnel endpoints may be routers or middleboxes aggregating traffic from a large number of tunnel users, therefore the computation of an additional checksum on the outer UDP packet, may be seen as an unwarranted burden on nodes that implement a tunneling protocol, especially if the inner packet(s) are already protected by a checksum. In IPv4, there is a checksum on the IP packet itself, and the checksum on the outer UDP packet can be set to zero. However in IPv6 there is not a checksum on the IP packet and RFC 2460 [RFC2460] explicitly states that IPv6 receivers MUST discard UDP packets with a - 0 checksum. So, while sending a UDP packet with a 0 checksum is - permitted in IPv4 packets, it is explicitly forbidden in IPv6 + zero checksum. So, while sending a UDP packet with a zero checksum + is permitted in IPv4 packets, it is explicitly forbidden in IPv6 packets. To improve support for IPv6 UDP tunnels, this document updates RFC 2460 to allow tunnel endpoints to use a zero UDP checksum under constrained situations (IPv6 tunnel transports that carry checksum-protected packets), following the considerations in [I-D.ietf-6man-udpzero]. Unicast UDP Usage Guidelines for Application Designers [RFC5405] should be consulted when reading this specification. It discusses both UDP tunnels (Section 3.1.3) and the usage of Checksums (Section 3.4). @@ -178,28 +178,29 @@ RFC 2460) will discard the zero-checksum UDP packets, and should log this as an error. The below discuss how path errors can be detected and handled in an UDP tunneling protocol when the checksum protection is disabled. Note that other (non-tunneling) protocols may have different approaches, but these are not the topic of this update. We propose the following approach to handle this problem: o Context (i.e. tunneling state) should be established via - application PDUs that are carried in checksummed UDP packets. - That is, any control packets flowing between the tunnel endpoints - should be protected by UDP checksums. The control packets can - also contain any negotiation required to enable the endpoint/ - adapters to accept UDP packets with a zero checksum. The control - packets may also carry any negotiation required to enable the - endpoint/adapters to identify the set of ports that need to enable - reception UDP datagrams with a zero checksum. + application Protocol Data Units (PDUs) that are carried in + checksummed UDP packets. That is, any control packets flowing + between the tunnel endpoints should be protected by UDP checksums. + The control packets can also contain any negotiation required to + enable the endpoint/adapters to accept UDP packets with a zero + checksum. The control packets may also carry any negotiation + required to enable the endpoint/adapters to identify the set of + ports that need to enable reception UDP datagrams with a zero + checksum. o A system shall not set the UDP checksum to zero in packets that do not contain tunneled packets. o UDP keep-alive packets with checksum zero can be sent to validate paths, given that paths between tunnel endpoints can change and so middleboxes in the path may vary during the life of the association. Paths with middleboxes that are intolerant of a UDP checksum of zero will drop the keep-alives and the endpoints will discover that. Note that this need only be done per tunnel @@ -317,21 +318,21 @@ 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams with a zero-checksum. A port for which zero-checksum has been enabled MUST NOT log zero-checksum datagrams for that reason (of course, there might be other reasons to log such packets). 4. A stack may separately identify UDP datagrams that are discarded with a zero checksum. It SHOULD NOT add these to the standard log, since the endpoint has not been verified. - 5. UDP Tunnels that encapsulate IP may rely on the inner packet + 5. UDP Tunnels that encapsulate IP MAY rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, then the tunnel MUST provide an additional integrity verification mechanism. An integrity mechanism is always recommended at the tunnel layer to ensure that corruption rates of the inner most packet are not increased. 6. Tunnels that encapsulate Non-IP packets MUST have a CRC or other mechanism for checking packet integrity, unless the