I think we may be converging, but I really would like to check. I'd like
to try some text below that we could use to replace section 3.8.
The current text reads:
A DCCP-UDP endpoint MAY use any UDP port number, providing the active
endpoint knows a valid UDP Destination Port on the passive endpoint.
By default, the DCCP-UDP client sets the source and destination ports
to the default port number. UDP port number XXX IANA PORT XXX has
been registered with IANA for this purpose.
A DCCP-UDP server (that is, an initially passive endpoint that wishes
to receive DCCP-Request packets [RFC4340] over DCCP-UDP) binds a UDP
port number for all encapsulated DCCP connections. If the DCCP-UDP
server binds to this default port reserved for the DCCP-UDP service,
it SHOULD accept datagrams from any UDP source port. For example,
this would be needed if a NAPT along the path had translated the
original UDP source port.
There is a risk that the same DCCP source port number will be used by
two endpoints each behind a NAPT. A DCCP-UDP endpoint SHOULD
therefore demultiplex a DCCP-UDP flow using both the UDP source and
destination port numbers in addition to processing of the DCCP ports
by the DCCP module.
Hence, the endpoint identifier for a DCCP-UDP connection should be
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> defined by DCCP-STD."
My first attempt at replacement text reads:
A DCCP-UDP endpoint MAY use any UDP port number, providing the active
endpoint knows a valid UDP Destination Port on the passive endpoint.
By default, a DCCP-UDP client sets the destination port
to the default port number. UDP port number XXX IANA PORT XXX has
been registered with IANA for this purpose. A client SHOULD set
source port to a number that is unique for this DCCP connection.
Choosing distinct source UDP ports for distinct DCCP connections
ensures that UDP-based flow identifiers differ whenever
DCCP-based flow identifiers differ. Specifically, two connections
with different <source address, source DCCP port, destination
address, destination DCCP port> 4-tuples will have different
<source address, source UDP port, destination address,
destination UDP port> 4-tuples.
A DCCP-UDP server (that is, an initially passive endpoint that wishes
to receive DCCP-Request packets [RFC4340] over DCCP-UDP) binds a UDP
port number for all encapsulated DCCP connections. If the DCCP-UDP
server binds to this default port reserved for the DCCP-UDP service,
it SHOULD accept datagrams from any UDP source port. For example,
this would be needed if a NAPT along the path had translated the
original UDP source port.
There is a risk that the same DCCP source port number could be used
by two endpoints each behind a NAPT. A DCCP-UDP server MUST
therefore demultiplex a DCCP-UDP flow using both the UDP source and
destination port numbers and the encapsulated DCCP ports.
A DCCP-Server MUST ensure than an active DCCP connection
is uniquely identified by the 6-tuple <source address,
UDP Source Port, DCCP Source Port, destination address,
UDP Destination Port, DCCP Destination Port>.
The demultiplexing at a DCCP-UDP endpoint occurs in two stages:
1) In the first stage DCCP-UDP packets are demultiplexed
using the 4-tuple, <source address, UDP Source Port,
DCCP Source Port, destination address, UDP Destination Port>.
2) In the second stage, a receiving endpoint MUST ensure
that two independent DCCP connections that were
multiplexed to the
same 4-tuple are not associated with the same connection
in the DCCP module. The endpoint therefore needs to keep
state for the set of active DCCP-UDP endpoints using each
4-tuple. This may be achieved in one of two ways:
A) A DCCP server MAY accept only one
active 6-tuple at any one time for a given 4-tuple. In this
case, DCCP-UDP packets that do not match an active
6-tuple MUST NOT be passed to the DCCP Module and the DCCP
Server SHOULD send a DCCP-Reset
with the reason "encapsulated port reuse". An endpoint that
receives a DCCP-Reset with this reason MAY immediately try
again using a different 4-tuple.
This provides protection should the same 4-tuple be
re-used by multiple DCCP connections, ensuring that
only one DCCP connection is established at one time.
B) A DCCP-SERVER MAY support multiple DCCP connections over
the same UDP 4-tuple. If supported, the endpoint MUST
then associate each 6-tuple with a single connection.
If an endpoint is unable to demultiplex the 6-tuple (e.g.
due to internal resources limits), it MUST NOR pass
DCCP-UDP packets that do not match an active
6-tuple to the DCCP Module. The DCCP
endpoint MAY send a DCCP-Reset
with the reason "encapsulated port reuse"
indicating the connection may be retried using a
different 4-tuple.
---
This document requests IANA to assign a new Reset Reason "encapsulated
port reuse". etc.
---
