IPv6 and UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-08

[Ballot discuss]
You say that

"Any node implementing the zero-checksum
mode MUST follow the node requirements specified in Section 4 of
"Applicability Statement for the use of IPv6 UDP Datagrams with
Zero Checksums" [I-D.ietf-6man-udpzero]."

That reference points to text:

"IPv6 nodes supporting usage of zero UDP checksums MUST also
allow reception using a calculated UDP checksum on all ports
configured to allow zero UDP checksum usage.  (The sending
endpoint, e.g. encapsulating ingress, may choose to compute the
UDP checksum, or may calculate this by default.)  The receiving
endpoint MUST use the reception method specified in RFC2460 when
the checksum field is not zero."

Please clarify what you mean by "reception". Reception into the
control plane I am cool with, but reception into the tunnel forwarder
will send the packet on the slow path in most implementations
and will be showstopper in high performance tunnel applications.
This needs to be clarified and if you do mean into the forwarding
plane the issue needs to be noted.

[Ballot comment]
I welcome this advice
"An empirically-based analysis of the probabilities of packet
corruption (with or without checksums) has not (to our knowledge)
been conducted since about 2000.  At the time of publication, it
is now 2012.  We strongly suggest a new empirical study, along
with an extensive analysis of the corruption probabilities of the
IPv6 header."

However it should be noted that the cautions are provisional
pending completion of such a study, and that the caution text
should be revisited on completion of that study.

IANA has reviewed draft-ietf-6man-udpchecksums-06, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6 and UDP Checksums for Tunneled Packets) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'IPv6 and UDP Checksums for Tunneled Packets'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides an update of the Internet Protocol version 6
  (IPv6) specification (RFC2460) to improve the performance in the use
  case when a tunnel protocol uses UDP with IPv6 to tunnel packets.
  The performance improvement is obtained by relaxing the IPv6 UDP
  checksum requirement for suitable tunneling protocol where header
  information is protected on the "inner" packet being carried.  This
  relaxation removes the overhead associated with the computation of
  UDP checksums on IPv6 packets used to carry tunnel protocols.  The
  specification describes how the IPv6 UDP checksum requirement can be
  relaxed for the situation where the encapsulated packet itself
  contains a checksum.  The limitations and risks of this approach are
  described, and restrictions specified on the use of the method.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
Version -05, along with the corresponding changes to the udpzero-07 document, satisfy my concerns, and I'm happy to clear the DISCUSS and switch to YES.

Retaining for the record, here was the issue:

This was a combined DISCUSS on udpchecksums and udpzero.  I had no actual objection to publishing either of these documents.  What I' was concerned about is whether we're saying what we want to stay as a "standard".

The issue comes when I look at udpzero-06 Section 5.1 and udpchecksums-04 section 5.  The numbered list in the latter is essentially a word-for-word copy of the numbered list in the former, with the "must"s and "may"s and "should not"s changed to upper case.  It always bothers me when a significant amount of important text is duplicated like that, but the real problem comes when I look at what this *says*.

Because udpzero is informational, when it says, "If a zero checksum approach were to be adopted by the IETF, the specification should consider adding the following constraints on usage," that makes no normative requirement on any future protocol that runs on UDP and decides to bypass the UDP checksums.  Now, of course, we also have a document, udpchecksums, which defines what to do if you do tunneling on UDP and you want to skip the outer checksums (because you have inner ones).  *That* document makes this list normative.

But what happens if, later, someone decides to document how to do, let's say, media streaming over UDP with zero checksums.  The analysis in udpzero applies, of course, but the new document is under no obligation to consider it or any of those usage restrictions in Section 5.1.  (It might be that such a document could never get past the current community and ADs, but I'm not sure we want to leave that to chance.)

So the question comes to what we want to say normatively.  Which is it that we want a standard saying?

1. If you tunnel packets over UDP and want to avoid the UDP checksums, you need to use this list of restrictions.  But other applications over UDP that want to avoid the UDP checksums can make entirely different decisions.

or

2. If you do *anything* over UDP and want to avoid the UDP checksums, you need to use this list of restrictions.  And here's how tunneling over UDP works.

I think (2) is right, but the way the documents were structured said (1).

Discussion cleared, and thanks for working with me on this.

[Ballot comment]

- The DCCP-UDP tunnel draft [1] says you MUST have a non-zero
UDP checksum. Does that conflict with this or need to be called out
as an exception? (And if so, does anything else?)

  [1] http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/

- Ought 6man-udpzero be a normative reference? Seems odd to say
this "requires" that (top of p7) but for the referred thing to
be informative and an informational RFC. Is all the right text
in the right places?

- The secdir review [2] suggested calling more stuff out to
application developers, which seems worth considering.

  [2] http://www.ietf.org/mail-archive/web/secdir/current/msg03555.html

[Ballot comment]
No objection to the publication of this document, but I really would like to have the following requirement clarified.

2.  Implementations MUST provide a way to signal the set of ports
          that will be enabled to receive UDP datagrams with a zero
          checksum.

What is an implementation? The application running over the tunnel? You refer to "An encapsulating protocol" in the sentence before the bullet points, is this what you mean?
If yes, signal from where to whom?
Or maybe by "implementation" you mean "IPv6 protocol stack implementation"

[Ballot comment]

  Please consider the non-blocking comments from the Gen-ART Review by
  Peter Yee on 30-Sep-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07809.html

[Ballot discuss]
Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to get to yes on this draft also, since I support the liberalization of this protocol design when used for tunnelling. Specifically point 6 in this draft is relevant to this discussion.
Additionally a tunnel may not have any way of knowing if the payload is protected (as you suggest), since normally a tunnel has no knowledge of the payload characteristics.

In point 7 you suggest that an application cannot rely on packet length. When PWs are used for tunneling we rely on exactly that (except in the case of packets shorter than 64 octets for Ethenet padding reasons), and I am not aware of any reported issues. Thus when the application is tunnel encap/decap there is a body of evidence that suggests that this OK.

[Ballot comment]
There is some text in the earlier part of document that looks like it should be written in RFC2119 format. In this case it is not important because the normative change is later and this used RFC2119 directives, however the authors should consider making the document self consistent in this regard.

[Ballot discuss]
This is a combined DISCUSS on udpchecksums and udpzero.  First, let me say that I have no actual objection to publishing either of these documents.  What I'm concerned about is whether we're saying what we want to stay as a "standard", so let's discuss that:

The issue comes when I look at udpzero Section 5.1 and udpchecksums section 5.  The numbered list in the latter is essentially a word-for-word copy of the numbered list in the former, with the "must"s and "may"s and "should not"s changed to upper case.  It always bothers me when a significant amount of important text is duplicated like that, but the real problem comes when I look at what this *says*.

Because udpzero is informational, when it says, "If a zero checksum approach were to be adopted by the IETF, the specification should consider adding the following constraints on usage," that makes no normative requirement on any future protocol that runs on UDP and decides to bypass the UDP checksums.  Now, of course, we also have a document, udpchecksums, which defines what to do if you do tunneling on UDP and you want to skip the outer checksums (because you have inner ones).  *That* document makes this list normative.

But what happens if, later, someone decides to document how to do, let's say, media streaming over UDP with zero checksums.  The analysis in udpzero applies, of course, but the new document is under no obligation to consider it or any of those usage restrictions in Section 5.1.  (It might be that such a document could never get past the current community and ADs, but I'm not sure we want to leave that to chance.)

So the question comes to what we want to say normatively.  Which is it that we want a standard saying?

1. If you tunnel packets over UDP and want to avoid the UDP checksums, you need to use this list of restrictions.  But other applications over UDP that want to avoid the UDP checksums can make entirely different decisions.

or

2. If you do *anything* over UDP and want to avoid the UDP checksums, you need to use this list of restrictions.  And here's how tunneling over UDP works.

I think (2) is right, but the way the documents are structured now says (1).

Discussion, please....

IANA has reviewed draft-ietf-6man-udpchecksums-04, which is currently
in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (UDP Checksums for Tunneled Packets) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'UDP Checksums for Tunneled Packets'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides an update of the Internet Protocol version 6
  (IPv6) specification (RFC2460) to improve the performance of IPv6 in
  the use case when a tunnel protocol uses UDP with IPv6 to tunnel
  packets.  The performance improvement is obtained by relaxing the
  IPv6 UDP checksum requirement for suitable tunneling protocol where
  header information is protected on the "inner" packet being carried.
  This relaxation removes the overhead associated with the computation
  of UDP checksums on IPv6 packets used to carry tunnel protocols and
  thereby improves the efficiency of the traversal of firewalls and
  other network middleboxes by such protocols.  We describe how the
  IPv6 UDP checksum requirement can be relaxed in the situation where
  the encapsulated packet itself contains a checksum, the limitations
  and risks of this approach, and defines restrictions on the use of
  this relaxation to mitigate these risks.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/


No IPR declarations have been submitted directly on this I-D.