Hi Gerrit, See inline... Tom P. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Gerrit Renker > Sent: Friday, September 03, 2010 6:52 AM > To: dccp@xxxxxxxx > Subject: [udp-encap rev2] discussion/comments > > 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? > [TomP] The main point is neither, or rather the main point is orthogonal to these issues. The main point is to allow DCCP to pass through existing NAT devices. > 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. > [TomP] I am very against doing the checksum calculation twice, once for UDP and then again for DCCP. In my opinion, implementations should know which encapsulation is being used. > > 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. > [TomP] I'll look into this for the next version. > 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 ?). > [TomP] I believe this is already covered in the draft (sections 3.4 and 3.5). As to how implementations will choose to do this (as you suggest or some other mechanism), I don't thinks that's the business of this draft. > 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. > [TomP] For applications that don't use a rendezvous protocol such as SDP, a default port is very useful. That it might be changed along the way doesn't change the initial need. > 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. > [TomP] I think that such as statement is not necessary. > 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). > [TomP] You seem to be confusing the UDP aspects with the DCCP aspects here. The DCCP server listens, and the DCCP client initiates on DCCP ports, but both server and client listen on UDP ports. > GF> This, to me, refers to both stacks at the hosts, rather than per- > socket connection > endpoints. I agree the wording should better. > [TomP] The wording where? > > 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. > [TomP] I don't agree. Introducing an in-the-network tunneling server complicates things (how do you ensure it's on the path? Build it into the NAT? But then why not build in real DCCP support?), and therefore will never be built. Maybe someone might choose to implement DCCP-UDP as a bump-in-the-stack model. Well, then that implementation can zero the DCCP checksum on the outbound side and recomputed it on the inbound side, instead of forcing more integrated implementations to calculate the checksum twice. > 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. > [TomP] I'm not seeing the relationship of this to what's immediately above. > 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 > [TomP] I think the abstract is pretty clear. > 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. > [TomP] I agree with Gorry. > * '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; [TomP] I find that very clumsy. > => 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. > [TomP] I think that this should be kept. The capabilities of 5596 are supported by DCCP-UDP. > * "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... > [TomP] DCCP-UDP supports the semantics of partial checksums, but not the function, as the UDP checksum covers the whole packet. I think the statement stands. > > 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". > [TomP] Possibly, but I like the resemblance to the drawing in 4340. > * 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? > [TomP] We've covered why the default port. I suggest changing "(normally both are the" to "(often both are initially the". > * Checksum: > - the specification (reference) of the UDP pseudo-header is missing; [TomP] RFC 0768 has already been referred to. I can add another reference here. > - 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. > [TomP] I don't agree with this (as covered before). > * 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; > [TomP] We still the paragraph of text that's in the section. I think it doesn't hurt to repeat the diagrams and set the context for that paragraph. > * 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.) > [TomP] I disagree. > * section 3.3.1 > - s/Chesksums/Checksums/ [TomP] I'll fix the typo. > - same comment as per (e), section could be omitted [TomP] I disagree. > > * 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? > [TomP] I think that 4340 section 14 (including 14.2) covers these issues. > * 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". > [TomP] I think you mean section 3.7. I believe the section says pretty much what you say above. > > 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 > [TomP] I disagree. > 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 >
