Here is a reply to your much earlier email - which I think I forgot to
send. Sorry, I was doing several things at once and didn't reply earlier.
Thanks for your comments. I am going to prepare a new revision and post
a URL to cover the changes from your comments, the ones from the WG
meeting and Tom's various comments.
Gorry
Eddie Kohler wrote:
Gorry, comments on service-codes-04.
The original draft of the DCCP specification did not use
traditional ports; instead the client allocated a 32-bit identifier
to uniquely identify the connection. ... This design
suffered from the downside of being sufficiently different from
existing protocols that there were concerns that it would hinder the
use of DCCP through NATs and other middleboxes.
An additional downside is that this design prevents the deployment of
two servers for the same service on a single machine, something that is
trivial with ports. This is the true reason why ports reappeared,
although NAT/middlebox concerns also played a part.
Added.
This permits a flexible correspondence between services and port
numbers than possible using the corresponding socket pair (4-tuple
of layer-3 addresses and layer-4 ports).
"a MORE flexible correspondence"
Added this too.
Note that more than one DCCP server may share the same server port,
since in DCCP the Service Code mechanism is the method for unique
identification of a service.
This is not correct: the COMBINATION of server port and Service Code
uniquely identifies a LISTENING APPLICATION. It is important to get
this right.
I agree with your sentence (added this later-on in the I-D). However, I
think the original text is also true (... and then a listening
application supporting a service opens one or more ports each specified
by a server port and service code).
2.7. A method to hash the Service Code to a Dynamic Port
I do not find this section convincing. Among other things:
- operating systems use the dynamic port range for client ports, and
therefore there is a chance that a server attempting to open the
indicated port for listening will be prevented from doing so because of
an existing short-lived client port.
>
Not sure I understand this. If the client connects to X from a port pair
(s,d) then why would the server receive a connect from the same client
with (s,d) as the port pair? - surely it would choose some different
source port?
- the function can return port 65535 which i believe some OSes refuse to
open.
>
Agreed - Port port 65535 should be excluded. Assigning this was an
unforeseen consequence of the proposal at the last WG meeting to move
this to the dynamic range. For the moment, I added the same "trick" as
we use for the UDP checksum, i.e. if it hashes to this, reassign the
number to the base value, 0xC000. [but see later query on what to do]
- there is no need for a large range of server ports (because of the
unique mapping of server port + service code to application).
>
Sure, a small range would be OK (and may be good if we were to use the
registered port range) - but if we use the dynamic range (as current),
then it would seem wiser to spread across all to lower the contention.
- the section is unclear whether it is suggesting a possible procedure
or defining a requirement.
We were not requiring this to be used. It was put forward as a
rendezvous method that would let you have a server port number you could
use without prior IANA reservation. Indeed, as proposed it's only a more
organised way of choosing a server port in the dynamic space.
Do you still think this is a problem?
I suggest instead that the document allocate one Registered Port
intended for use by DCCP applications with no port allocation of their
own. This port would become something like a "default DCCP port," and
applications using it would be using the originally intended service
code model.
If because of current OS constraints (such as the Linux
implementation's) more than one "default DCCP port" is required, that is
too bad, but a small range of, say, 256 or 1024 Registered Ports would
suffice in practice until that implementation limitation is overcome.
Possible, and this would work, but would need a strong motivation - i.e.
that we think the dynamic range presents problems.
Port numbers and IP addresses are the traditional methods to
identify a flow within an IP network. When the DCCP header has not
been encrypted, Middleboxes [RFC3234] should use the Service Code
to identify the application-service (even when running on a
non-standard port). When consistently used, the Service Code can
provide a more specific indication of the actual service (e.g.
indicate the type of multimedia flow, or intended application
behaviour). Middlebox devices are therefore expected to check
Service Code values as well as, or even instead of port numbers for
DCCP.
I disagree with this paragraph. It puts requirements on middleboxes and
recommends shifting away from well-known practices (e.g., port numbers)
to unknown practices with few practical benefits (Service Codes cannot
be trusted). "are therefore expected" is too strong. There are good
reasons to manage DCCP applications based on ports, including
familiarity. The most I would say is something like "Middleboxes that
use DCCP may additionally use the Service Code to identify an
application service, even when running on a non-standard port. When
consistently used, the Service Code can provide a specific hint of the
intended service, such as the type of multimedia flow or intended
application behavior." Additional text, if any, should explain WHY
middleboxes should shift towards using the Service Code; this would be
more convincing and appropriate than the current requirement.
This section would be more useful if it pointed out to middlebox authors
some issues with port numbers. For example:
"Middlebox authors are cautioned that new DCCP connections are
identified by the pair of Server Port and Service Code. In particular,
this means that IANA may allocate a server port to more than one
application. All such applications will be distinguished by Service
Code. A middlebox that intends to differentiate applications SHOULD
therefore test the Service Code as well as the destination or source
port on a DCCP-Request or DCCP-Response packet.
Security Consideration: DCCP's use of Service Codes as well as ports to
demultiplex incoming connections may change the service model expected
by middleboxes. The port-numbers registry already contains some
instances of multiple application registrations for a single port number
for TCP and UDP. This is relatively rare, however. Since DCCP's Service
Code allows multiple applications to safely share the same port number,
even on the same machine, port number reuse in DCCP may be more common
than in TCP and UDP. Middleboxes that intend to differentiate
applications should therefore examine Service Codes on connection
requests as well as port numbers."
>
I rewrote this section, which is a slight reorientation on the last text
we discussed. You may have comments on the new text (but I hope I added
most of this), if so let me know.
DCCP connections identified by the Service Code continue to use IP
addresses and ports, although neither port number may be Well Known.
Nothing about this is different from TCP or UDP. It should be cut.
True, but I kept this - I think it was helpful.
Although Service Codes label a connection and can (and is
encouraged to) associate specific delivery properties (e.g. use
Service Codes to identify the real-time nature of a flow that
claims to be using RTP),
Not good English.
Indeed, re-worked.
This document updates RFC4340 to also add:
"A specific Service Code value MAY be associated with more than one
server port, although only a single port is registered by IANA."
It would be good to define exactly what the updates to RFC 4340 are
doing here. So far all of the updates are clarifications, i.e., do not
change the meaning, except arguably for the "SHOULD" requirement for
multiple applications on the same listening port. Please explain
exactly what each change does. E.g., not "This document updates RFC4340
to also add:", but "This document updates RFC4340 to also add: .... This
change clarifies RFC4340, but does not change its meaning."
I'll look again and try to differentiate clarifications - but changing
the 2119 keyword is more than a clarification?
o "IANA should normally assign a value above 1024 to a DCCP server
port. IANA allocation requests to allocate port numbers in the Well
Known Ports range (0 through 1023), require Expert Review prior to
allocation by IANA [RFC4340]. Requests for registered ports in the
range 1024-49151, do not normally require Expert Review."
What's the logic for this requirement? I would remove it. Service Code
demultiplexing should mean that ANY allocation request for a port does
not normally require Expert Review.
[The intention was to relax the requirement, but allow IANA intervention
- e.g. to resolve issues with port re-use between transport protocols, etc.]
For this and other things on the IANA registration, note there is
related work in TSV to harmonise port assignments for all IETF transports.
o "IANA MUST NOT allocate more than one DCCP server port with a
single Service Code value.
Strongly disagree. I see no reason for such a restriction. This also
goes against what you recommend middleboxes do.
We do disagree. The rationale has long been that the IETF do not
allocate multiple ports for an application - expecting it to coordinate
any extra port usage from the dynamic range using the single assigned
port. True, if we rely totally on SC, we would not need this - however,
we also need to be realistic in that there may be cases where SC are not
used as intended (possibly), current IANA procedures reserve ports
across all transport registries when allocated for one transport (e.g.
DCCP is not to be a back-door to getting multiple UDP ports).
o A request for additional Service Codes to be associated with an
already allocated Port Number requires expert review. These
requests will normally be accepted when they originate from the
contact associated with the port registration. In other cases,
these applications will be expected to use an unallocated port,
when this is available."
Again, I disagree. What is the logic? Is this designed to keep the
meanings of ports stable for middlebox authors? See my text above.
Not exactly. If company X requests a port from IANA, then they could
believe they have some "ownership" of the port they were assigned (after
all the went to the bother of registering the port - for whatever
cause). Therefore if company Y now approaches IANA and explicitly asks
to use the port, it seems reasonable for someone to check this.
RFC 4340 notes that a short port name MUST be associated with each
DCCP server port that has been registered, and that this name is
expected to be unique within the registry. This document updates this
by adding that:
o "A port name may be generated from the Service Code value
represented in hexadecimal, e.g. SC:fdpz corresponds to the port name
'0x6664707a'."
In the case of DCCP, it is considered useful to use a value that
shows the association with the Service Code, and since service codes
are 32-bit numbers this requires the a hexadecimal representation.
This differs with the tradition of naming ports in UDP and TCP.
Again, I disagree. This uglifies port numbers. The colon character is
not used in any existing port number registration.
[Nor was the colon intended here] - We agree - this was a part of a
"direction" proposed by the ad-hoc meeting after the previous IETF. It
is my understanding that this approach did not approve attractive when
it was sketched out, and I have removed this from the draft. I also will
NOT recommend this to IANA.
The registrations in
the service-codes draft itself do not follow this logic.
>
Indeed :-)
And finally
there is already a well-known mechanism for associating Service Codes
with ports: RFC4340 requires that the port number registration's short
English phrase include the Service Code; this is easily parsed. Please
remove this.
I am not sure how easily it will be parsable, as current. However, I'll
try to ask that the SC is a defined field in the new IANA XML-based
registry, which should fix this once IANA changes.
This document notes that it is not required to supply an approved
document (e.g. a published RFC) to support an application for a
DCCP Service Code or port number value, although RFCs may be used
to request Service Code values via the IANA Considerations section
(e.g. [ID.SC]). A specification is however required to allocate a
Service Code that uses a combination of ASCII digits, uppercase
letters, and character space, '-', '.', and '/') [RFC4340].
This is not a change from RFC4340 and should be marked as such.
I agree; I don't think this is a change. I did not mark it as an update.
Hope this helps.
Yes, that was MOST helpful. I'll post a URL to a new interim rev of the
draft as soon as I have checked the I-D. Let me know if you have more
comments.
Eddie
Gorry
