Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums

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

(Ron Bonica) (was Discuss) Yes

Comment (2012-10-12 for -06)
Would you be willing to add a short section in an Appendix that illustrates the kind of analysis that you are requiring of a protocol that wants to rely on UDPZero? I am thinking of something like the following:

 Sample Text
 Protocol Foo encapsulates an IP datagram within the following:

 - a foo header
 - a UDP header
 - an outer IPv6 header

 Because the UDP checksum is set to zero, the following fields are unprotected:

 - foo header: field1
 - foo header: field2
 - UDP header: source port
 - UDP header: destination port
 - outer IPv6 header: source address
 - outer IPv6 header: destination  address

The consequence of corruption in field1 of the foo header is mumble. The consequence of corruption in field2 of the foo header is grumble, but only if some other condition is true. The consequence of corruption in any other field is, at worst, loss of the packet.

Assume a tunnel with the following characteristics:

 - sustained data rate of 1 Gbps
 - Bit error rate of 10**-12 on each of 4 constituent links
 - average packet size equal to 1500 bytes

The bullet list, below, provides an estimate of the frequency with which each of the above mentioned fields will be corrupted:

 - foo header: field1 (once per N seconds)
 - foo header: field2 (once per N seconds)
 - UDP header: source port (once per N seconds)
 - UDP header: destination port (once per N seconds)
 - outer IPv6 header: source address (once per N seconds)
 - outer IPv6 header: destination  address (once per N seconds)

 End sample text

Does this sound reasonable?

(Brian Haberman) Yes

(Barry Leiba) (was Discuss) Yes

Comment (2012-10-22 for -07)
Version -07, along with the corresponding changes to the udpchecksums-05 document, satisfy my concerns, and I'm happy to clear the DISCUSS and switch to YES.

(Stewart Bryant) (was Discuss) No Objection

Comment (2013-02-21 for -11)
Thank you for addressing my concerns WRT the behavior of routers.

(Gonzalo Camarillo) No Objection

Benoit Claise No Objection

Comment (2013-01-24 for -10)
Thanks for addressing my comments

(Ralph Droms) No Objection

Comment (2012-10-09 for -06)
In section 4.1, is there a reference to the "proposal to simply ignore
the UDP checksum value on reception at the tunnel egress" that can be
cited to give more background?

In section 4.2.1, "The methods that ignores the checksum has an
additional downside" needs to be plural or singular throughout.

The first paragraph of section 5 tells me it identifies requirements
for protocols carried without UDP checksum.  Section 5.1 talks only
about "zero checksum"; does the proposal to ignore the checksum at the
tunnel egress also fit here?  Also, stylistically, I think the section
header for 5.1 can simply be dropped.

In section 5.1, I can't parse out what list item 5 is trying to
convey.  What is the "tunnel layer" and is it always recommended and
required for some tunnel mechanisms?

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2013-01-21 for -10)
Thank you for this new revision and for addressing my Comments on -06

Stephen Farrell No Objection

(Russ Housley) No Objection

(Pete Resnick) (was Discuss) No Objection

Comment (2013-02-22 for -11)
My complaint with this document was that it needed to justify why we need a new zero-checksum mechanism for IPv6 UDP, in particular why it is any better than UDP-Lite. Two changes were made in version -11:

Section 1.3.1 adds:

      However, use of the zero UDP checksum
      does not fully fulfill this need, because only certain classes of
      middleboxes, (i.e. ones that do not modify or evaluate the UDP
      checksum) will support zero UDP checksum traffic, other
      middleboxes will require an update to support this traffic.

That makes things worse. It says that this mechanism won't work in many middleboxes. If it won't work, why should we do it?
It is not until the new section 2.4, buried in the 5th paragraph, that the document finally makes a justification:

   Many existing classes
   of middleboxes do not verify or change the transport checksum.  For
   these middleboxes, IPv6 with a zero UDP checksum is expected to
   function where UDP-Lite would not.

That's the only justification in the document. I really think you should make two changes still:

1. Move the text you inserted into 1.3.1 into section 3. It is an "anti"-motivation, not a motivation for this work.
2. Add to (or rewrite) section 1.3.4 to say that there *are* many existing classes of middleboxes that will work with a zero UDP checksum that won't work with other mechanisms (e.g., other tunneling protocols and UDP-Lite). Right now, 1.3.4 says that the new mechanism won't work with existing middleboxes. Again, that tells me to *not* do this work.

Personally, I'd really like you to call out why this thing is at all useful much earlier in the document. The current text is completely ambivalent on whether this thing is a useful mechanism at all.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-01-22 for -10)
s2.2: Is there are reason that RFC 5097 isn't an informative reference?