draft-ietf-6man-udpchecksums-01.txt   draft-ietf-6man-udpchecksums-02.txt 
Network Working Group M. Eubanks Network Working Group M. Eubanks
Internet-Draft AmericaFree.TV LLC Internet-Draft AmericaFree.TV LLC
Intended status: Standards Track P. Chimento Intended status: Standards Track P. Chimento
Expires: May 3, 2012 Johns Hopkins University Applied Expires: September 13, 2012 Johns Hopkins University Applied
Physics Laboratory Physics Laboratory
October 31, 2011 March 12, 2012
UDP Checksums for Tunneled Packets UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-01 draft-ietf-6man-udpchecksums-02
Abstract Abstract
This document provides an update of RFC 2460[RFC2460] in order to This document provides an update of RFC 2460[RFC2460] in order to
improve the performance of IPv6 in an increasingly important use improve the performance of IPv6 in an increasingly important use
case, the use of tunneling to carry new transport protocols. The case, the use of tunneling to carry new transport protocols. The
performance improvement is obtained by relaxing the IPv6 UDP checksum performance improvement is obtained by relaxing the IPv6 UDP checksum
requirement for suitable tunneling protocol where header information requirement for suitable tunneling protocol where header information
is protected on the "inner" packet being carried. This relaxation is protected on the "inner" packet being carried. This relaxation
removes the overhead associated with the computation of UDP checksums removes the overhead associated with the computation of UDP checksums
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 May 3, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 45 skipping to change at page 4, line 45
checksum is permitted in IPv4 packets, it is explicitly forbidden in checksum is permitted in IPv4 packets, it is explicitly forbidden in
IPv6 packets. In order to meet the needs of the deployers of IPv6 IPv6 packets. In order to meet the needs of the deployers of IPv6
UDP tunnels, this document modifies RFC 2460 to allow for the UDP tunnels, this document modifies RFC 2460 to allow for the
ignoring of UDP checksums under constrained situations (IPv6 ignoring of UDP checksums under constrained situations (IPv6
tunneling where the inner packet exists and has a checksum), based on tunneling where the inner packet exists and has a checksum), based on
the considerations set forth in [I-D.ietf-6man-udpzero]. the considerations set forth in [I-D.ietf-6man-udpzero].
While the origin of this I-D is the problem raised by the draft While the origin of this I-D is the problem raised by the draft
titled "Automatic IP Multicast Without Explicit Tunnels", also known titled "Automatic IP Multicast Without Explicit Tunnels", also known
as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide
applicability, immediately to LISP [I-D.ietf-lisp], and also to other applicability, immediately to AMT and LISP [I-D.ietf-lisp], and in
tunneling protocols to come out of Softwires and other IETF Working the future to other tunneling protocols to come out of Softwires and
Groups. other IETF Working Groups.
Since the first version of this document, the need for an efficient, Since the first version of this document, the need for an efficient,
lightweight UDP tunneling mechanism has increased. Indeed, other lightweight UDP tunneling mechanism has increased. Indeed, other
workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have
also expressed a need to have exceptions to the RFC 2460 prohibition. also expressed a need to have exceptions to the RFC 2460 prohibition.
Other users of UDP as a tunneling protocol, for example, L2TP and Other users of UDP as a tunneling protocol, for example, L2TP and
Softwires may benefit from a relaxation of the RFC 2460 restriction. Softwires may benefit from a relaxation of the RFC 2460 restriction.
The third version of this document benefited from a close read by The third version of this document benefited from a close read by
skipping to change at page 5, line 47 skipping to change at page 5, line 47
[I-D.ietf-6man-udpzero] describes the issues related to allowing UDP [I-D.ietf-6man-udpzero] describes the issues related to allowing UDP
over IPv6 to have a valid checksum of zero and is not repeated here. over IPv6 to have a valid checksum of zero and is not repeated here.
In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine
(9) constraints on the usage of a zero checksum for UDP over IPv6. (9) constraints on the usage of a zero checksum for UDP over IPv6.
We agree with the restrictions proposed, and in fact proposed some of We agree with the restrictions proposed, and in fact proposed some of
those restrictions ourselves in the previous version of the current those restrictions ourselves in the previous version of the current
draft. These restrictions are incorporated into the proposed changes draft. These restrictions are incorporated into the proposed changes
below. below.
As has been pointed out in [I-D.ietf-6man-udpzero] and in many As has been pointed out in [I-D.ietf-6man-udpzero] and in various
mailing lists, there is still the possibility of deep-inspection mailing list discussions, there is still the possibility of deep-
firewall devices or other middleboxes actually checking the UDP inspection firewall devices or other middleboxes actually checking
checksum field of the outer packet and discarding the tunneling the UDP checksum field of the outer packet and thereby discarding the
packets. This is would be an issue also for legacy systems which tunneling packets. This is would be an issue also for legacy systems
have not implemented the change in the IPv6 specification. So in any which have not implemented the change in the IPv6 specification. So
case, there may be packet loss of lightweight tunneling packets in any case, there may be packet loss of lightweight tunneling
because of mixed new-rule and old-rule nodes. packets because of mixed new-rule and old-rule nodes.
As an example, we discuss how can errors be detected and handled in a As an example, we discuss how can errors be detected and handled in a
lightweight UDP tunneling protocol when the checksum protection is lightweight UDP tunneling protocol when the checksum protection is
disabled. Note that other (non-tunneling) protocols may have disabled. Note that other (non-tunneling) protocols may have
different approaches. We suggest that the following could be an different approaches. We suggest that the following could be an
approach to this problem: approach to 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 PDUs that are carried in checksummed UDP packets.
That is, any control packets flowing between the tunnel endpoints That is, any control packets flowing between the tunnel endpoints
skipping to change at page 10, line 24 skipping to change at page 10, line 24
being developed in the IETF requires a definitive policy. The being developed in the IETF requires a definitive policy. The
authors would like to make the following observations: authors would like to make the following observations:
o An empirically-based analysis of the probabilities of packet o An empirically-based analysis of the probabilities of packet
corruptions (with or without checksums) has not (to our knowledge) corruptions (with or without checksums) has not (to our knowledge)
been conducted since about 2000. It is now 2011. We strongly been conducted since about 2000. It is now 2011. We strongly
suggest that an empirical study is in order, along with an suggest that an empirical study is in order, along with an
extensive analysis of IPv6 header corruption probabilities. extensive analysis of IPv6 header corruption probabilities.
o A key cause of this issue generally is the lack of protocol o A key cause of this issue generally is the lack of protocol
support in middleboxes. Specifically, new protocols, such as support in middleboxes. Specifically, new protocols, such as LISP
LISP, are being forced to use UDP tunnels just to traverse an end- [I-D.ietf-lisp], are being forced to use UDP tunnels just to
to-end path successfully and avoid having their packets dropped by traverse an end-to-end path successfully and avoid having their
middleboxes. If this were not the case, the use of UDP-lite might packets dropped by middleboxes. If this were not the case, the
become more viable for some (but not necessarily all) lightweight use of UDP-lite [RFC3828] might become more viable for some (but
tunneling protocols. not necessarily all) lightweight tunneling protocols.
o Another cause of this issue is that the UDP checksum is overloaded o Another cause of this issue is that the UDP checksum is overloaded
with the task of protecting the IPv6 header for UDP flows (as it with the task of protecting the IPv6 header for UDP flows (as it
the TCP checksum for TCP flows). Protocols that do not use a the TCP checksum for TCP flows). Protocols that do not use a
pseudo-header approach to computing a checksum or CRC have pseudo-header approach to computing a checksum or CRC have
essentially no protection from misdelivered packets. essentially no protection from mis-delivered packets.
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
8. Security Considerations 8. Security Considerations
skipping to change at page 11, line 23 skipping to change at page 11, line 23
We would like to thank Brian Haberman, Magnus Westerlund and Gorry We would like to thank Brian Haberman, Magnus Westerlund and Gorry
Fairhurst for discussions and reviews. Fairhurst for discussions and reviews.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
"Softwire Security Analysis and Requirements", RFC 5619, "Softwire Security Analysis and Requirements", RFC 5619,
August 2009. August 2009.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6man-udpzero] [I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-04 (work in Considerations", draft-ietf-6man-udpzero-05 (work in
progress), October 2011. progress), December 2011.
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-15 (work in progress), July 2011. draft-ietf-lisp-22 (work in progress), February 2012.
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Bumgardner, G. and T. Morin, "Automatic Multicast
Pusateri, "Automatic IP Multicast Without Explicit Tunnels Tunneling", draft-ietf-mboned-auto-multicast-12 (work in
(AMT)", draft-ietf-mboned-auto-multicast-11 (work in progress), February 2012.
progress), July 2011.
Authors' Addresses Authors' Addresses
Marshall Eubanks Marshall Eubanks
AmericaFree.TV LLC AmericaFree.TV LLC
P.O. Box 141 P.O. Box 141
Clifton, Virginia 20124 Clifton, Virginia 20124
USA USA
Phone: +1-703-501-4376 Phone: +1-703-501-4376
 End of changes. 13 change blocks. 
33 lines changed or deleted 29 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/