datatracker.ietf.org
Sign in
Version 5.7.1.p2, 2014-10-29
Report a bug

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

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

Summary: Needs 3 more YES or NO OBJECTION positions to pass.

Adrian Farrel

Comment (2013-01-21 for -10)

Thank you for this new revision and for addressing my Comments on -06

Barry Leiba

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.

Benoit Claise

Comment (2013-01-24 for -10)

Thanks for addressing my comments

Pete Resnick

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.

[Ralph Droms]

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?

[Ron Bonica]

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?

[Sean Turner]

Comment (2013-01-22 for -10)

s2.2: Is there are reason that RFC 5097 isn't an informative reference?

[Stewart Bryant]

Comment (2013-02-21 for -11)

Thank you for addressing my concerns WRT the behavior of routers.