Re: Comments on draft-fairhurst-dccp-serv-codes-03.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eddie Kohler wrote:

Tom,

The addition of service codes by DCCP allows us to break this
demultiplexing/identifying duality.  We can now say that the *exclusive*
use of port numbers is for demultiplexing, and the *exclusive* use of
service codes is for identifying applications.  This implies a few
rules:


We COULD say this, but why would we?
>
It also goes against the language in the DCCP RFC, which explicitly allows a listening socket to be associated with multiple Service Codes. (Think HTTP/1.0 and HTTP/1.1.)

I agree a passive socket/unbound socket can be open to receiving several different SC values. Although, an active socket MUST have only one SC associated with it.

Similarly, the DCCP stack MUST understand Service Codes, as it is required to send an error if service codes don't match.

Yes.

Gorry's draft should not be redefining the RFC in my opinion.
>
I guess the WG will decide if this updates or is simply an informational guideline. Mark Handley suggested in the last WG meeting that we need to keep an open mind about this, since at the time the Spec was written we had little experience of thinking this through - to me, this seems the right time to do this thinking.

On the other hand I still don't quite understand the goal of Gorry's draft.
>
Eddie



 o Demultiplexing is based on the source and destination IP address and
source and destination port numbers only, just as it is for the other
connection-oriented transports.  Only one application/socket can
"listen" on a port number for incoming connection requests.

 o It is not necessary for the DCCP stack to know the service code
associated with an application that is listening on a port number, since
the DCCP stack is really only concerned with demultiplexing, not
application identity.  A DCCP stack SHOULD (MUST?) allow an application
to check the service code in an incoming DCCP-Request and decide whether
or not to proceed with the connection.  A DCCP stack MUST NOT require an
application to perform this check.  A DCCP stack MAY (SHOULD?) allow an
application to pre-specify the service code[s] that it will accept and
process incoming DCCP-Requests based on that information.

 o A DCCP stack MUST allow an application to specify the service code to
be used in DCCP_Request packets.

 o Applications MAY use well-known port numbers to facilitate
client/server rendezvous.

 o Applications SHOULD register and use a service code specific to the
application.

 o Devices, for example, firewalls, wishing to identify an application
associated with a connection MUST use only the service code.  Devices
MUST NOT use port numbers to identify the type of application using a
connection.

Comments appreciated :-).

Tom P.






[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux