draft-ietf-6man-udpzero-09.txt   draft-ietf-6man-udpzero-10.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: July 23, 2013 Ericsson Expires: July 25, 2013 Ericsson
January 19, 2013 January 21, 2013
Applicability Statement for the use of IPv6 UDP Datagrams with Zero Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums Checksums
draft-ietf-6man-udpzero-09 draft-ietf-6man-udpzero-10
Abstract Abstract
This document provides an applicability statement for the use of UDP This document provides an applicability statement for the use of UDP
transport checksums with IPv6. It defines recommendations and transport checksums with IPv6. It defines recommendations and
requirements for the use of IPv6 UDP datagrams with a zero UDP requirements for the use of IPv6 UDP datagrams with a zero UDP
checksum. It describes the issues and design principles that need to checksum. It describes the issues and design principles that need to
be considered when UDP is used with IPv6 to support tunnel be considered when UDP is used with IPv6 to support tunnel
encapsulations and examines the role of the IPv6 UDP transport encapsulations and examines the role of the IPv6 UDP transport
checksum. An appendix presents a summary of the trade-offs that were checksum. An appendix presents a summary of the trade-offs that were
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 July 23, 2013. This Internet-Draft will expire on July 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 49 skipping to change at page 3, line 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Evaluation of proposal to update RFC 2460 to Appendix A. Evaluation of proposal to update RFC 2460 to
support zero checksum . . . . . . . . . . . . . . . . 28 support zero checksum . . . . . . . . . . . . . . . . 28
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28 A.1. Alternatives to the Standard Checksum . . . . . . . . . . 28
A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30 A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 30
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31 A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 31
A.2.3. Ingress and Egress Performance Implications . . . . . 31 A.2.3. Ingress and Egress Performance Implications . . . . . 31
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 31 A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 32
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32 A.2.5. Corruption Detection Strength . . . . . . . . . . . . 32
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 32 A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 33
Appendix B. Document Change History . . . . . . . . . . . . . . . 35 Appendix B. Document Change History . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] transport is defined for The User Datagram Protocol (UDP) [RFC0768] transport is defined for
the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet the Internet Protocol (IPv4) [RFC0791] and is defined in "Internet
Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The Protocol, Version 6 (IPv6) [RFC2460] for IPv6 hosts and routers. The
UDP transport protocol has a minimal set of features. This limited UDP transport protocol has a minimal set of features. This limited
set has enabled a wide range of applications to use UDP, but these set has enabled a wide range of applications to use UDP, but these
skipping to change at page 5, line 44 skipping to change at page 5, line 44
checksum. The provided comparison of methods is expected to also be checksum. The provided comparison of methods is expected to also be
useful when considering applications that have different goals from useful when considering applications that have different goals from
the ones that initiated the writing of this document, especially the the ones that initiated the writing of this document, especially the
use of already standardized methods. The analysis concludes that use of already standardized methods. The analysis concludes that
using a zero UDP checksum is the best method of the proposed using a zero UDP checksum is the best method of the proposed
alternatives to meet the goals for certain tunnel applications. alternatives to meet the goals for certain tunnel applications.
This document defines recommendations and requirements for use of This document defines recommendations and requirements for use of
IPv6 datagrams with a zero UDP checksum. This usage is expected to IPv6 datagrams with a zero UDP checksum. This usage is expected to
have initial deployment issues related to middleboxes, limiting the have initial deployment issues related to middleboxes, limiting the
usability more than desired in the currently deployed internet. usability more than desired in the currently deployed Internet.
However, this limitation will be largest initially and will reduce as However, this limitation will be largest initially and will reduce as
updates are provided in middleboxes that support the zero UDP updates are provided in middleboxes that support the zero UDP
checksum for IPv6. The document therefore derives a set of checksum for IPv6. The document therefore derives a set of
constraints required to ensure safe deployment of a zero UDP constraints required to ensure safe deployment of a zero UDP
checksum. checksum.
Finally, the document also identifies some issues that require future Finally, the document also identifies some issues that require future
consideration and possibly additional research. consideration and possibly additional research.
1.1. Document Structure 1.1. Document Structure
skipping to change at page 10, line 46 skipping to change at page 10, line 46
Tunnel encapsulations can use UDP-Lite (e.g. Control And Tunnel encapsulations can use UDP-Lite (e.g. Control And
Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP- Provisioning of Wireless Access Points, CAPWAP [RFC5415]), since UDP-
Lite provides a transport-layer checksum, including an IP pseudo Lite provides a transport-layer checksum, including an IP pseudo
header checksum, in IPv6, without the need for a router/middlebox to header checksum, in IPv6, without the need for a router/middlebox to
traverse the entire packet payload. This provides most of the traverse the entire packet payload. This provides most of the
verification required for delivery and still keeps a low complexity verification required for delivery and still keeps a low complexity
for the checksumming operation. UDP-Lite may set the length of for the checksumming operation. UDP-Lite may set the length of
checksum coverage on a per packet basis. This feature could be used checksum coverage on a per packet basis. This feature could be used
if a tunnel protocol is designed to only verify delivery of the if a tunnel protocol is designed to only verify delivery of the
tunneled payload and uses a calcuated checksum for control tunneled payload and uses a calculated checksum for control
information. information.
There is currently poor support for middlebox traversal using UDP- There is currently poor support for middlebox traversal using UDP-
Lite, because UDP-Lite uses a different IPv6 network-layer Next Lite, because UDP-Lite uses a different IPv6 network-layer Next
Header value to that of UDP, and few middleboxes are able to Header value to that of UDP, and few middleboxes are able to
interpret UDP-Lite and take appropriate actions when forwarding the interpret UDP-Lite and take appropriate actions when forwarding the
packet. This makes UDP-Lite less suited to protocols needing general packet. This makes UDP-Lite less suited to protocols needing general
Internet support, until such time that UDP-Lite has achieved better Internet support, until such time that UDP-Lite has achieved better
support in middleboxes and end-points. support in middleboxes and end-points.
skipping to change at page 16, line 33 skipping to change at page 16, line 33
Reassembly failure: An error in the "More Fragments" field for the Reassembly failure: An error in the "More Fragments" field for the
last fragment will for example result in the packet never being last fragment will for example result in the packet never being
considered complete and will eventually be timed out and considered complete and will eventually be timed out and
discarded. A corruption in the ID field will result in the discarded. A corruption in the ID field will result in the
fragment not being delivered to the intended context thus leaving fragment not being delivered to the intended context thus leaving
the rest incomplete, unless that packet has been duplicated prior the rest incomplete, unless that packet has been duplicated prior
to corruption. The incomplete packet will eventually be timed out to corruption. The incomplete packet will eventually be timed out
and discarded. and discarded.
Erroneous reassembly: The re-assemblied packet did not match the Erroneous reassembly: The re-assembled packet did not match the
original packet. This can occur when the ID field of a fragment original packet. This can occur when the ID field of a fragment
is corrupted, resulting in a fragment becoming associated with is corrupted, resulting in a fragment becoming associated with
another packet and taking the place of another fragment. another packet and taking the place of another fragment.
Corruption in the offset information can cause the fragment to be Corruption in the offset information can cause the fragment to be
misaligned in the reassembly buffer, resulting in incorrect misaligned in the reassembly buffer, resulting in incorrect
reassembly. Corruption can cause the packet to become shorter or reassembly. Corruption can cause the packet to become shorter or
longer, however completion of reassembly is much less probable, longer, however completion of reassembly is much less probable,
since this would require consistent corruption of the IPv6 headers since this would require consistent corruption of the IPv6 headers
payload length field and the offset field. The possibility of payload length field and the offset field. The possibility of
mis-assembly requires the reassembling stack to provide strong mis-assembly requires the reassembling stack to provide strong
skipping to change at page 21, line 50 skipping to change at page 21, line 50
indicate the set of ports that will be enabled to receive indicate the set of ports that will be enabled to receive
datagrams with a zero UDP checksum. This may be implemented via datagrams with a zero UDP checksum. This may be implemented via
a socket API call, or similar mechanism. It may also be a socket API call, or similar mechanism. It may also be
implemented by enabling the method for a pre-assigned static implemented by enabling the method for a pre-assigned static
port used by a specific tunnel protocol. port used by a specific tunnel protocol.
7. IPv6 nodes supporting usage of zero UDP checksums MUST also 7. IPv6 nodes supporting usage of zero UDP checksums MUST also
allow reception using a calculated UDP checksum on all ports allow reception using a calculated UDP checksum on all ports
configured to allow zero UDP checksum usage. (The sending configured to allow zero UDP checksum usage. (The sending
endpoint, e.g. encapsulating ingress, may choose to compute the endpoint, e.g. encapsulating ingress, may choose to compute the
UDP checksum, or may calculate this by default.) The receving UDP checksum, or may calculate this by default.) The receiving
endpoint MUST use the reception method specified in RFC2460 when endpoint MUST use the reception method specified in RFC2460 when
the checksum field is not zero. the checksum field is not zero.
8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams 8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams
with a zero UDP checksum. This remains the case for any with a zero UDP checksum. This remains the case for any
datagram received on a port that does not explicitly enable datagram received on a port that does not explicitly enable
processing of a zero UDP checksum. A port for which the zero processing of a zero UDP checksum. A port for which the zero
UDP checksum has been enabled MUST NOT log the datagram solely UDP checksum has been enabled MUST NOT log the datagram solely
because the checksum value is zero. because the checksum value is zero.
skipping to change at page 22, line 33 skipping to change at page 22, line 33
port numbers in the ICMPv6 message body). port numbers in the ICMPv6 message body).
5. Requirements on usage of the zero UDP checksum 5. Requirements on usage of the zero UDP checksum
This section is an applicability statement that identifies This section is an applicability statement that identifies
requirements and recommendations for protocols and tunnel requirements and recommendations for protocols and tunnel
encapsulations that are transported over an IPv6 transport flow (e.g. encapsulations that are transported over an IPv6 transport flow (e.g.
tunnel) that does not perform a UDP checksum calculation to verify tunnel) that does not perform a UDP checksum calculation to verify
the integrity at the transport endpoints. the integrity at the transport endpoints.
1. Transported potocols that enable the use of zero UDP checksum 1. Transported protocols that enable the use of zero UDP checksum
MUST only enable this for a specific port or port-range. This MUST only enable this for a specific port or port-range. This
needs to be enabled at the sending and receibing ednpoints for a needs to be enabled at the sending and receiving endpoints for a
UDP flow. UDP flow.
2. An integrity mechanism is always RECOMMENDED at the transported 2. An integrity mechanism is always RECOMMENDED at the transported
protocol layer to ensure that corruption rates of the delivered protocol layer to ensure that corruption rates of the delivered
payload is not increased (e.g. the inner-most packet of a UDP payload is not increased (e.g. the inner-most packet of a UDP
tunnel). A mechanism that isolates the causes of corruption tunnel). A mechanism that isolates the causes of corruption
(e.g. identifying misdelivery, IPv6 header corruption, tunnel (e.g. identifying misdelivery, IPv6 header corruption, tunnel
header corruption) is expected to also provide additional header corruption) is expected to also provide additional
information about the status of the tunnel (e.g. to suggest a information about the status of the tunnel (e.g. to suggest a
security attack). security attack).
skipping to change at page 23, line 13 skipping to change at page 23, line 13
significantly increased corruption rate can occur, then the significantly increased corruption rate can occur, then the
tunnel protocol MUST provide an additional integrity tunnel protocol MUST provide an additional integrity
verification mechanism. Early detection is desirable to avoid verification mechanism. Early detection is desirable to avoid
wasting unnecessary computation, transmission capacity or wasting unnecessary computation, transmission capacity or
storage for packets that will subsequently be discarded. storage for packets that will subsequently be discarded.
4. A transported protocol that supports use of a zero UDP checksum, 4. A transported protocol that supports use of a zero UDP checksum,
MUST be designed so that corruption of this information does not MUST be designed so that corruption of this information does not
result in accumulated state for the protocol. result in accumulated state for the protocol.
5. A transported protocol that encapsulates a payload that is not 5. A transported protocol with a non-tunnel payload or one that
an IP packet flow MUST verify a CRC or other mechanism to check encapsulates non-IP packets MUST have a CRC or other mechanism
packet integrity, unless the payload is specifically designed for checking packet integrity, unless the non-IP packet is
for transmission over lower layers that do not provide a packet specifically designed for transmission over a lower layer that
integrity guarantee. does not provide a packet integrity guarantee.
6. A transported protocol with control feedback SHOULD be robust to 6. A transported protocol with control feedback SHOULD be robust to
changes in the network path, since the set of middleboxes on a changes in the network path, since the set of middleboxes on a
path may vary during the life of an association. Senders path may vary during the life of an association. The UDP
therefore need a method to discover paths with middleboxes that endpoints need to discover paths with middleboxes that drop
drop packets with a zero UDP checksum. Therefore keep-alive packets with a zero UDP checksum. Therefore, transported
messages SHOULD send datagrams with a zero UDP checksum. This protocols SHOULD send keep-alive messages with a zero UDP
will enable the remote endpoint to distinguish between a path checksum. An endpoint that discovers an appreciable loss rate
failure and dropping of datagrams with a zero UDP checksum. for keep-alive packets MAY terminate the UDP flow (e.g. tunnel).
Section 3.1.3 of RFC 5405 describes requirements for congestion
control when using a UDP-based transport.
7. A middlebox implementation MUST allow forwarding of IPv6 UDP 7. A protocol with control feedback that can fall-back to using UDP
with a calculated RFC 2460 checksum is expected to be more
robust to changes in the network path. Therefore, keep-alive
messages SHOULD include both UDP datagrams with a checksum and
datagrams with a zero UDP checksum. This will enable the remote
endpoint to distinguish between a path failure and dropping of
datagrams with a zero UDP checksum.
8. A middlebox implementation MUST allow forwarding of an IPv6 UDP
datagram with both a zero and standard UDP checksum using the datagram with both a zero and standard UDP checksum using the
same UDP port. same UDP port.
8. A middlebox MAY configure a restricted set of specific port 9. A middlebox MAY configure a restricted set of specific port
ranges that forward UDP datagrams with a zero UDP checksum. The ranges that forward UDP datagrams with a zero UDP checksum. The
middlebox MAY drop IPv6 datagrams with a zero UDP checksum that middlebox MAY drop IPv6 datagrams with a zero UDP checksum that
are outside a configured range. are outside a configured range.
9. When a middlebox forwards an IPv6 UDP flow containg datagrams 10. When a middlebox forwards an IPv6 UDP flow containing datagrams
with both a zero and standard UDP checksum, the middlebox MUST with both a zero and standard UDP checksum, the middlebox MUST
NOT maintain separate state for flows depending on the value of NOT maintain separate state for flows depending on the value of
their UDP checksum field. (This requirement is necessary to their UDP checksum field. (This requirement is necessary to
enable a sender that always calculates a checksum to communicate enable a sender that always calculates a checksum to communicate
via a middlebox with a remote endpoint that uses a zero UDP via a middlebox with a remote endpoint that uses a zero UDP
checksum.) checksum.)
10. Section 3.1.3 of RFC 5405 describes requirements for congestion
control for apllications using UDP.
6. Summary 6. Summary
This document examines the role of the UDP transport checksum when This document examines the role of the UDP transport checksum when
used with IPv6. It presents a summary of the trade-offs in used with IPv6. It presents a summary of the trade-offs in
evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint
to use a zero UDP checksum field to indicate that no checksum is to use a zero UDP checksum field to indicate that no checksum is
present. present.
The use of UDP with a zero UDP checksum has merits for some The use of UDP with a zero UDP checksum has merits for some
applications, such as tunnel encapsulation, and is widely used in applications, such as tunnel encapsulation, and is widely used in
skipping to change at page 36, line 46 skipping to change at page 37, line 7
* Interim Version * Interim Version
* Submission after IESG Feedback * Submission after IESG Feedback
* Updates to enable the document to become a PS Applicability * Updates to enable the document to become a PS Applicability
Statement Statement
Working Group Draft 08 Working Group Draft 08
* Submission for second WGLC as an Applicability Statement * First Version written as a PS Applicability Statement
* Submission after second WGLC * Changes to reflect decision to update RFC 2460, rather than
recommend decision
* Updates to requirements for middleboxes
* Inclusion of requirements for security, API, and tunnel
* Move of the rationale for the update to an Annex (former
section 4)
Working Group Draft 09
* Submission after second WGLC (note mistake corrected in -09).
* Clarified role of API for supporting full checksum. * Clarified role of API for supporting full checksum.
* Clarified that full checksum is required in security * Clarified that full checksum is required in security
considerations, and therefore noting that full checksum should considerations, and therefore noting that full checksum should
not be treated as an attack - consistent with remainder of not be treated as an attack - consistent with remainder of
document. document.
* Added mention that API can set a mode in transport stack - to * Added mention that API can set a mode in transport stack - to
link to similar statement in RFC 2460 update. link to similar statement in RFC 2460 update.
* Fixed typos. * Fixed typos.
Working Group Draft 08
* Submission to correct unwanted removal of text from section 5
bullets 5-7 by GF.
* Replaced section 5 text with the text from 08, and reapplied
the editorial correction.
* Note to reviewers: Please compare this revision with -08 used
in the IETF LC).
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Scotland, UK Scotland, UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry URI: http://www.erg.abdn.ac.uk/users/gorry
 End of changes. 20 change blocks. 
31 lines changed or deleted 61 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/