IPv6 and UDP Checksums for Tunneled Packets
RFC 6935

Note: This ballot was opened for revision 04 and is now closed.

(Ron Bonica) (was Discuss) Yes

(Brian Haberman) Yes

Barry Leiba (was Discuss) Yes

Comment (2012-10-22 for -05)
No email
send info
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.


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.

(Stewart Bryant) (was Discuss) No Objection

Comment (2013-02-21)
No email
send info
Thank you for addressing my concerns

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-10-09 for -04)
No email
send info
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

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"

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-10-11 for -04)
No email
send info
- 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

(Russ Housley) No Objection

Comment (2012-10-08 for -04)
No email
send info
  Please consider the non-blocking comments from the Gen-ART Review by
  Peter Yee on 30-Sep-2012.  You can find the review here:

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection