Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
Summary: Needs 5 more YES or NO OBJECTION positions to pass.
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
( spt ) No Objection
Comment (2013-01-22 for -10)
s2.2: Is there are reason that RFC 5097 isn't an informative reference?