Comments on draft-ietf-6man-udpchecksums-00

[Magnus Westerlund <[e-mail]>]

Hi,

I have made a review of the draft and have some comments on it.

1. Needs to indicate that it updates RFC2460 (when approved). This
usually goes into the header of the front page. The abstract and as part
of the introduction.

2. The abstract is way to meager. It needs to make clear, what it does,
that there are limitations and that it updates RFC 2460.

3. Style of writing. This is a document that updates and will be the
specification of a change of the IPv6 specification. Currently it still
reads like a change proposal. From my perspective it needs to be more
authoritative. This is something we have decided to do. Thus the
document should be written like:
1. Introduction: We are changing the UDP zero checksum rule in IPv6.
2. Short motivation why.
3. Change to specification. Old text that is replaced. New text.

Some places where this is evident:
- Section 1, last paragraph on page 3: Not long term relevant and using
terms that make less sense in an RFC.
- Section 1.4 "Recommend Solution": Wrong title. Should be its own main
section. First paragraph.

4. Section 1.4:
      In cases, where the encapsulating
      protocol uses a zero checksum for UDP, the receiver of packets in
      the allowed port range MUST NOT discard packets with a UDP
      checksum of zero.

"in the allowed port range" seems wrong, isn't "to a port that has been
enabled to receive zero checksum" so that the full sentence reads:

In cases, where the encapsulating protocol uses a zero checksum for UDP,
the receiver of packets to a port that has been enabled to receive zero
checksum MUST NOT discard packets with a UDP checksum of zero.

5. Section 1.4 bullet 1:
      1.  IPv6 protocol stack implementations SHOULD NOT by default
          allow the new method.  The default node receiver behaviour
          MUST discard all IPv6 packets carrying UDP packets with a zero
          checksum.

I think "new method" is unclear in this sentence. Yes, I know it is from
my draft. However, in the context of actually doing the change it needs
to be more crisp and clear.

6. Section 1.4, bullet 3:
      3.  RFC 2460 specifies that IPv6 nodes should log UDP datagrams
          with a zero-checksum.  This should remain the case for any
          datagram received on a port that does not explicitly enable
          zero-checksum processing.  A port for which zero-checksum has
          been enabled MUST NOT log the datagram.

Should we clarify that it MUST NOT log for the reason of it having a
zero checksum. It may still be logged but for other reasons. The
simplest change appears to say:

A port for which zero-checksum has been enabled MUST NOT log the
datagram for that reason.

7. Section 1.4, bullet 5:
      5.  UDP Tunnels that encapsulate IP MUST rely on the inner packet
          integrity checks provided that the tunnel will not
          significantly increase the rate of corruption of the inner IP
          packet.  If a significantly increased corruption rate can
          occur, then the tunnel MUST provide an additional integrity
          verification mechanism.  An integrity mechanism is always
          recommended at the tunnel layer to ensure that corruption
          rates of the inner most packet are not increased.

I think the first "MUST" is actually not correct. I think "MAY" is
actually more correct. If you transport IP as inner packet, then you MAY
rely on that being corruption verified by itself, the outer header
doesn't need to take that responsibility providing that the corruption
rate will not be increase. However disallowing additional checks was not
the intention here.

8. Section 1.5 should have its own main section.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------