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.
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
* 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.
* 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.
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
