VideoLAN project

rem@videolan.org http://www.videolan.org/

Transport Area Behavior Engineering for Hindrance Avoidance (if taken) This document would define a set of requirements for NATs that handle DCCP.

For historical reasons, NAT devices are not typically capable of handling datagrams and flows for application using the Datagram Congestion Control Protocol (DCCP). This draft discusses the technical issues involved, and proposes different potential solutions. It is however expected that not all of them (if any) will be carried on.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document applies to NAT devices that want to handle DCCP datagrams. It is not the intent of this document to deprecate the overwhelming majority of deployed NAT devices. These NATs are simply not expected to handle DCCP, so this memo is not applicable to them. TBD: This draft does not currently specify any clear requirement anyway.

The first approach to using DCCP through NAT devices involves changing the NAT devices to handle DCCP explicitly. Processing of DCCP packets by a NAT device would then be very similar to processing of TCP packets, as already specified in . In addition to the usual changes to the IP header, NAT devices would need to mangle: DCCP source port, for outgoing packets, depending on the NAT mapping DCCP destination port, for incoming packets, depending on the NAT mapping DCCP checksum, to compensate for IP address and port number modifications. Because changing the the source or destination IP address of a DCCP packet will normally invalidate the DCCP checksum, it is not possible to use DCCP through a NAT without dedicated support. Some NAT devices are known to provide a "generic" transport protocol support, whereby only the IP header is mangled. That scheme will not work with DCCP at all. TBD: write down actual mapping and timing requirements, etc. See behave-nat-tcp as a start.

Tunnelling is another approach: DCCP datagram would be encapsulated into an additionnal UDP transport header. This relies on the fact that many NATs are capable of handling UDP datagrams. This solution has tha major advantage of not needing any changes to the existing deployed NAT devices. Issues with this solution include: Both sides of the DCCP session need to be updated to use tunnelling, even though only one side might be hindered with a NAT. This implies a non-backward compatible extension to . A method MUST be defined to negociate when to use tunnelling. The per-packet overhead is increased. Various actual tunnelling solutions are already defined, such as ESP-in-UDP (especially with the NULL cipher suite) or Teredo.

When both parties to an intended DCCP session are located behind either a NAT device or a stateful firewall, neither can act as the paassive endpoint in the connection establishment. Unfortunately, at the time of writing, the DCCP connection state machine does not allow both peers to behave as active endpoint, as is the case in TCP simultaneous open. It is expected that this issue will be tackled in the DCCP working group shortly (TODO: reference relevant I-D).

TBD.

This document raises no IANA considerations.

The authors would like to thank ... for their comments on this document.