Skip to main content

Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
draft-ietf-6man-udpzero-12

Yes

(Brian Haberman)

No Objection

(Gonzalo Camarillo)
(Martin Stiemerling)
(Robert Sparks)
(Russ Housley)
(Stephen Farrell)
(Wesley Eddy)

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

Barry Leiba Former IESG member
(was Discuss) Yes
Yes (2012-10-22 for -07) Unknown
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.
Brian Haberman Former IESG member
Yes
Yes (for -06) Unknown

                            
Ron Bonica Former IESG member
(was Discuss) Yes
Yes (2012-10-12 for -06) Unknown
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?
Adrian Farrel Former IESG member
No Objection
No Objection (2013-01-21 for -10) Unknown
Thank you for this new revision and for addressing my Comments on -06
Benoît Claise Former IESG member
No Objection
No Objection (2013-01-24 for -10) Unknown
Thanks for addressing my comments
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection (2013-02-22 for -11) Unknown
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.
Ralph Droms Former IESG member
No Objection
No Objection (2012-10-09 for -06) Unknown
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?
Robert Sparks Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-01-22 for -10) Unknown
s2.2: Is there are reason that RFC 5097 isn't an informative reference?
Stephen Farrell Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2013-02-21 for -11) Unknown
Thank you for addressing my concerns WRT the behavior of routers.
Wesley Eddy Former IESG member
No Objection
No Objection (for -06) Unknown