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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/