> The minimal length ICMP error message generated in response to > processing a UDP Datagram only identifies the Source UDP Port and > Destination UDP Port. The ICMP message does not carry sufficient > information to discover the encapsulated DCCP Port values. A DCCP-UDP > endpoint that supports multiple DCCP connections over the same pair of > UDP ports (see section <xref target="port") may not therefore be able > to > associate an ICMP message with a unique DCCP-UDP connection. Perfect. Thanks. > > 9. Section 3.7, "Path Maximum Transmission Unit Discovery", needs to > > remind implementers to consider the UDP overhead when doing PMTUD. > > > Done, and also noted reduced DCCP MPS. > > > 10. Section 3.3.1, "partial checksums". Do NATs support partial > > checksums, or do some of them drop UDP packets with bad checksums? > > RFC4787 is silent (on purpose, as I recall). > > > Indeed :-) > > I'm not sure what change you suggest, but propose the following updated > text to replace section 3.3.1 to improve clarity: > > This document describes an encapsulation for DCCP that uses the UDP > transport. It requires that the UDP checksum to be enabled. This > checksum provides coverage of the entire encapsulated DCCP datagram. > > DCCP-UDP supports the syntax of partial checksums. It also supports > negotiation of the Minimum Checksum Coverage feature and settings of > the > CsCov field. However, the UDP checksum field in DCCP-UDP always covers > the entire DCCP datagram and the DCCP checksum is ignored on receipt. > An > application that enables the partial checksums feature in the DCCP > Module will therefore experience a service that is functionally > identical to using full DCCP checksum coverage. This is also the > service > that the application would have received if it had used a network path > that did not provide optimised processing for DCCP partial checksums. Perfect. Thanks. -d
