Hi Eddie, Thanks for the comments. I am in general agreement. See inline for specifics. Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Eddie Kohler > Sent: Monday, September 20, 2010 12:45 PM > To: dccp@xxxxxxxx > Subject: Re: WGLC for dccp-udpencap > > Hello all, > > I understand that WGLC for this draft has concluded, but in case comments > are > useful, here are several. I strongly approve of the document; it is a > clean > and useful spec and a good advance on prior versions, whether or not these > comments are addressed. The only technical comment has to do with > demultiplexing; this is important to address. > > * Ports (section 3.1): I agree with those who have commented about the > oddity > of "normally both [souce & destination ports] are the default port to be > assigned by IANA". I agree with Gorry & the document that it is useful to > have a default port. But keeping the src&dst ports as the default is > unnecessary and unlikely to hold. > [TomP] Hmm. People seem to like to assume that "normally" means that it MUST be this way. That wasn't the intention. > I would change the explanation as follows. Note the third paragraph, set > off > with %%%. This is new text. I think we must mention demultiplexing > (whether > the UDP Ports are ignored for demultiplexing purposes), and I believe that > demultiplexing MUST consider UDP Ports as well as DCCP ports: there is a > risk > that the same DCCP Source Port will be used by two endpoints behind a NAT, > as > in the ASCII art diagram below. > > S1 --> UDP sport U1, DCCP sport D1, > UDP dport UX, DCCP dport DX > \ > v UDP sport U1, DCCP sport D1, UDP dport UX, DCCP > dport DX > NAT =========================================> SERVER > ^ UDP sport U2*, DCCP sport D1, UDP dport UX, DCCP > dport DX > / > S2 --> UDP sport U1, DCCP sport D1, > UDP dport UX, DCCP dport DX > > * To prevent ambiguity the NAT changes S2's UDP sport; all else remains > the > same; the NAT cannot reach into the DCCP header to change those > ports. > If DCCP-STD were used with a DCCP-aware NAT, one of the DCCP sports > would > change. > > BEGIN TEXT > > Source and Dest(ination) Ports: 16 bits each > > These fields identify the UDP ports used for the encapsulated DCCP > connection. > Note that they do not identify the DCCP source and destination ports. > > A DCCP-UDP server (that is, an initially passive host that receives > DCCP-Request packets [RFC 4340]) MAY reserve a UDP port number for all > encapsulated DCCP connections. In this case, DCCP-UDP packets arriving at > the > server will have the same UDP Destination Port. UDP port number XXX has > been > registered with IANA for this purpose. A DCCP-UDP client MAY use this > port > number as its UDP Source Port as well. However, any DCCP-UDP endpoint MAY > use > any UDP port numbers (as long as the active endpoint knows a valid UDP > Destination Port on the passive endpoint). > > %%% The identifier for a DCCP-UDP connection is the 6-tuple <source > address, > UDP Source Port, DCCP Source Port, destination address, UDP Destination > Port, > DCCP Destination Port>, rather than a 4-tuple <source address, source > port, > destination address, destination port>. %%% > > END TEXT > [TomP] I didn't consider this case. I'll update the draft. > * Checksum (section 3.1): "This field is the Internet checksum of a > network-layer pseudoheader and the UDP packet." -- Might be nice to > mention > here that 0 checksums aren't allowed, as well as in S3.3. > [TomP] OK -- I think just to 3.3, say a zero checksum is invalid. > * S3.3: It might be nice to refer to DCCP's Data Checksum option, pointing > out > that, unlike the DCCP-Checksum header field, the Data Checksum option MUST > be > processed as usual. > [TomP] OK. > Eddie > > > On 09/18/2010 04:23 AM, Pasi Sarolahti wrote: > > WG Last Call for draft-ietf-dccp-udpencap concluded some days ago. > Thanks to everyone who commented! It's unclear to me if we have conclusion > on some of the discussed topics, namely: > > > > * The text on checksums and partial checksums > > > > * Security considerations and the text on firewalls > > > > * Discussion on source/destination port allocation and NAPT > > > > * Applicability of the Section 5.1 text > > > > Tom, do you think we have converged on these? Also, I'd like to see some > comments on Gerrit's review, to see to what degree there is agreement on > the issues. > > > > Assuming we have settled with the above topics, I think we need a > revision based on the discussion, that would then be sent to the IESG. > > > > - Pasi > > > > > > On Aug 27, 2010, at 9:16 PM, Pasi Sarolahti wrote: > > > >> This mail starts a working group last call for the UDP encapsulation > draft. The draft is available at http://www.ietf.org/internet- > drafts/draft-ietf-dccp-udpencap-02.txt . Please read the draft and send > any comments to the DCCP mailing list. Also, if you think the document is > good to go forward, it will be helpful if you send a note about that to > the mailing list. > >> > >> The WGLC lasts for two weeks, until September 10. > >> > >> - Pasi > >> > >
