Please find below the transcript of a discussion I sent to Gorry regarding
revision 2 of the udp-encap draft.
As per Gorry's comments, I may have missed parts of the discussion, so please
ignore or correct where I am erring.
The main point I did not understand is whether the aim is to
* encapsulate DCCP as a user-space protocol or
* encapsulate DCCP as an in-kernel protocol?
If the latter is the main aim, then it would be great not to make changes to
the encapsulated data (DCCP header + DCCP payload), since this would require
a separate implementation for generating the DCCP-UDP payload data.
Even if the DCCP checksum should break as a result of NAT-ing some of the
IP adresses - the DCCP checksum can easily be recomputed at the UDP endpoint.
General questions and remarks
=============================
a. It would be good to specify how UDP ICMP errors are translated into DCCP
semantics, in particular the "administratively prohibited" variants of
Destination Unreachable (RFC 1122, 3.2.2.1), and how these options are
to be passed on to UDP.
GF> Agree, something is needed to specify at the sender to say the procedure for generating errors
and processing then at the receiver.
b. Are network-layer options (e.g. setting TOS) which may be set with DCCP-STD
simply to be transferred to DCCP-UDP (same question for PMTUD - is the
DCCP-UDP MTU the same the UDP_MTU - 8 ?).
c. Why does there need to be an IANA-assigned default port for DCCP
encapsulation? The benefit of a well-known for current-generation NAT boxes
is not clear (it would not help NAT traversal). For future-generation NAT
boxes might give the wrong impression to implementors that DCCP-UDP is the
only feasible way of supporting DCCP.
For out-of-band signalling SDP has already been specified by the document.
GF> This is debatable - I can see pros and cons, at the moment I'd favour using
a well known port. The document should say WHY the method is chosen.
d. The document specifies that both endpoints shall be listening on the given
UDP port, while DCCP distinguishes active and passive (client/server) parts
of the connection. I wonder whether it is necessary or would be good to
inform about which side is the active one in the SDP protocol, since how
shall the endpoint otherwise know what to do with the UDP tunnel? If both
endpoints listen, nothing happens, if both connect there is simultaneous
open (discussed in RFC 5596).
GF> This, to me, refers to both stacks at the hosts, rather than per-socket connection
endpoints. I agree the wording should better.
e. I can see no point for the extra rule that DCCP packets contained in UDP
encapsulation should not have their own checksums. First it alters and
restricts the use of DCCP so that encapsulated DCCP behaves differently
from unencapsulated DCCP. Second, it makes the specification more complicated,
by adding exceptions. Furthermore, the Internet checksum is cheap to compute,
the other endpoint is known (and hence pseudo-header is already implicit).
The restriction of not being able to use partial checksums limits usability
if e.g. DCCP-UDP is employed on a path where on the "last mile" partial
checksums are of interest (e.g. wireless links). It is also conceivable
that there may be a "tunneling server" which transparently wraps DCCP in UDP;
for such mode of operation it could simply just prepend the 8 bytes of header,
checksum the resulting packet, no need to alter its payload. The peering
endpoint would strip off the UDP header and could forward the enclosed DCCP
datagram without having to peek into the packet in order to recompute the
checksum. Hence the recommendation is to keep DCCP as originally specified
in DCCP, and to not introduce extra checksumming rules.
GF> This comes from the NAT behaviour where the module modifies the IP (and port
values for NAPT) of the outer headers. The encaps document doesn't say how
this works, and I expect a NAPT would re-write the "emphemeral" port anyway.
So, I am guessing the encaps receiver should bind to ANY src port and the
standard DCCP_UDP dst port by default. The document should say WHY the method was chosen.
Abstract
--------
* the term 'alternative' encapsulation is a bit misleading, since there is
alternative, both DCCP-STD and DCCP-UDP are encapsulated in IPv4/6 headers;
* it would be clearer to refer to the technique as something like "DCCP-in-UDP"
* "without modification of those middleboxes"
=> suggest e.g. 'modification of their software stacks' since "middleboxes"
otherwise is repeated in the same sentence
1. Introduction
---------------
* 'According to [RFC 4340], DCCP packets are directly encapsulated ...'
=> this is clear from the definition of transport protocol, could be omitted
GF> I disagree: This was instead in the last review, to make clear the NORMAL
behaviour was standard RFC 4340 encaps.
* 'For convenience, the [RFC 4340] encapsulation (updated by [RFC 5596])'
=> as above, perhaps one could refer to RFC 4340 as "native packetization of
DCCP within IP" or something similar;
=> the remark that RFC 4340 is updated by RFC 5596 is not relevant, referencing
it would only make sense if there were discussion comparing the pros and cons
of the two approaches, which does not seem to be the aim of this specification.
Since this document introduces a fix for current-generation NAT devices, it
could e.g. be said that current generation NAT devices also do not support
RFC 5596 (hopefully Linux will soon), or the RFC reference could be dropped.
> I recommended adding this: The rationale was we need to be able to transition
firewalls AND NATs and the same behaviour can not be expected at all middleboxes.
Therefore, I argued that the encaps MUST support both RFC 4340 and the extension
in 5596 to allow it to operate in the wild, especially with multiple NATs/Firewalls.
* "The DCCP-UDP encapsulation specified here supports all of the features
contained in DCCP-STD except for partial checksums."
=> Please see (e) above, it would be best not to introduce new assumptions
about DCCP and support the checksum by treating the encapsulated packet
as opaque payload data of UDP. This would not restrict application scenarios
("sorry you can't use partial checksums because we are tunneling you").
GF> The intention was to allow applications to use the same partial-checksum code,
but they wouldn't get benefit with UDP encaps. If they were to use UDP-Lite encaps
they would, but that is a corner case...
3. DCCP-UDP
-----------
* "(default port awaiting IANA action)"
sorry I don't understand why it is necessary to define a default port?
* "The basic format of a DCCP-UDP packet is"
=> Drawing could perhaps be simplified by referring from 'DCCP Generic
Header' downwards simply as "DCCP packet, possibly with header options,
as specified in RFC 4340, section 5".
* section 3.1, "(normally both are the default port to be assigned by IANA)"
=> meaning that 'Source Port' == 'Dest Port'?
=> again, please, I don't understand why a default port is required?
* Checksum:
- the specification (reference) of the UDP pseudo-header is missing;
- as per (e) above it is better not to introduce assumptions about the
contained payload, which would also simplify the specification, i.e.
* checksums are to be used and computed as specified in RFC 4340,
* the DCCP pseudo-header uses the DCCP port numbers and the UDP
endpoint IP addresses (i.e. from the point of DCCP the encapsulating
UDP header does not exist);
* the DCCP-UDPv4 checksum computation then proceeds according to
RFC 768 with the UDP checksum field set to zero and using as
UDP length the length of the contained DCCP packet including the
DCCP header and DCCP header options;
* the DCCP-UDPv6 checksum computation uses the pseudo-header
from RFC 2460, 8.1 with the Upper-Layer packet length set to the
length of the contained DCCP packet including the DCCP header and
options.
* section 3.2 could be omitted, since this is already specified in
RFC 4340 and as far as I understand the inner DCCP packet semantics
are opaque for the purpose of NAT traversal;
* section 3.3, checksum computation
- as per (e) above, this section could be omitted
- with regard to checksum validity it could be simplified by
referring validate DCCP-UDP packets according to RFC 768, with
the restriction that the checksum MUST NOT be disabled (zero csum)
- (The term 'DCCP-NAT' has not been introduced in this document.)
* section 3.3.1
- s/Chesksums/Checksums/
- same comment as per (e), section could be omitted
* section 3.5
- would be good to clarify the use of UDP fragmentation:
UDP implementations support fragmentation, UDPv6 in addition supports
jumbograms (RFC 2675), hence need clarification whether to
a) bump the maximum inner MTU of DCCP to exploit the limits of UDP or
b) completely disallow fragmentation of DCCP-UDP packets (since possibly
not supported by hardware)
- how shall section 14 of RFC 4340 be interpreted in this context:
* is DCCP's MPS simply the UDP PMTU minus 8?
* apply RFC 5405 for UDP MTU fallback values?
* section 3.6
I don't understand the purpose of specifying the service code of an
encapsulated protocol. Service code and encapsulation seem not related,
a connection could have any service-code value and still need UDP
encapsulation, but why not leaving this transparent to DCCP?
In particular, if assuming a "DCCP tunnelling service" or a type of
overlay network, it would be difficult to alter the contained service
code. Also, like the checksums, this again introduces new assumptions
into DCCP and complicates the specification. My personal view is to
allow DCCP to pick whatever service code is appropriate for the type
of service used, and not to add additional rules restricting this use
because the protocol ends up being "tunneled".
5. Signaling the Use of DCCP-UDP
--------------------------------
* "listening for DCCP-UDP connections on the indicated UDP port (if
udp-port-num is included)
--> suggest to make the use of `udp-port-num' mandatory ('MUST') and
not to require an IANA-assigned well-known port
GF> Don't agree.
7. IANA Considerations
----------------------
* same comment as earlier, perhaps I am missing something, but I fail
to see the need for a default well-known port for DCCP encapsulation
