draft-ietf-6man-udpzero-04.txt   draft-ietf-6man-udpzero-05.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: Informational M. Westerlund Intended status: Informational M. Westerlund
Expires: April 27, 2012 Ericsson Expires: June 25, 2012 Ericsson
October 25, 2011 December 23, 2011
IPv6 UDP Checksum Considerations IPv6 UDP Checksum Considerations
draft-ietf-6man-udpzero-04 draft-ietf-6man-udpzero-05
Abstract Abstract
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, as defined in RFC2460. It presents a summary of the used with IPv6, as defined in RFC2460. It presents a summary of the
trade-offs for evaluating the safety of updating RFC 2460 to permit trade-offs for evaluating the safety of updating RFC 2460 to permit
an IPv6 UDP endpoint to use a zero value in the checksum field as an an IPv6 UDP endpoint to use a zero value in the checksum field as an
indication that no checksum is present. This method is compared with indication that no checksum is present. This method is compared with
some other possibilities. The document also describes the issues and some other possibilities. The document also describes the issues and
design principles that need to be considered when UDP is used with design principles that need to be considered when UDP is used with
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 April 27, 2012. This Internet-Draft will expire on June 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 4 skipping to change at page 3, line 4
checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Alternatives to the Standard Checksum . . . . . . . . . . 20 4.1. Alternatives to the Standard Checksum . . . . . . . . . . 20
4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 22 4.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 22
4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 23 4.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 23
4.2.3. Ingress and Egress Performance Implications . . . . . 23 4.2.3. Ingress and Egress Performance Implications . . . . . 23
4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 23 4.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 23
4.2.5. Corruption Detection Strength . . . . . . . . . . . . 24 4.2.5. Corruption Detection Strength . . . . . . . . . . . . 24
4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 24 4.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 24
5. Requirements on the specification of transported protocols . . 26 5. Requirements on the specification of transported protocols . . 26
5.1. Constraints required on usage of a zero checksum . . . . . 26 5.1. Constraints required on usage of a zero checksum . . . . . 27
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Document Change History . . . . . . . . . . . . . . . 32 Appendix A. Document Change History . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
skipping to change at page 5, line 15 skipping to change at page 5, line 15
Section 2 describes a set of standards-track datagram transport Section 2 describes a set of standards-track datagram transport
protocols that may be used to support tunnels. protocols that may be used to support tunnels.
Section 3 discusses issues with a zero checksum in UDP for IPv6. It Section 3 discusses issues with a zero checksum in UDP for IPv6. It
considers the impact of corruption, the need for validation of the considers the impact of corruption, the need for validation of the
path and when it is suitable to use a zero checksum. path and when it is suitable to use a zero checksum.
Section 4 evaluates a set of proposals to update the UDP transport Section 4 evaluates a set of proposals to update the UDP transport
behaviour and other alternatives intended to improve support for behaviour and other alternatives intended to improve support for
tunnel protocols. It focuses on a proposal to allow a zero checksum tunnel protocols. It focuses on a proposal to allow a zero checksum
for this use-case with IPv6 and assess the trade-offs that would for this use-case with IPv6 and assesses the trade-offs that would
arise. arise.
Section 5.1 lists the constraints perceived for safe deployment of Section 5.1 lists the constraints perceived for safe deployment of
zero-checksum. zero-checksum.
Section 6 provides the recommendations for standardization of zero- Section 6 provides the recommendations for standardization of zero-
checksum with a summary of the findings and notes remaining issues checksum with a summary of the findings and notes remaining issues
needing future work. needing future work.
1.2. Background 1.2. Background
skipping to change at page 6, line 14 skipping to change at page 6, line 14
UDP datagram payload. The UDP header includes a 16-bit one's UDP datagram payload. The UDP header includes a 16-bit one's
complement checksum that provides a statistical guarantee that the complement checksum that provides a statistical guarantee that the
payload was not corrupted in transit. This also allows a receiver to payload was not corrupted in transit. This also allows a receiver to
verify that the endpoint was the intended destination of the verify that the endpoint was the intended destination of the
datagram, because the transport pseudo header covers the IP datagram, because the transport pseudo header covers the IP
addresses, port numbers, transport payload length, and Next Header/ addresses, port numbers, transport payload length, and Next Header/
Protocol value corresponding to the UDP transport protocol [RFC1071]. Protocol value corresponding to the UDP transport protocol [RFC1071].
The length field verifies that the datagram is not truncated or The length field verifies that the datagram is not truncated or
padded. The checksum therefore protects an application against padded. The checksum therefore protects an application against
receiving corrupted payload data in place of, or in addition to, the receiving corrupted payload data in place of, or in addition to, the
data that was sent. Although the IPv4 UDP [RFC0768] checksum may be data that were sent. Although the IPv4 UDP [RFC0768] checksum may be
disabled, applications are recommended to enable UDP checksums disabled, applications are recommended to enable UDP checksums
[RFC5405]. [RFC5405].
The network-layer fields that are validated by a transport checksum The network-layer fields that are validated by a transport checksum
are: are:
o Endpoint IP source address (always included in the pseudo header o Endpoint IP source address (always included in the pseudo header
of the checksum) of the checksum)
o Endpoint IP destination address (always included in the pseudo o Endpoint IP destination address (always included in the pseudo
skipping to change at page 8, line 38 skipping to change at page 8, line 38
Address Translators, NATs. Address Translators, NATs.
o A desire to use the port number space to enable load-sharing. o A desire to use the port number space to enable load-sharing.
1.3.2. Reducing forwarding cost 1.3.2. Reducing forwarding cost
It is a common requirement to terminate a large number of tunnels on It is a common requirement to terminate a large number of tunnels on
a single router/host. Processing per tunnel concerns both state a single router/host. Processing per tunnel concerns both state
(memory requirements) and per-packet processing costs. (memory requirements) and per-packet processing costs.
Automatic IP Multicast Without Explicit Tunnels, known as AMT Automatic IP Multicast Tunneling, known as AMT
[I-D.ietf-mboned-auto-multicast] currently specifies UDP as the [I-D.ietf-mboned-auto-multicast] currently specifies UDP as the
transport protocol for packets carrying tunneled IP multicast transport protocol for packets carrying tunneled IP multicast
packets. The current specification for AMT requires that the UDP packets. The current specification for AMT requires that the UDP
checksum in the outer packet header should be 0 (see Section 6.6 of checksum in the outer packet header should be 0 (see Section 6.6 of
[I-D.ietf-mboned-auto-multicast]). It argues that the computation of [I-D.ietf-mboned-auto-multicast]). It argues that the computation of
an additional checksum, when an inner packet is already adequately an additional checksum, when an inner packet is already adequately
protected, is an unwarranted burden on nodes implementing lightweight protected, is an unwarranted burden on nodes implementing lightweight
tunneling protocols. The AMT protocol needs to replicate a multicast tunneling protocols. The AMT protocol needs to replicate a multicast
packet to each gateway tunnel. In this case, the outer IP addresses packet to each gateway tunnel. In this case, the outer IP addresses
are different for each tunnel and therefore require a different are different for each tunnel and therefore require a different
skipping to change at page 9, line 39 skipping to change at page 9, line 39
UDP support is commonly provided. It is also necessary due to the UDP support is commonly provided. It is also necessary due to the
almost ubiquitous deployment of IPv4 NATs. There has also been almost ubiquitous deployment of IPv4 NATs. There has also been
discussion of NAT for IPv6, although not for the same reason as in discussion of NAT for IPv6, although not for the same reason as in
IPv4. If IPv6 NAT becomes a reality they hopefully do not present IPv4. If IPv6 NAT becomes a reality they hopefully do not present
the same protocol issues as for IPv4. If NAT is defined for IPv6, it the same protocol issues as for IPv4. If NAT is defined for IPv6, it
should take UDP zero checksum into consideration. should take UDP zero checksum into consideration.
The requirements for IPv6 firewall traversal are likely be to be The requirements for IPv6 firewall traversal are likely be to be
similar to those for IPv4. In addition, it can be reasonably similar to those for IPv4. In addition, it can be reasonably
expected that a firewall conforming to RFC 2460 will not regard UDP expected that a firewall conforming to RFC 2460 will not regard UDP
datagrams with a zero checksum as valid packets. If an zero-checksum datagrams with a zero checksum as valid packets. If a zero-checksum
for UDP were to be allowed for IPv6, this would need firewalls to be for UDP were to be allowed for IPv6, this would need firewalls to be
updated before full utility of the change is available. updated before full utility of the change is available.
It can be expected that UDP with zero-checksum will initially not It can be expected that UDP with zero-checksum will initially not
have the same middlebox traversal characteristics as regular UDP. have the same middlebox traversal characteristics as regular UDP.
However, if standardized we can expect an improvement over time of However, if standardized we can expect an improvement over time of
the traversal capabilities. We also note that deployment of IPv6- the traversal capabilities. We also note that deployment of IPv6-
capable middleboxes is still in its initial phases. Thus, it might capable middleboxes is still in its initial phases. Thus, it might
be that the number of non-updated boxes quickly become a very small be that the number of non-updated boxes quickly become a very small
percentage of the deployed middleboxes. percentage of the deployed middleboxes.
skipping to change at page 10, line 50 skipping to change at page 10, line 50
The IETF has defined a set of transport protocols that may be The IETF has defined a set of transport protocols that may be
applicable for tunnels with IPv6. There are also a set of network applicable for tunnels with IPv6. There are also a set of network
layer encapsulation tunnels such as IP-in-IP and GRE. These already layer encapsulation tunnels such as IP-in-IP and GRE. These already
standardized solutions are discussed here prior to the issues, as standardized solutions are discussed here prior to the issues, as
background for the issue description and some comparison of where the background for the issue description and some comparison of where the
issue may already occur. issue may already occur.
2.1. UDP with Standard Checksum 2.1. UDP with Standard Checksum
UDP [RFC0768] with standard checksum behaviour is defined in RFC 2460 UDP [RFC0768] with standard checksum behaviour, as defined in RFC
has already been discussed. UDP usage guidelines are provided in 2460, has already been discussed. UDP usage guidelines are provided
in [RFC5405].
[RFC5405].
2.2. UDP-Lite 2.2. UDP-Lite
UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as UDP-Lite [RFC3828] offers an alternate transport to UDP, specified as
a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and a proposed standard, RFC 3828. A MIB is defined in RFC 5097 and
unicast usage guidelines in [RFC5405]. There is at least one open unicast usage guidelines in [RFC5405]. There is at least one open
source implementation as a part of the Linux kernel since version source implementation as a part of the Linux kernel since version
2.6.20. 2.6.20.
UDP-Lite provides a checksum with optional partial coverage. When UDP-Lite provides a checksum with optional partial coverage. When
skipping to change at page 11, line 35 skipping to change at page 11, line 34
cover the insensitive part with the same strong layer 2 frame CRC cover the insensitive part with the same strong layer 2 frame CRC
that covers the sensitive part. that covers the sensitive part.
2.2.1. Using UDP-Lite as a Tunnel Encapsulation 2.2.1. Using UDP-Lite as a Tunnel Encapsulation
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/middelbox to header checksum, in IPv6, without the need for a router/middelbox to
traverse the entire packet payload. This provides most of the traverse the entire packet payload. This provides most of the
delivery verifications and still keep the complexity of the delivery verifications and still keeps the complexity of the
checksumming operation low. UDP-Lite may set the length of checksum checksumming operation low. UDP-Lite may set the length of checksum
coverage on a per packet basis. This feature could be used if a coverage on a per packet basis. This feature could be used if a
tunnel protocol is designed to only verify delivery of the tunneled tunnel protocol is designed to only verify delivery of the tunneled
payload and uses full checksumming for control information. payload and uses full checksumming for control 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.
2.3. General Tunnel Encapsulations 2.3. General Tunnel Encapsulations
The IETF has defined a set of tunneling protocols or network layer The IETF has defined a set of tunneling protocols or network layer
encapsulations, like IP-in-IP and GRE. These either do not include a encapsulations, e.g., IP-in-IP and GRE. These either do not include
checksum or use a checksum that is optional, since tunnel a checksum or use a checksum that is optional, since tunnel
encapsulations are typically layered directly over the Internet layer encapsulations are typically layered directly over the Internet layer
(identified by the upper layer type in the IPv6 Next Header field) (identified by the upper layer type in the IPv6 Next Header field)
and are also not used as endpoint transport protocols. There is and are also not used as endpoint transport protocols. There is
little chance of confusing a tunnel-encapsulated packet with other little chance of confusing a tunnel-encapsulated packet with other
application data that could result in corruption of application state application data that could result in corruption of application state
or data. or data.
From the end-to-end perspective, the principal difference is that the From the end-to-end perspective, the principal difference is that the
network-layer Next Header field identifies a separate transport, network-layer Next Header field identifies a separate transport,
which reduces the probability that corruption could result in the which reduces the probability that corruption could result in the
skipping to change at page 12, line 33 skipping to change at page 12, line 33
This section evaluates issues around the proposal to update IPv6 This section evaluates issues around the proposal to update IPv6
[RFC2460], to provide the option of using a UDP transport checksum [RFC2460], to provide the option of using a UDP transport checksum
set to zero. Some of the identified issues are shared with other set to zero. Some of the identified issues are shared with other
protocols already in use. protocols already in use.
The decision by IPv6 to omit an integrity check at the network level The decision by IPv6 to omit an integrity check at the network level
has meant that the transport check was overloaded with many has meant that the transport check was overloaded with many
functions, including validating: functions, including validating:
o the endpoint address was not corrupted within a router - i.e. A o the endpoint address was not corrupted within a router, i.e., a
packet was intended to be received by this destination and a wrong packet was intended to be received by this destination and
header has not been spliced to a different payload; validate that the packet does not consist of a wrong header
spliced to a different payload;
o that extension header processing is correctly delimited - i.e. o that extension header processing is correctly delimited - i.e.,
The start of data has not been corrupted. In this case, reception the start of data has not been corrupted. In this case, reception
of a valid next header value provides some protection; of a valid next header value provides some protection;
o reassembly processing, when used; o reassembly processing, when used;
o the length of the payload; o the length of the payload;
o the port values - i.e. The correct application receives the o the port values - i.e., the correct application receives the
payload (applications should also check the expected use of source payload (applications should also check the expected use of source
ports/addresses); ports/addresses);
o the payload integrity. o the payload integrity.
In IPv4, the first four checks are performed using the IPv4 header In IPv4, the first four checks are performed using the IPv4 header
checksum. checksum.
In IPv6, these checks occur within the endpoint stack using the UDP In IPv6, these checks occur within the endpoint stack using the UDP
checksum information. An IPv6 node also relies on the header checksum information. An IPv6 node also relies on the header
skipping to change at page 16, line 51 skipping to change at page 16, line 51
A protocol using UDP zero-checksum can never assume that it is the A protocol using UDP zero-checksum can never assume that it is the
only protocol using a zero checksum. Therefore, it needs to only protocol using a zero checksum. Therefore, it needs to
gracefully handle misdelivery. It must be robust to reception of gracefully handle misdelivery. It must be robust to reception of
malformed packets received on a listening port and expect that these malformed packets received on a listening port and expect that these
packets may contain corrupted data or data associated with a packets may contain corrupted data or data associated with a
completely different protocol. completely different protocol.
3.1.5. Corruption of Fragmentation Information 3.1.5. Corruption of Fragmentation Information
The fragmentation information in IPv6 employs a 32-bit identity The fragmentation information in IPv6 employs a 32-bit identity
field, compared to only a 16-bit filed in IPv4, a 13-bit fragment field, compared to only a 16-bit field in IPv4, a 13-bit fragment
offset and a 1-bit flag, indicating if there are more fragments. offset and a 1-bit flag, indicating if there are more fragments.
Corruption of any of these field may result in one of two outcomes: Corruption of any of these field may result in one of two outcomes:
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
skipping to change at page 18, line 38 skipping to change at page 18, line 38
outer fragmentation. outer fragmentation.
o A tunnel that performs outer fragmentation can result in a higher o A tunnel that performs outer fragmentation can result in a higher
level of corruption due to both inner and outer fragmentation, level of corruption due to both inner and outer fragmentation,
enabling more chances for reassembly errors to occur. enabling more chances for reassembly errors to occur.
o Recursive tunneling can result in fragmentation at more than one o Recursive tunneling can result in fragmentation at more than one
header level, even for inner fragmentation unless it goes to the header level, even for inner fragmentation unless it goes to the
inner most IP header. inner most IP header.
o Unless there is verification at each reassembly the probability o Unless there is verification at each reassembly, the probability
for undetected error will increase with the number of times for undetected error will increase with the number of times
fragmentation is recursively applied. Making IP-in-IP and UDP fragmentation is recursively applied, making IP-in-IP and UDP with
with zero checksum equal subject to this effect. zero checksum both vulnberable to undetected errors.
In conclusion fragmentation of packets with a zero-checksum does not In conclusion fragmentation of packets with a zero-checksum does not
worsen the situation compared to some other commonly used tunnel worsen the situation compared to some other commonly used tunnel
encapsulations. However, caution is needed for recursive tunneling encapsulations. However, caution is needed for recursive tunneling
without any additional verification at the different tunnel layers. without any additional verification at the different tunnel layers.
3.2. Validating the network path 3.2. Validating the network path
IP transports designed for use in the general Internet should not IP transports designed for use in the general Internet should not
assume specific path characteristics. Network protocols may reroute assume specific path characteristics. Network protocols may reroute
skipping to change at page 26, line 44 skipping to change at page 26, line 44
o Do we accept the complexity cost of having one more solution in o Do we accept the complexity cost of having one more solution in
the future? the future?
The authors do think the answer to the above questions are such that The authors do think the answer to the above questions are such that
zero-checksum should be standardized for use by tunnel zero-checksum should be standardized for use by tunnel
encapsulations. encapsulations.
5. Requirements on the specification of transported protocols 5. Requirements on the specification of transported protocols
This section identifies requirements for the protocols that are
transported over a transport connection that does not perform a UDP
checksum calculation to verify the integrity at the transport
endpoints.
5.1. Constraints required on usage of a zero checksum 5.1. Constraints required on usage of a zero checksum
If a zero checksum approach were to be adopted by the IETF, the If a zero checksum approach were to be adopted by the IETF, the
specification should consider adding the following constraints on specification should consider adding the following constraints on
usage: usage:
1. IPv6 protocol stack implementations should not by default allow 1. IPv6 protocol stack implementations should not by default allow
the new method. The default node receiver behaviour must discard the new method. The default node receiver behaviour must discard
all IPv6 packets carrying UDP packets with a zero checksum. all IPv6 packets carrying UDP packets with a zero checksum.
skipping to change at page 28, line 17 skipping to change at page 28, line 23
9. IPv6 nodes that receive ICMPv6 messages that refer to packets 9. IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero UDP checksum must provide appropriate checks with a zero UDP checksum must provide appropriate checks
concerning the consistency of the reported packet to verify that concerning the consistency of the reported packet to verify that
the reported packet actually originated from the node, before the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and port acting upon the information (e.g. validating the address and port
numbers in the ICMPv6 message body). numbers in the ICMPv6 message body).
Deployment of the new method needs to remain restricted to endpoints Deployment of the new method needs to remain restricted to endpoints
that explicitly enable this mode and adopt the above procedures. Any that explicitly enable this mode and adopt the above procedures. Any
middlebox that examines or interact with the UDP header over IPv6 middlebox that examines or interacts with the UDP header over IPv6
should support the new method. should support the new method.
6. Summary 6. Summary
This document examines the role of the transport checksum when used This document examines the role of the transport checksum when used
with IPv6, as defined in RFC2460. with IPv6, as defined in RFC2460.
It presents a summary of the trade-offs for evaluating the safety of It presents a summary of the trade-offs for evaluating the safety of
updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value
in the checksum field to indicate that no checksum is present. A in the checksum field to indicate that no checksum is present. A
decision not to include a UDP checksum in received IPv6 datagrams decision not to include a UDP checksum in received IPv6 datagrams
could impact a tunnel application that receives these packets. could impact a tunnel application that receives these packets.
However, a well-designed tunnel application should include However, a well-designed tunnel application should include
consistency checks to validate any header information encapsulated consistency checks to validate any header information encapsulated
with a packet. In most cases tunnels encapsulating IP packets can with a packet. In most cases tunnels encapsulating IP packets can
rely on the inner packets own integrity protection. When correctly rely on the inner packets own integrity protection. When correctly
implemented, such a tunnel endpoint will not be negatively impacted implemented, such a tunnel endpoint will not be negatively impacted
by omission of the transport-layer checksum. Recursive tunneling and by omission of the transport-layer checksum. Recursive tunneling and
fragmentation is a potential issues that can raise corruption rates fragmentation is a potential issue that can raise corruption rates
significantly, and requires careful consideration. significantly, and requires careful consideration.
Other applications at the intended destination node or another IPv6 Other applications at the intended destination node or another IPv6
node can be impacted if they are allowed to receive datagrams without node can be impacted if they are allowed to receive datagrams without
a transport-layer checksum. It is particularly important that a transport-layer checksum. It is particularly important that
already deployed applications are not impacted by any change at the already deployed applications are not impacted by any change at the
transport layer. If these applications execute on nodes that transport layer. If these applications execute on nodes that
implement RFC 2460, they will reject all datagrams with a zero UDP implement RFC 2460, they will reject all datagrams with a zero UDP
checksum, thus this is not an issue. For nodes that implement checksum, thus this is not an issue. For nodes that implement
support for zero-checksum it is important to ensure that only UDP support for zero-checksum it is important to ensure that only UDP
skipping to change at page 29, line 17 skipping to change at page 29, line 23
datagrams in the same way that they handle IPv4 UDP datagrams. This datagrams in the same way that they handle IPv4 UDP datagrams. This
possibly reduces the need to update the checksum. Firewalls are possibly reduces the need to update the checksum. Firewalls are
intended to be configured, and therefore may need to be explicitly intended to be configured, and therefore may need to be explicitly
updated to allow new services or protocols. IPv6 middlebox updated to allow new services or protocols. IPv6 middlebox
deployment is not yet as prolific as it is in IPv4. Thus, relatively deployment is not yet as prolific as it is in IPv4. Thus, relatively
few current middleboxes may actually block IPv6 UDP with a zero few current middleboxes may actually block IPv6 UDP with a zero
checksum. checksum.
In general, UDP-based applications need to employ a mechanism that In general, UDP-based applications need to employ a mechanism that
allows a large percentage of the corrupted packets to be removed allows a large percentage of the corrupted packets to be removed
before they reach an application, both to protect the applications before they reach an application, both to protect the data stream of
data stream and the control plane of higher layer protocols. These the application and the control plane of higher layer protocols.
checks are currently performed by the UDP checksum for IPv6, or the These checks are currently performed by the UDP checksum for IPv6, or
reduced checksum for UDP-Lite when used with IPv6. the reduced checksum for UDP-Lite when used with IPv6.
The use of UDP with no checksum has merits for some applications, The use of UDP with no checksum has merits for some applications,
such as tunnel encapsulation, and is widely used in IPv4. However, such as tunnel encapsulation, and is widely used in IPv4. However,
there are dangers for IPv6: There is a bigger risk of corruption and there are dangers for IPv6: There is a bigger risk of corruption and
miss-delivery when using zero-checksum in IPv6 compared to IPv4 due miss-delivery when using zero-checksum in IPv6 compared to IPv4 due
to the removed IP header checksum. Thus, applications needs to make to the removed IP header checksum. Thus, applications need to make a
a new evaluation of the risks of enabling a zero-checksum. Some new evaluation of the risks of enabling a zero-checksum. Some
applications will need to re-consider their usage of zero-checksum, applications will need to re-consider their usage of zero-checksum,
and possibly consider a solution that at least provides the same and possibly consider a solution that at least provides the same
delivery protection as for IPv4, for example by utilizing UDP-Lite, delivery protection as for IPv4, for example by utilizing UDP-Lite,
or by enabling the UDP checksum. Tunnel applications using UDP for or by enabling the UDP checksum. Tunnel applications using UDP for
encapsulation can in many case use zero-checksum without significant encapsulation can in many case use zero-checksum without significant
impact on the corruption rate. In some cases, the use of checksum impact on the corruption rate. In some cases, the use of checksum
off-loading may help alleviate the checksum processing cost. off-loading may help alleviate the checksum processing cost.
Recursive tunneling and fragmentation is a difficult issue relating Recursive tunneling and fragmentation is a difficult issue relating
to tunnels in general. There is an increased risk of an error in the to tunnels in general. There is an increased risk of an error in the
skipping to change at page 30, line 44 skipping to change at page 31, line 6
[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.
10.2. Informative References 10.2. Informative References
[ECMP] "Using the IPv6 flow label for equal cost multipath [ECMP] "Using the IPv6 flow label for equal cost multipath
routing in tunnels (draft-carpenter-flow-ecmp)". routing in tunnels (draft-carpenter-flow-ecmp)".
[I-D.ietf-6man-udpchecksums] [I-D.ietf-6man-udpchecksums]
Eubanks, M., "UDP Checksums for Tunneled Packets", Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
draft-ietf-6man-udpchecksums-00 (work in progress), Packets", draft-ietf-6man-udpchecksums-01 (work in
March 2011. progress), October 2011.
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "Tunnels in the Internet Touch, J. and M. Townsley, "Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-00 (work in Architecture", draft-ietf-intarea-tunnels-00 (work in
progress), March 2010. progress), March 2010.
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L.,
Pusateri, T., and T. Morin, "Automatic IP Multicast Pusateri, T., and T. Morin, "Automatic IP Multicast
Tunneling", draft-ietf-mboned-auto-multicast-11 (work in Tunneling", draft-ietf-mboned-auto-multicast-11 (work in
skipping to change at page 33, line 32 skipping to change at page 33, line 38
intent of this draft. intent of this draft.
Working Group Draft 03 Working Group Draft 03
* Editorial updates * Editorial updates
Working Group Draft 04 Working Group Draft 04
* Resubmission only updating the AMT and RFC2765 references. * Resubmission only updating the AMT and RFC2765 references.
Working Group Draft 05
* Resubmission to correct editorial NiTs - thanks to Bill Atwood
for noting these.
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
Phone: Phone:
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
 End of changes. 25 change blocks. 
38 lines changed or deleted 48 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/