Subject: Some thoughts on draft-ietf-6man-udpchecksums-01

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 08 Nov 2011 18:07:02 +0000

Marshall, and others,

I've now read the new draft:
http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-01

This looks much more like what I expected, thanks.

I've got some concerns with the following para in Section 5:

       Whenever originating a UDP packet, an IPv6 node SHOULD compute a
                                                       ^^^^^^ - (1)
       UDP checksum over the packet and the pseudo-header, and, if that
       computation yields a result of zero, it must be changed to hex
       FFFF for placement in the UDP header.  IPv6 receivers SHOULD
                                                             ^^^^^^ - (1)
       discard UDP packets containing a zero checksum, and SHOULD log the
       error.  However, some protocols, such as lightweight tunneling
       protocols that use UDP as a tunnel encapsulation, MAY omit
       computing the UDP checksum of the encapsulating UDP header and set
       it to zero, subject to the constraints described in
       [I-D.ietf-6man-udpzero].  In cases where the encapsulating
       protocol uses a zero checksum for UDP, the receiver of packets
       sent to a port enabled to receive zero-checksum packets MUST NOT
                                                               ^^^^^^^^ (2)
       discard packets solely for having a UDP checksum of zero.  Note
       that these constraints apply only to encapsulating protocols that
       omit calculating the UDP checksum and set it to zero.  An
       encapsulating protocol can always choose to compute the UDP
       checksum, in which case, its behavior should be as specified
       originally.
       ^^^^^^^^^^ - (3)

(1), I think they MUST do this unless the receiver has been explicitly
enabled to process zero checksums for a particular port.

I think this sentence could be misleading, in that it can be quoted out 
of context easily, better to say MUST unless the update specified later 
is used. After all, the update proposed is

(2) I don't think this is a requirement you can easily place as an update
to RFC 2460.

(3) I think this means the method defined in RFC 2460.

In addition, I do think we should clearly recommend the use of checksums 
when there are not specific reasons for disabling them.

I also see one minor NiT:

- The abstract should mention RFC 2460 in words, but not cite it as a
reference.

---

I look forward to your thoughts on this,

best wishes,

Gorry