I've been working on a revision that seeks to address some of the issues that were raised and clarify some points. This is an email to summarise my current understanding. I'd like to post a new revision of the I-D, since this now has many changes and I'd like to resynchronise the discussion with the draft. ] Only one application/socket can "listen" on a port number ] for incoming connection requests. ] True: demux by SC is on a per connection (socket) basis, not packet by packet. But, I'd envisaged that Passive sockets MAY be associated with more than one Service Code aka inetd, but different (RFC 4340, 8.1.2), which means a non-connected socket may be associated with more than one potential service the requested SC will determine which (if any) is selected. ] 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. ] So, we are talking about the operation of a receiver here. The logic to accept/reject a connection needs to be a part of determining if the SC is valid, and I think the current logic assumes that once the application is involved, the socket has already accepted the connection. IMHO, letting apps process this in their own code is not the right way to handle this An app does not know what to do with a SC that is not for this particular app, but for another app passively waiting on the same port. This could be handled by the equivalent of a SC-enabled inetd (the ³enhanced² mode in the I-D). ] 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. ] I¹m not sure I see it this way (yet). I¹d suggest an application MUST devolve this checking to the DCCP stack. The parts I find hard are: * Applications that are launched by inetd (or equivalent), where the socket needs to be passed to the correct application. The OS has several candidate SC that may be matched, one of which mus match prior to opening. * Applications such as RTP that have a wide (not unique) range of ports they do not appear for instance in /etc/services, but we would like them to have a Service Code, so the app should tell DCCP that the port is only to be bound to a specific SC. Am I reading this correct? ] A DCCP stack MUST NOT require an application to perform ] this check. ] The Spec. says the connection MUST only be accepted if the SC is valid so to me that implies the stack MUST decide to accept or abort. Is this what others think? ] 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. ] Yes (RFC 4340, 8.1.2) the minimal support in section 4.1 of the I-D satisfies the MAY. The support described in sections 4.2 & 4.3 does more. ] I have not yet been able to see how servcodes could ] be exploited so that a variety of hosts behind a NAT can ] offer the same service to the Internet. As far as I can see, ] even if you use servcodes for demultiplexing packets, ] you'll need "well-known servcodes". ] As far as I can see, in order for several hosts behind a ] NAT to offer the same service to the Internet you'd need ] a directory service like like DNS SRV RRs, portmapper, etc. ] Well, in my understanding, SC are not generally expected to be ³dynamic² so it could be sufficient to used a configured table. If you implement an ALG, you could probably then associate the SC with the ALG. Best wishes, Gorry
