wdiff rfc5595.original rfc5595.txt

DCCP WG G.Fairhurst
Internet-Draft
Network Working Group G. Fairhurst
Request for Comments: 5595 University of Aberdeen
Intended status: Proposed Standard May 26, 2009
Expires: October 31, 2009
Updates: RFC 4340 July 2009
Category: Standards Track

The DCCP Datagram Congestion Control Protocol (DCCP) Service Code
draft-ietf-dccp-serv-codes-11.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 26, 2009. Codes

Abstract

This document describes the usage of Service Codes by the Datagram
Congestion Control Protocol, RFC 4340. It motivates the setting of a
Service Code by applications. Service Codes provide a method to
identify the intended service/application to process a DCCP
connection request. This provides improved flexibility in the use
and assignment of port numbers for connection multiplexing. The use
of a DCCP Service Code can also enable more explicit coordination of
services with middleboxes (e.g. (e.g., network address translators and
firewalls). This document updates the specification provided in RFC
4340.

Table

Status of Contents

1. Introduction...................................................3
1.1. History...................................................3
1.2. Conventions used in this document.........................6
2. An Architecture This Memo

This document specifies an Internet standards track protocol for Service Codes..............................6
2.1. IANA Port Numbers.........................................6
2.2. DCCP Service Code Values..................................8
2.2.1. New versions of Applications or Protocols............8
2.3. Service Code Registry.....................................9
2.4. Zero Service Code.........................................9
2.5. Invalid Service Code......................................9
2.6. SDP the
Internet community, and requests discussion and suggestions for describing Service Codes..........................9
2.7. A method
improvements. Please refer to hash the Service Code to a Dynamic Port......10
3. Use current edition of the DCCP Service Code..................................10
3.1. Setting Service Codes at the Client......................11
3.2. Using Service Codes in the Network.......................11
3.3. Using Service Codes at "Internet
Official Protocol Standards" (STD 1) for the Server........................12
3.3.1. Reception of a DCCP-Request.........................13
3.3.2. Multiple Associations standardization state
and status of a Service Code with Ports..14
3.3.3. Automatically launching a Server....................14
4. Security Considerations.......................................14
4.1. Server Port number re-use................................15
4.2. Association this protocol. Distribution of applications with Service Codes...........15
4.3. Interactions with IPsec..................................16
5. IANA Considerations...........................................16
6. Acknowledgments...............................................16
7. References....................................................17
7.1. Normative References.....................................17
7.2. Informative References...................................17
8. Author's Addresses............................................19
8.1. Disclaimer...............................................19
8.2. this memo is unlimited.

1. Introduction

DCCP specifies a Service Code Notice

Copyright (c) 2009 IETF Trust and the persons identified as a 4-byte value (32 bits) that
describes the application-level service to which a client application
wishes
document authors. All rights reserved.

This document is subject to connect ([RFC4340], section 8.1.2). A Service Code
identifies BCP 78 and the protocol (or a standard profile, e.g. [ID.RTP]) IETF Trust's Legal
Provisions Relating to be
used at IETF Documents in effect on the application layer. It is not intended to be used to
specify a variant of an application, or a specific variant date of a
protocol (Section 2.2).

The Service Code mechanism allows an application to declare the set
publication of services that are associated with server port numbers. This can
affect how an application interacts this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with DCCP. It allows decoupling
the role of port numbers respect to indicate a desired service this document.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the role copyright in connection demultiplexing and state management. A DCCP application
identifies some of this
material may not have granted the requested service by IETF Trust the Service Code value in a DCCP-
Request packet. Each application therefore associates one or more
Service Codes with each listening port ([RFC4340], section 8.1.2).

The use right to allow
modifications of Service Codes can assist such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in identifying such materials, this document may not be modified
outside the intended
service by a firewall IETF Standards Process, and derivative works of it may assist other middleboxes (e.g., a proxy
server, network address translator (NAT) [RFC2663]). Middleboxes that
desire to identify
not be created outside the type of data a flow claims IETF Standards Process, except to transport,
should utilize the Service Code format
it for this purpose. When consistently
used, the Service Code can provide a more specific indication of the
actual service (e.g. indicating the type of multimedia flow, or
intended application behaviour).

The more flexible use of server ports can also offer benefit to
applications where servers need to handle very large numbers of
simultaneous open ports to the same service. publication as an RFC 4340 omits or to describe the motivation behind Service Codes, nor
does translate it properly describe how Well Known and Registered server ports
relate to Service Codes. The intent into languages other
than English.

Table of this document is to clarify
these issues. Contents

1. Introduction ....................................................2
1.1. History

It is simplest to understand the motivation ....................................................3
1.2. Conventions Used in This Document ..........................6
2. An Architecture for defining Service Codes by describing ...............................6
2.1. IANA Port Numbers ..........................................6
2.2. DCCP Service Code Values ...................................7
2.2.1. New Versions of Applications or Protocols ...........8
2.3. Service Code Registry ......................................8
2.4. Zero Service Code ..........................................9
2.5. Invalid Service Code .......................................9
2.6. SDP for Describing Service Codes ...........................9
2.7. A Method to Hash the history Service Code to a Dynamic Port ........9
3. Use of the DCCP protocol.

Most current Internet transport protocols (TCP [RFC793], UDP
[RFC768], SCTP [RFC4960], UDP-Lite [RFC3828]) used "Published" port
numbers from Service Code ...................................10
3.1. Setting Service Codes at the Well Known or registered number spaces [RFC814].

These 16-bit values indicate Client .......................11
3.2. Using Service Codes in the application service associated with
a connection or message. The server port must be known to Network ........................11
3.3. Using Service Codes at the client
to allow a connection to be established. This may be achieved using
out-of-band signaling (e.g. described using SDP [RFC4566]), but more
commonly a Published port is allocated to Server .........................12
3.3.1. Reception of a particular protocol or
application; for example HTTP commonly uses port 80 and SMTP commonly
uses port 25. Making DCCP-Request ........................13
3.3.2. Multiple Associations of a port number Published [RFC1122] involves
registration Service Code
with the Internet Assigned Numbers Authority (IANA),
which includes defining Ports .........................................14
3.3.3. Automatically Launching a service by Server ...................14
4. Security Considerations ........................................14
4.1. Server Port Number Reuse ..................................15
4.2. Association of Applications with Service Codes ............15
4.3. Interactions with IPsec ...................................15
5. IANA Considerations ............................................16
6. Acknowledgments ................................................16
7. References .....................................................17
7.1. Normative References ......................................17
7.2. Informative References ....................................17

1. Introduction

DCCP specifies a unique keyword and reserving Service Code as a
port number from among 4-byte value (32 bits) that
describes the application-level service to which a fixed pool [IANA].

In client application
wishes to connect ([RFC4340], Section 8.1.2). A Service Code
identifies the earliest draft of DCCP, protocol (or the authors wanted standard profile, e.g., [RTP-DCCP])
to address be used at the
issue of Published ports in a future-proof manner, since this method
suffers from several problems:

o The port space application layer. It is not sufficiently large for ports intended to be easily
allocated (e.g. in an unregulated manner). Thus, many
applications operate using unregistered ports, possibly colliding
with use by other applications.

o The use of port-based firewalls encourages application-writers used
to
disguise one specify a variant of an application as another in or a specific variant of a
protocol (Section 2.2).

The Service Code mechanism allows an attempt application to bypass
firewall filter rules. declare the set
of services that are associated with server port numbers. This motivates firewall writers to use deep
packet inspection in can
affect how an attempt to identify the service associated application interacts with a port number.

o ISPs often deploy transparent proxies, primarily to improve
performance and reduce costs. For example, TCP requests destined
to TCP DCCP. It also allows
decoupling of the role of port 80 are often redirected numbers to indicate a web proxy.

These issues are coupled. When applications collide on the same
Published, but unregistered port, there is no simple way for network
security equipment to tell them apart, with desired service
from the likelihood role of
introducing problems port numbers in demultiplexing and state management.
A DCCP application identifies the requested service by the Service
Code value in a DCCP-Request packet. Each application therefore
associates one or more Service Codes with interaction each listening port
([RFC4340], Section 8.1.2).

The use of features.

There is little that a transport protocol designer Service Codes can do about
applications that attempt to masquerade as assist in identifying the intended
service by a firewall and may assist other applications. For
ones middleboxes (e.g., a proxy
server or network address translator (NAT) [RFC2663]). Middleboxes
that are not attempting desire to hide, identify the problem may be simply that
they cannot trivially obtain type of data a Published port. Ideally, it flow claims to transport
should be
sufficiently easy that every application-writer utilize the Service Code for this purpose. When consistently
used, the Service Code can request provide a Well
Known more specific indication of the
actual service (e.g., indicating the type of multimedia flow or registered
intended application behaviour) than deriving this information from
the server port and receive one instantly with no questions
asked. value.

The 16-bit port space traditionally used is not more flexible use of server ports can also offer benefits to
applications where servers need to handle very large enough numbers of
simultaneous-open ports to support such the same service.

RFC 4340 omits a trivial allocation description of ports.

Thus, the design of DCCP sought an alternative solution. The idea
was simple. A 32-bit server port space should be sufficiently large
that motivation behind Service Codes,
and it enables use of very simple allocation policies. However,
overhead considerations made a 32-bit port value undesirable (DCCP
needed does not properly describe how Well Known and Registered
server ports relate to be useful for low rate applications). Service Codes. The solution in DCCP to intent of this problem was document is
to use a 32-bit Service Code
[RFC4340] clarify these issues.

RFC 4340 states that is included only in the DCCP-Request packet. The use
of a 32-bit value was Service Codes are not intended to make it trivially simple to obtain
a unique value for each application. Placing the value in a be DCCP-
Request packet, requires no additional overhead for the actual data
flow.
specific. Service Codes, or similar concepts, may therefore also be
useful to other IETF transport protocols.

1.1. History

It is however sufficient for both the end systems, and
provides any stateful middleboxes along the path with additional
information simplest to understand what applications are being used.

Early discussion the motivation for defining Service
Codes by describing the history of the DCCP protocol considered an alternative to
the protocol.

Most current Internet transport protocols (TCP [RFC793], UDP
[RFC768], SCTP (the Stream Control Transmission Protocol) [RFC4960],
and UDP-Lite [RFC3828]) use of traditional ports; instead it was suggested that "Published" port numbers from the Well
Known or Registered number spaces [RFC814]. These 16-bit values
indicate the application service associated with a connection or
message. The server port must be known to the client
used to allow a 32-bit identifier
connection to uniquely identify each connection. The
server listened on be established. This may be achieved using out-of-band
signalling (e.g., described using SDP [RFC4566]), but more commonly a socket bound only
Published port is allocated to a Service Code. This
solution was unambiguous; the Service Code was the only identifier particular protocol or application;
for example, HTTP commonly uses port 80 and SMTP commonly uses port
25. Making a listening socket at port number Published [RFC1122] involves registration
with the server side. The DCCP client included Internet Assigned Numbers Authority (IANA), which includes
defining a
Service Code in the request, allowing it to reach the corresponding
listening application. One downside was that this prevented
deployment of two servers for the same service on by a single machine,
something that is trivial with ports. The design also 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 unique keyword and other middleboxes.

RFC 4340 abandoned the use of reserving a 32-bit connection identifier in favor
of two traditional 16-bit port values, one chosen by the server and
one by number
from among a fixed pool [IANA].

In the client. This allows middleboxes to utilize similar
techniques for earliest draft of DCCP, UDP, TCP, etc. However, it introduced a new
problem: "How does the server port relate authors wanted to address the Service Code?" The
intent was that the Service Code identified the application or
protocol using DCCP, providing middleboxes with information about the
intended use of a connection, and that the pair
issue of Published ports effectively
formed a 32-bit connection identifier, which was unique between in a
pair of end-systems. future-proof manner, since this method
suffers from several problems:

o The port space is not sufficiently large number of available unique Service Code values allows all
applications for ports to be assigned a unique Service Code. However, there
remains a current problem: The server port is chosen easily
allocated (e.g., in an unregulated manner). Thus, many
applications operate using unregistered ports, possibly colliding
with use by the server,
but the client needs to know this to establish a connection. It was
undesirable to mandate out-of-band communication to discover the
server port. A solution is to register DCCP server ports. other applications.

o The
limited availability use of DCCP server ports appears port-based firewalls encourages application writers to contradict the
benefits of DCCP Service Codes, because although it may be trivial
disguise one application as another in an attempt to
obtain a Service Code, it has not traditionally been trivial bypass
firewall filter rules. This motivates firewall writers to
obtain a registered port from IANA and use
deep packet inspection in the long-run it may not be
possible an attempt to uniquely allocate identify the service
associated with a unique registered DCCP port number.

o ISPs often deploy transparent proxies, primarily to new
applications. As improve
performance and reduce costs. For example, TCP requests destined
to TCP port numbers become scarce, this motivates the need 80 are often redirected to associate more than one Service Code with a listening port (e.g.
two different web proxy.

These issues are coupled. When applications could be assigned the same server port,
and need to run collide on the same host at the same time, differentiated by
their different associated Service Codes.

Service Codes provide flexibility in the
Published-but-unregistered port, there is no simple way clients identify the
server application to which they wish to communicate. The mechanism
allows a server for network
security equipment to associate a set of server ports with a service.
The set may tell them apart, and thus it is likely that
problems will be common with other services available at introduced through the same
server host, allowing a larger number interaction of concurrent connections for features.

There is little that a
particular service than possible when transport protocol designer can do about
applications that attempt to masquerade as other applications. For
ones that are not attempting to hide, the service is identified by problem may be simply that
they cannot trivially obtain a
single Published port. Ideally, it should be
sufficiently easy that every application writer can request a Well
Known or Registered port number.

There has been confusion concerning how server ports relate to
Service Codes. and receive one instantly with no questions
asked. The goal of this document 16-bit port space traditionally used is not large enough
to clarify this and the
issues concerning support such a trivial allocation of ports.

Thus, the use designers of Service Codes.

RFC4340 states that Service Codes are not intended to be DCCP-
specific. Service Codes, or similar concepts may therefore also DCCP sought an alternative solution. The idea
was simple. A 32-bit server port space should be
useful sufficiently large
to other IETF transport protocols.

1.2. Conventions used in this document enable use of very simple allocation policies. However, overhead
considerations made a 32-bit port value undesirable (DCCP needed to
be useful for low-rate applications).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" solution in DCCP to this
document are problem was to be interpreted as described in RFC 2119 [RFC2119].

2. An Architecture for use a 32-bit Service Codes

DCCP defines Code
[RFC4340] that is included only in the DCCP-Request packet. The use
of a combination of ports and Service Codes 32-bit value was intended to
identify make it trivially simple to obtain
a unique value for each application. Placing the server application ([RFC4340], section 8.1.2). These are
described value in a DCCP-
Request packet requires no additional overhead for the following Sections.

2.1. IANA Port Numbers

In DCCP, actual data
flow. It is however sufficient for both the packets belonging end systems, and
provides any stateful middleboxes along the path with additional
information to a connection understand what applications are de-multiplexed
based on a combination being used.

Early discussion of four values {source IP address, source
port, dest IP address, dest port}, as in TCP. An endpoint address is
associated with a port number, (e.g. forming the DCCP protocol considered an alternative to
the use of traditional ports; instead, it was suggested that a socket); and client
use a pair of
associations 32-bit identifier to uniquely identifies identify each connection. Ports provide the
fundamental per-packet de-multiplexing function.

The Internet Assigned Numbers Authority currently manages connection and that
the set of
globally reserved port numbers [IANA]. The source port associated
with server listen on a connection request, often known as socket bound only to a Service Code. This
solution was unambiguous; the "ephemeral port", is
traditionally in Service Code was the range 49152-65535, and also includes only identifier
for a listening socket at the range
1024-49151. server side. The value used DCCP client included
a Service Code in the request, allowing it to reach the corresponding
listening application. One downside was that this prevented
deployment of two servers for the ephemeral port same service on a single machine,
something that is usually chosen
by trivial with ports. The design also suffered from
the client operating system. It has been suggested 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.

RFC 4340 abandoned the use of a
randomized choice 32-bit connection identifier in favor
of two traditional 16-bit port number value can help defend against
"blind" attacks [ID.Rand] in TCP. values, one chosen by the server and
one by the client. This method may be applicable allows middleboxes to
other IETF-defined transport protocols, including DCCP.

Traditionally, utilize similar
techniques for DCCP, UDP, TCP, etc. However, it introduced a new
problem: "How does the destination (server) server port value associated with a
service is determined either by an operating system index relate to a copy
of the IANA table (e.g., getportbyname() in Unix, which indexes Service Code?" The
intent was that the
/etc/services file), Service Code identified the application or directly mapped by
protocol using DCCP, providing middleboxes with information about the application.

The UDP
intended use of a connection, and TCP port number space: 0..65535, is split into three
ranges [RFC2780]:

o 0..1023 "Well Known", also called "system" ports,

o 1024..49151 "registered", also called "user" ports,

o 49152..65535 "dynamic", also called "private" ports. that the pair of ports effectively
formed a 32-bit connection identifier, which was unique between a
pair of end systems.

The large number of available, unique Service Code values allows all
applications to be assigned a unique Service Code. However, there
remained a problem: the server port was chosen by the server, but the
client needed to know this port to establish a connection. It was
undesirable to mandate out-of-band communication to discover the
server port. The chosen solution was to register DCCP supports Well Known and registered server ports. These are allocated in
the
The limited availability of DCCP IANA port numbers registry ([RFC4340], Section 19.9). Each
registered server ports appears to contradict
the benefits of DCCP port MUST Service Codes because, although it may be associated with at least one pre-defined
trivial to obtain a Service Code.

Applications that do Code, it has not need traditionally been
trivial to use obtain a server Registered port from IANA and, in the Well Known
or registered range SHOULD use long-run,
it may not be possible to allocate a dynamic server unique Registered DCCP port (i.e. that does
not require to be registered in
new applications. As port numbers become scarce, this motivates the DCCP
need to associate more than one Service Code with a listening port registry). Clients can
identify
(e.g., two different applications could be assigned the same server
port value for and need to run on the services same host at the same time,
differentiated by their different associated Service Codes).

Service Codes provide flexibility in the way clients identify the
server application to which they wish to
connect using a range of methods. One common method is by reception
of a SDP record (Section 2.6) exchanged out-of-band (e.g. using SIP
[RFC3261] or RTSP [RFC2326]). DNS SRV resource records also provide communicate. The mechanism
allows a
way server to identify associate a set of server port ports with a service.
The set may be common with other services available at the same
server host, allowing a larger number of concurrent connections for a
particular service based on the
services string name [RFC2782].

Applications that do not use out-of-band signalling can still
communicate, providing that both client and server agree than possible when the service is identified by a
single Published port
value to be used. number.

1.2. Conventions Used in This eliminates the need for each registered
Service Code Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be allocated an IANA-assigned server port (see also
Section 2.7).

2.2. DCCP interpreted as described in RFC 2119 [RFC2119].

2. An Architecture for Service Code Values Codes

DCCP specifies defines the use of a 4 byte combination of ports and Service Code Codes to
identify the server application ([RFC4340], section 8.1.2)
represented Section 8.1.2). These
are described in one of three forms: the following sections.

2.1. IANA Port Numbers

In DCCP, the packets belonging to a decimal number (the canonical
method), connection are demultiplexed
based on a combination of four character ASCII string [ANSI.X3-4.1986], or an eight

digit hexadecimal number. All standards assigned Service Codes,
including all values assigned by IANA, are required to use {source IP address, source
port, dest IP address, dest port}, as in TCP. An endpoint address is
associated with a value
that may be represented using port number (e.g., forming a subset socket) and a pair of
associations uniquely identifies each connection. Ports provide the ASCII character set.
Private Service Codes do not need to follow this convention, although
RFC 4340 suggests that users also choose Service Codes that may also
be represented in ASCII.
fundamental per-packet demultiplexing function.

The Service Code identifies Internet Assigned Numbers Authority currently manages the application-level service to which a
client application wishes to connect. Examples of services are RTP
[ID.RTP], TIME (this document), ECHO (this document). In a different
example, DTLS [RFC5238] provides a transport-service (not an
application-layer service), therefore applications using DTLS are
individually identified by a set of corresponding Service Code
values.

Endpoints MUST associate a Service Code with every DCCP socket
[RFC4340], both actively and passively opened. The application will
generally supply this Service Code. A single passive listening
globally reserved port
may be associated with more than one Service Code value. numbers [IANA]. The set of
Service Codes could be source port associated
with one or more server
applications. This permits a more flexible correspondence between
services and port numbers than possible using the corresponding
socket pair (4-tuple of layer-3 addresses and layer-4 ports). In the
currently defined set of packet types, connection request, often known as the Service Code value "ephemeral port", is
present only
traditionally in DCCP-Request ([RFC4340], section 5.2) the range 49152-65535 and DCCP-
Response packets ([RFC4340], section 5.3). Note new DCCP packet types
(e.g. [ID.Simul]) could also carry a Service Code value.

2.2.1. New versions of Applications or Protocols

Applications/protocols that provide version negotiation or indication
in includes the protocol operating over DCCP do not require a new server port
or new Service Code range
1024-49151. The value used for each new protocol version. New versions of
such applications/protocols SHOULD continue to use the same Service
Code. If the application developers feel that ephemeral port is usually chosen
by the new version
provides significant new capabilities (e.g. client operating system. It has been suggested that will change the
behavior of middleboxes), they MAY allocate a new Service Code
randomized choice port number value can help defend against "blind"
attacks [Rand] in TCP. This method may be applicable to other IETF-
defined transport protocols, including DCCP.

Traditionally, the destination (server) port value associated with a
service is determined either by an operating system index that points
to a copy of the same IANA table (e.g., getportbyname() in Unix, which
indexes the /etc/services file) or by the application specifying a different set of
direct mapping.

The UDP and TCP port number space: 0..65535, is split into three
ranges [RFC2780]:

o 0..1023 "Well Known", also called "system" ports,

o 1024..49151 "Registered", also called "user" ports, and

o 49152..65535 "Dynamic", also called "private" ports.

DCCP supports Well Known and Registered ports. If These are allocated
in the new Service Code is DCCP IANA Port Numbers registry ([RFC4340], Section 19.9).
Each Registered DCCP port MUST be associated with at least one pre-
defined Service Code.

Applications that do not need to use a server port in the Well Known
or Registered range SHOULD use a Dynamic server port (i.e., one not
required to be registered
port, in the DCCP Ports registry MUST also be updated to include the new
Service Code value, but MAY share Port registry). Clients can
identify the same server port assignment(s).

2.3. Service Code Registry

The set of registered Service Codes specified value for use within the
general Internet are defined in an IANA-controlled name space. IANA
manages new allocations services to which they wish to
connect using a range of Service Codes in this space ([RFC4340]).
Private Service Codes are not centrally allocated and are denoted methods. One common method is by reception
of an SDP record (Section 2.6) exchanged out-of-band (e.g., using SIP
[RFC3261] or the decimal range 1056964608-1073741823 (i.e. 32-bit values with the
high-order byte equal Real Time Streaming Protocol (RTSP) [RFC2326]). DNS
SRV resource records also provide a way to identify a server port for
a particular service based on the service's string name [RFC2782].

Applications that do not use out-of-band signalling can still
communicate, provided that both client and server agree on the port
value of 63, corresponding to be used. This eliminates the ASCII
character '?').

Associations of need for each registered
Service Code with Well Known Ports are to be allocated to an IANA-assigned server port (see
also defined
in the IANA Section 2.7).

2.2. DCCP Port Registry (section 2.1).

2.4. Zero Service Code

A Values

DCCP specifies a 4-byte Service Code ([RFC4340], Section 8.1.2)
represented in one of zero is "permanently reserved (it represents the
absence of three forms: a meaningful decimal number (the canonical
method), a 4-character ASCII string [ANSI.X3-4.1986], or an 8-digit
hexadecimal number. All standards assigned Service Code)" [RFC4340]. This indicates Codes, including
all values assigned by IANA, are required to use a value that
no application information was provided. may be
represented using a subset of the ASCII character set. Private
Service Codes do not need to follow this convention, although RFC
4340 states suggests that
applications MAY users choose Service Codes that may also be associated with this
represented in ASCII.

The Service Code in identifies the same way
as other Service Code values. This use is permitted application-level service to which a
client application wishes to connect. For example, services have
been defined for any server
port.

This document clarifies section 19.8 of RFC 4340, by adding the
following:

"Applications SHOULD NOT use Real-Time Protocol (RTP) [RTP-DCCP]. In a
different example, Datagram Transport Layer Security (DTLS) [RFC5238]
provides a transport-service (not an application-layer service);
therefore, applications using DTLS are individually identified by a
set of corresponding Service Code of zero.

Application writers that need values.

Endpoints MUST associate a temporary Service Code value SHOULD
choose a value from the private range (section 2.3).

Applications intended for deployment in the Internet are encouraged
to use an IANA-defined with every DCCP socket
[RFC4340], both actively and passively opened. The application will
generally supply this Service Code. If no specific A single passive-listening port
may be associated with more than one Service Code
exists, they SHOULD request value. The set of
Service Codes could be associated with one or more server
applications. This permits a new assignment from more flexible correspondence between
services and port numbers than is possible using the IANA."

2.5. Invalid Service Code

RFC4340 defines corresponding
socket pair (4-tuple of layer-3 addresses and layer-4 ports). In the
currently defined set of packet types, the Service Code value of 0xFFFFFFFF as Invalid. This is provided so implementations can use a special four-byte value to
indicate "no valid Service Code". Implementations MUST NOT accept a
present only in DCCP-Request with this value, ([RFC4340], Section 5.2) and SHOULD NOT allow applications to
bind to this DCCP-
Response packets ([RFC4340], Section 5.3). Note that new DCCP packet
types (e.g., [RFC5596]) could also carry a Service Code value [RFC4340].

2.6. SDP for describing Service Codes

Methods value.

2.2.1. New Versions of Applications or Protocols

Applications/protocols that currently signal destination port numbers, such as provide version negotiation or indication
in the
Session Description Protocol (SDP) [RFC4566] require extension to
support protocol operating over DCCP Service Codes [ID.RTP].

2.7. A method to hash the Service Code to a Dynamic Port

Applications that do not use out-of-band signalling, or an IANA-
assigned port still require both the client and server to agree the
server port value to be used. This Section describes an optional
method that allows an application to derive a default new server port
number from
or new Service Code for each new protocol version. New versions of
such applications/protocols SHOULD continue to use the same Service
Code. The returned value is in If the dynamic
port range [RFC4340]:

int s_port; /* server port */
s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000;
if (s_port==0xFFFF) {s_port = 0xC000;}

Where sc[] represents application developers feel that the four bytes new version
provides significant new capabilities (e.g., that will change the
behavior of middleboxes), they MAY allocate a new Service Code
associated with the same or different set of Well Known ports. If
the new Service Code, and sc[3] Code is the least significant byte, for example this function associates
SC:fdpz associated with a Well Known or Registered
port, the server port 64634.

This algorithm has DCCP Ports registry MUST also be updated to include the following properties:

o It identifies a default new
Service Code value, but MAY share the same server port for each service.

o It seeks to assign different assignment(s).

2.3. Service Code Registry

The set of registered Service Codes to different ports, but
does not guarantee an assignment is unique.

o It preserves the four bits of the final bytes of specified for use within the Service Code,
allowing mapping common series
general Internet are defined in an IANA-controlled name space. IANA
manages new allocations of Service Codes to adjacent ports,
e.g. Foo1, and Foo2; and Fooa and Foob would be assigned adjacent
ports. (Note: this consecutive numbering only applies to
characters in the range 0-9 and A-O this space [RFC4340].
Private Service Codes are not centrally allocated and P-Z. When are denoted by
the characters
cross a decimal range boundary, 1056964608-1073741823 (i.e., 32-bit values with the algorithm introduces a discontinuity,
resulting in mapping
high-order byte equal to non-consecutive ports. Hence Fooo and Foop
respectively map a value of 63, corresponding to the decimal values ASCII
character '?').

Associations of 65015 and 65000).

o It avoids the port 0xFFFF, which is not accessible on all host
platforms.

Applications and higher-layer protocols that have been assigned a
Service Code (or use a Service Code from the unassigned private
space) may use this method. It does not preclude other applications
using the selected server port, since DCCP servers with Well Known ports are
differentiated by also defined
in the IANA DCCP Port registry (Section 2.1).

2.4. Zero Service Code value.

3. Use of the DCCP

A Service Code

The basic operation of Service Codes zero is as follows:

A client initiating a connection:

. issues a DCCP-Request with "permanently reserved (it represents the
absence of a meaningful Service Code and chooses a
destination (server) port number Code)" [RFC4340]. This indicates
that is expected to no application information was provided. RFC 4340 states that
applications MAY be associated with the specified this Service Code at the destination.

o A server that receives a DCCP-Request:

. determines whether an available service matching in the same way
as other Service Code values. This use is supported permitted for the specified destination any server
port.
The session is associated with

This document clarifies Section 19.8 of RFC 4340 by adding the
following:

Applications SHOULD NOT use a Service Code and of zero.

Application writers that need a
corresponding server. A DCCP-Response is returned.

. if temporary Service Code value
SHOULD choose a value from the service is not available, private range (Section 2.3).

Applications intended for deployment in the session is rejected and Internet are
encouraged to use an IANA-defined Service Code. If no specific
Service Code exists, they SHOULD request a
DCCP-Reset packet is returned.

3.1. Setting new assignment from the
IANA.

2.5. Invalid Service Codes at Code

RFC 4340 defines the Client

A client application MUST associate every DCCP connection (and hence
every DCCP active socket) with a single Service Code value
[RFC4340]). of 4294967295 in decimal
(0xFFFFFFFF) as "invalid". This value is used in the corresponding provided so implementations can
use a special 4-byte value to indicate "no valid Service Code".
Implementations MUST NOT accept a DCCP-Request
packet.

3.2. Using with this value, and
SHOULD NOT allow applications to bind to this Service Code value
[RFC4340].

2.6. SDP for Describing Service Codes in

Methods that currently signal destination port numbers, such as the Network
Session Description Protocol (SDP) [RFC4566], require an extension to
support DCCP connections identified by Service Codes [RTP-DCCP].

2.7. A Method to Hash the Service Code continue to a Dynamic Port

Applications that do not use IP
addresses and ports, although neither out-of-band signalling or an IANA-
assigned port number may be Published.

Port numbers and IP addresses are still require both the traditional methods client and server to identify
a flow within an IP network. Middlebox [RFC3234] implementors
therefore need to note that new DCCP connections are identified by agree on on
the pair of Server Port and Service Code in addition server port value to the IP
address. be used. This means section describes an optional
method that the IANA may allocate allows an application to derive a default server port to more
than one DCCP application [RFC4340].

Network address and port translators, known collectively as NATs
[RFC2663], may interpret DCCP ports [RFC2993] [ID.Behave-DCCP]. They
may also interpret DCCP Service Codes. Interpreting DCCP
number from the Service
Codes can reduce Code. The returned value is in the need to correctly interpret Dynamic
port numbers,
leading to new opportunities for network address and range [RFC4340]:

int s_port; /* server port
translators. Although it is encouraged to associate specific delivery
properties with */
s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000;
if (s_port==0xFFFF) {s_port = 0xC000;}

where sc[] represents the 4 bytes of the Service Code, e.g. to identify the real-time
nature of a flow that claims to be using RTP, there and sc[3] is no guarantee
that
the actual connection data corresponds to least significant byte. For example, this function associates
SC:fdpz with the associated server port 64634.

This algorithm has the following properties:

o It identifies a default server port for each service.

o It seeks to assign different Service
Code. A middlebox implementor may still use deep packet inspection,
and other means, in an attempt Codes to verify different ports, but
does not guarantee an assignment is unique.

o It preserves the content 4 lowest bits of a connection.

The use the final bytes of the DCCP Service Code can potentially lead to interactions
with other protocols that interpret or modify DCCP port numbers
[RFC3234]. The following additional clarifications update the
description provided in section 16
Code, which allows many common series of RFC 4340:

o "A middlebox that intends Service Codes to differentiate applications SHOULD
test be
mapped to a set of adjacent port numbers, e.g., Foo1, and Foo2;
Fooa and Foob would be assigned adjacent ports. (Note: this
consecutive numbering only applies to characters in the Service Code range 0-9
and A-O and P-Z. When the characters cross a range boundary, the
algorithm introduces a discontinuity, resulting in addition mapping to
non-consecutive ports. Hence, Fooo and Foop respectively map to
the destination or source
port decimal values of a DCCP-Request or DCCP-Response packet. 65015 and 65000).

o A middlebox It avoids the port 0xFFFF, which is not accessible on all host
platforms.

Applications and higher-layer protocols that have been assigned a
Service Code (or use a Service Code from the unassigned private
space) may use this method. It does not modify preclude other applications
using the intended application (e.g.
NATs [ID.Behave-DCCP] and Firewalls), MUST NOT change selected server port, since DCCP servers are differentiated
by the Service
Code.

o Code value.

3. Use of the DCCP Service Code

The basic operation of Service Codes is as follows:

A middlebox MAY send client initiating a DCCP-Reset in response to connection:

- issues a packet DCCP-Request with a Service Code and chooses a
destination (server) port number that is considered unsuitable."

3.3. Using Service Codes at the Server

The combination of expected to be
associated with the specified Service Code and at the destination.

A server port disambiguates
incoming DCCP-Requests received by that receives a server. The DCCP-Request:

- determines whether an available service matching the Service
Code is used
to associate a new DCCP connection with supported for the corresponding application
service. Four cases can arise when two DCCP specified destination server applications
passively listen on the same host:

o port.
The simplest case arises when two servers are associated with
different Service Codes and are bound to different server ports
(section 3.3.1).

o Two servers may be session is associated with the same DCCP Service Code
value, but be bound to different server ports (section 3.3.2).

o Two servers could use different DCCP Service Code values, and be
bound to a
corresponding server. A DCCP-Response is returned.

- if the same server port (section 3.3.1).

o Two servers could attempt to use service is not available, the same DCCP Service Code session is rejected and
bind to a
DCCP-Reset packet is returned.

3.1. Setting Service Codes at the same server port. Client

A DCCP implementation client application MUST disallow
this, since there is no way for the associate every DCCP host to direct a new connection to the correct server application.

RFC 4340 (section 8.1.2) states that an implementation:

o MUST associate each (and hence
every DCCP active socket socket) with exactly one Service Code on a specified server port.

In addition, section 8.1.2 also states:

o "Passive sockets MAY, at the implementation's discretion, be
associated with more than one single Service Code; this might let
multiple applications, or multiple versions of the same
application, listen on Code value
[RFC4340]). This value is used in the same port, differentiated by corresponding DCCP-Request
packet.

3.2. Using Service
Code."

This document updates this text Codes in RFC 4340 the Network

DCCP connections identified by replacing this with the following:

o "An implementation SHOULD allow more than one Service Code continue to be
associated with use IP
addresses and ports, although neither port number may be Published.

Port numbers and IP addresses are the traditional methods to identify
a passive server port, enabling multiple
applications, or multiple versions of flow within an application, IP network. Middlebox [RFC3234] implementors
therefore need to listen on
the same port, differentiated note that new DCCP connections are identified by
the associated Service Code."

It also adds:

o "An implementation SHOULD provide a method that informs a server pair of the Service Code value that was selected by an active
connection."

A single passively opened (listening) server port MAY therefore be
associated with multiple Service Codes, although an active (open)
connection can only be associated with a single Service Code. A
single application may wish to accept connections for more than one and Service Code using in addition to the same server port. IP
address. This means that the IANA may allow allocate a server port to
offer more
than the limit of 65,536 services determined by the size
of the Port field. The upper limit is based solely on the number of
unique connections between two hosts (i.e., 4,294,967,296).

3.3.1. Reception of a DCCP-Request

When a DCCP-Request is received, one DCCP application [RFC4340].

Network address and port translators, known collectively as NATs
[RFC2663], may interpret DCCP ports ([RFC2993] and [RFC5597]). They
may also interpret DCCP Service Codes. Interpreting DCCP Service
Codes can reduce the specified destination need to correctly interpret port numbers,
leading to new opportunities for network address and port
translators. Although it is not bound encouraged to a server, associate specific
delivery properties with the host MUST reject Service Code, e.g., to identify the connection by
issuing
real-time nature of a DCCP-Reset with Reset Code "Connection Refused". A host MAY
also use the Reset Code "Too Busy" ([RFC4340], section 8.1.3).

When the requested destination port is bound flow that claims to a server, the host
MUST also verify be using RTP, there is no
guarantee that the server port is associated with actual connection data corresponds to the
specified Service Code (there could be multiple Service Code values
associated with the same server port). Two cases can occur:

o If the receiving host is listening on a server port Service Code. A middlebox implementor may still use deep
packet inspection, and other means, in an attempt to verify the DCCP-
Request uses
content of a connection.

The use of the DCCP Service Code that is associated can potentially lead to interactions
with other protocols that interpret or modify DCCP port numbers
[RFC3234]. The following additional clarifications update the port, the
host accepts the connection. Once connected, the server returns a
copy
description provided in Section 16 of RFC 4340:

o A middlebox that intends to differentiate applications SHOULD
test the Service Code in addition to the destination or source
port of a DCCP-Request or DCCP-Response packet completing
the initial handshake [RFC4340]. packet.

o If the server port is A middlebox that does not associated with the requested Service
Code, modify the server SHOULD reject intended application
(e.g., NATs [RFC5597] and Firewalls) MUST NOT change the request by sending
Service Code.

o A middlebox MAY send a DCCP-Reset in response to a packet with Reset
a Service Code 8, "Bad that is considered unsuitable.

3.3. Using Service Code" ([RFC4340], Section
8.1.2), but MAY use Codes at the reason "Connection Refused".

After a connection has been accepted, Server

The combination of the protocol control block is
associated with a pair of ports and a pair of IP addresses and a
single Service Code value.

3.3.2. Multiple Associations of and server port disambiguates
incoming DCCP-Requests received by a server. The Service Code is
used to associate a new DCCP connection with Ports the corresponding
application service. Four cases can arise when two DCCP server
applications passively listen on the same host:

o The simplest case arises when two servers are associated with
different Service Codes and are not restricted bound to specific ports, although
they different server ports
(Section 3.3.1).

o Two servers may be associated with a specific well-known port. This allows the same DCCP Service Code
value but be bound to different server ports (Section 3.3.2).

o Two servers could use different DCCP Service Code values and be associated with more than one
bound to the same server port (in either (Section 3.3.1).

o Two servers could attempt to use the active or passive state).

3.3.3. Automatically launching a Server same DCCP Service Code and
bind to the same server port. A host DCCP implementation may permit MUST
disallow this, since there is no way for the DCCP host to
direct a service new connection to be associated the correct server application.

RFC 4340 (Section 8.1.2) states that an implementation:

o MUST associate each active socket with exactly one Service Code
on a specified server port (or range port.

In addition, Section 8.1.2 of ports) that is not permanently running RFC 4340 also states:

o Passive sockets MAY, at the server. In implementation's discretion, be
associated with more than one Service Code; this case, the arrival might let
multiple applications, or multiple versions of a DCCP-Request may require a
method to associate a DCCP-Request with a server that handles the
corresponding Service same
application, listen on the same port, differentiated by Service
Code.

This operation could resemble that of
"inetd" [inetd].

As in document updates the previous Section, when above text from RFC 4340 by replacing it
with the specified following:

o An implementation SHOULD allow more than one Service Code is not to be
associated with the specified a passive server port, the connection MUST be
aborted and a DCCP Reset message sent [RFC4340].

4. Security Considerations

The security considerations enabling multiple
applications, or multiple versions of RFC 4340 identifies and offers
guidance on security issues relating an application, to DCCP. This document discusses listen
on the usage of same port, differentiated by the associated Service Codes.
Code.

It does not describe new protocol
functions.

All IPsec modes protect the integrity also adds:

o An implementation SHOULD provide a method that informs a server
of the DCCP header. This
protects the Service Code field from undetected modification within
the network. In addition, the IPsec Encapsulated Security Payload
(ESP) mode may value that was selected by an active
connection.

A single passively opened (listening) port MAY therefore be used
associated with multiple Service Codes, although an active (open)
connection can only be associated with a single Service Code. A
single application may wish to encrypt the accept connections for more than one
Service Code field, hiding using the
Service Code value within same server port. This may allow a server to
offer more than the network and also preventing
interpretation by middleboxes. limit of 65,536 services depending on the size of
the Port field. The DCCP header upper limit is not protected by
application-layer security, (e.g., based solely on the use DTLS [RFC5238] as
specified in DTLS/DCCP [RFC4347]).

There are four areas of security that are important:

1. Server Port number reuse (section 5.1).

2. Interaction with NATs and firewalls (section 3.2 describes
middlebox behaviour). Requirements relating to DCCP are described
in [ID.Behave-DCCP].

3. Interpretation of DCCP Service Codes over-riding traditional use
unique connections between two hosts (i.e., 4,294,967,296).

3.3.1. Reception of reserved/Well Known port numbers (Section 5.2).

4. Interaction with IPsec a DCCP-Request

When a DCCP-Request is received and DTLS security (section 5.3).

4.1. Server Port number re-use

Service Codes are used in addition to ports when demultiplexing
incoming connections. This changes the service model specified destination port is
not bound to be used a server, the host MUST reject the connection by
applications and middleboxes. The port-numbers registry already
contains instances of multiple application registrations for issuing
a single DCCP-Reset with the Reset Code "Connection Refused". A host MAY
also use the Reset Code "Too Busy" ([RFC4340], Section 8.1.3).

When the requested destination port number for TCP and UDP. These are relatively rare. Since is bound to a server, the
DCCP host
MUST also verify that the server port is associated with the
specified Service Code allows (there could be multiple applications to safely share Service Code values
associated with the same port number, even on server port). Two cases can occur:

o If the same host, receiving host is listening on a server port number reuse in
DCCP may be more common than in TCP and UDP.

4.2. Association of applications with Service Codes

The use of the DCCP-
Request uses a Service Codes provides more ready feedback Code that a concrete
service is associated with the port, the
host accepts the connection. Once connected, the server returns a given port on a servers, than for a
service that does not employing service codes. By responding to an
inbound connection request, systems not using these codes may
indicate that some service is, or is not, available on a given port,
but systems using this mechanism immediately provide confirmation (or
denial) that a particular service is present. This may have
implications in terms
copy of port scanning and reconnaissance.

Care needs to be exercised when interpreting the mapping of a Service Code value to in the corresponding service. The same service
(application) may be accessed using more than one DCCP-Response packet, completing
the initial handshake [RFC4340].

o If the server port is not associated with the requested Service Code.
Examples include
Code, the server SHOULD reject the request by sending a DCCP-Reset
packet with the Reset Code 8, "Bad Service Code" ([RFC4340],
Section 8.1.2), but MAY use the reason "Connection Refused".

After a connection has been accepted, the protocol control block is
associated with a pair of separate Service Codes for an application
layered directly upon DCCP ports, a pair of IP addresses, and one using DTLS transport over DCCP
[RFC5238]. Other possibilities include the use a single
Service Code value.

3.3.2. Multiple Associations of a private Service Code that maps with Ports

DCCP Service Codes are not restricted to specific ports, although
they may be associated with a specific Well Known port. This allows
the same application as assigned to an IANA-defined DCCP Service Code value, or a single application that provides value to be associated with more than one service. Different versions of
server port (in either the active or passive state).

3.3.3. Automatically Launching a service (application) Server

A host implementation may also
be mapped permit a service to be associated with a corresponding set of Service Code values.

Processing of Service Codes may imply more processing than currently
associated with incoming
server port numbers. Implementers need to guard
against increasing opportunities for Denial (or range of Service attack.

4.3. Interactions with IPsec

The Internet Key Exchange protocol (IKEv2), does ports) that is not currently
specify permanently running at
the server. In this case, the arrival of a DCCP-Request may require
a method to use DCCP Service Codes as associate a part of the
information used to setup an IPsec security association.

IPsec uses port numbers to perform access control in transport mode
[RFC4301]. Security policies can define port-specific access control
(PROTECT, BYPASS, DISCARD), as well as port-specific algorithms and
keys. Similarly, firewall policies allow or block traffic based on
port numbers.

Use of port numbers in IPsec selectors and firewalls may assume DCCP-Request with a server that handles the numbers correspond to Well Known services. It is useful to note
corresponding Service Code. This operation could resemble that there is no such requirement; any service may run on any port,
subject to mutual agreement between the endpoint hosts. Use of
"inetd" [inetd].

As in the previous section, when the specified Service Code may interfere is not
associated with this assumption both within IPsec the specified server port, the connection MUST be
aborted and
in other firewall systems, but it does not add a new vulnerability.
New implementations DCCP Reset message sent [RFC4340].

4. Security Considerations

The security considerations of IPsec RFC 4340 identify and firewall systems may interpret offer guidance
on security issues relating to DCCP. This document discusses the
usage of Service Code when implementing policy rules, but should Codes. It does not rely on
either port numbers or Service Codes to indicate a specific service.

5. IANA Considerations

This document does not update describe new protocol functions.

All IPsec modes protect the IANA allocation procedures for integrity of the DCCP Port Number and DCCP Service Codes Registries as defined in RFC
4340.

For completeness, header. This
protects the 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 field from undetected modification within
the network. In addition, the IPsec Encapsulated Security Payload
(ESP) mode may be used to request encrypt the Service Code values via field, hiding the IANA
Considerations Section. A specification is however required to
allocate a
Service Code that uses a combination of ASCII digits,
uppercase letters, and character space, '-', '.', and '/') [RFC4340].

6. Acknowledgments

This work has been supported by value within the EC IST SatSix Project.
Significant contributions to this document resulted from discussion
with Joe Touch, network and this is gratefully acknowledged. The author also
thanks Ian McDonald, Fernando Gont, Eddie Kohler, and the preventing
interpretation by middleboxes. The DCCP WG for
helpful comments on this topic, and Gerrit Renker for his help header is not protected by
application-layer security (e.g., the use of DTLS [RFC5238] as
specified in
determining DCCP behaviour and review DTLS/DCCP [RFC4347]).

There are four areas of this document. Mark Handley
provided significant input security that are important:

1. Server Port number reuse (Section 4.1).

2. Interaction with NATs and firewalls (Section 3.2 describes
middlebox behavior). Requirements relating to the text on definition DCCP are described
in [RFC5597].

3. Interpretation of DCCP Service Codes
and their usage. He also contributed much of the material that has
formed the historical background Section.

7. References

7.1. Normative References

[RFC1122] Braden, R. (ed.), "Requirements for Internet Hosts:
Communication Layers, " STD 3, RFC 1122, Oct. 1989
(STANDARD).

[RFC2119] Bradner, S., "Key words for overriding traditional use of
reserved/Well Known port numbers (Section 4.2).

4. Interaction with IPsec and DTLS security (Section 4.3).

4.1. Server Port Number Reuse

Service Codes are used in RFCs addition to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 (BEST
CURRENT PRACTICE).

[RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, Mar. 2006 (PROPOSED
STANDARD).

[ID.Behave-DCCP] R. Denis-Courmont, "Network Address Translation
(NAT) Behavioral Requirements ports when demultiplexing
incoming connections. This changes the service model to be used by
applications and middleboxes. The Port Numbers registry already
contains instances of multiple application registrations for DCCP", IETF Work in
Progress, draft-ietf-behave-dccp-05.txt.

7.2. Informative References

[ANSI.X3-4.1986] American National Standards Institute, "Coded
Character Set - 7-bit American Standard Code a single
port number for
Information Interchange", ANSI X3.4, 1986.

[IANA] Internet Assigned Numbers Authority, www.iana.org

[IANA.SC] IANA TCP and UDP. These are relatively rare. Since the
DCCP Service Code Registry
http://www.iana.org/assignments/service-codes

[ID.Simul] G. Fairhurst, G. Renker, "DCCP Simultaneous-Open Technique allows multiple applications to Facilitate NAT/Middlebox Traversal", IETF Work in
Progress, draft-ietf-dccp-simul-open-08.txt.

[ID.RTP] C. Perkins, "RTP and safely share the Datagram Congestion Control
Protocol (DCCP)", IETF Work
same port number, even on the same host, server port number reuse in Progress, draft-ietf-dccp-
rtp-07.txt.

[ID.Rand] M. Larsen, F. Gont, "Port Randomization", IETF Work
DCCP may be more common than in
Progress, draft-larsen-tsvwg-port-randomization-02.txt

[inetd] TCP and UDP.

4.2. Association of Applications with Service Codes

The extended inetd project, http://xinetd.org/

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, Sept. 1981 (STANDARD).

[RFC814] Clark, D., "NAME, ADDRESSES, PORTS, AND ROUTES", RFC 814,
July 1982 (UNKNOWN).

[RFC862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.

[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time

Streaming Protocol (RTSP)", RFC 2326, April 1998.

[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999.

[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.

[RFC2993] Hain, T., "Architectural Implications use of NAT", RFC 2993,
November 2000.

[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-
Lite)", RFC 3828, July 2004.

[RFC4301] Kent, S. and K. Seo, "Security Architecture Service Codes provides more ready feedback that a concrete
service is associated with a given port on a server than for the
Internet Protocol", RFC 4301, December 2005.

[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol RFC
4960, September 2007.

[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)", RFC 5238,
May 2008.

8. Author's Addresses

Godred (Gorry) Fairhurst,
School of Engineering,
University of Aberdeen,
Kings College,
Aberdeen, AB24 3UE,
UK
Email: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry

8.1. Disclaimer

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may a
service that does not have granted the IETF Trust the right employ Service Codes. By responding to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may
inbound connection request, systems not be modified
outside the IETF Standards Process, and derivative works of it using these codes may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC
indicate that some service is, or to translate it into languages other
than English.

8.2. Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect not, available on the date of
publication of a given port,
but systems using this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights mechanism immediately provide confirmation (or
denial) that a particular service is present. This may have
implications in terms of port scanning and restrictions with respect to this document.

>>> RFC Editor please remove this Section prior reconnaissance.

Care needs to publication.

Change Log.

01 introduced:

- a replacement of the word *range* be exercised when referring to sets of dccp
ports (they are not necessarily contiguous), noted by E. Kohler.

- Addition interpreting the mapping of some a Service Codes in IANA Section.

02 introduced:

- add
Code value to the corresponding service. The same service
(application) may be accessed using more than one Service Code.
Examples include the use of profiles with DCCP, identified by separate Service Code, but
not Codes for an application
layered directly upon DCCP and one using DTLS transport over DCCP
[RFC5238]. Other possibilities include the use of protocol variants.

- further detail on implementation levels (more input would be good)

- added security consideration for traffic generators

- added ref to UDPL for completeness

- Corrected NiTs found by Gerrit Renker

+++++++++++++++++++++++++++

WG 00 (first WG version)

This introduced revisions to make it a WG document.

- Corrected language and responded private Service
Code to many helpful comments from
Fernando Gont and Ian McDonald.

- Added a test for which server behaviour is used.

- Added some speculative text on how map to implement the SC.

- More input and discussion is requested from the WG.

- Added an informative appendix on host configuration.

- Merging of some Sections to remove repetition and clarify wording.

+++++++++++++++++++++++++++
WG 01

Historical material was added.

Comments from the list have application that has already been included.

The concept assigned an IANA-
defined Service Code value, or multiple Service Code values that map
to a single application providing more than one service. Different
versions of adding weak semantics a service (application) may also be mapped to a SC=0 was removed. This was
added at the request
corresponding set of implementers, with the aim Service Code values.

Processing of offering easier
implementation on at least one target platform. It has been removed
in this document because it weakens interoperability and complicates
the Spec.

The proposal Service Codes may imply more processing than currently
associated with incoming port numbers. Implementors need to allow several levels guard
against increasing opportunities for Denial of support was introduced in
previous drafts following suggestions from the WG, but was removed in
this revision. Service attacks.

4.3. Interactions with IPsec

The Internet Key Exchange protocol (IKEv2) does not currently specify
a method was seen to introduce complexity, and
resulted in complex interoperability scenarios.

Removed "test" method, this was no longer required.

Draft was reorganized use DCCP Service Codes as a part of the information used
to improve clarity and simplify concepts.

----

WG 02

Updated following comments from Eddie Kohler.

----

WG 03

Fixed NiTs and addressed issues marked set up an IPsec security association.

IPsec uses port numbers to perform access control in previous version.

Added 2 para at end transport mode
[RFC4301]. Security policies can define port-specific access control
(PROTECT, BYPASS, DISCARD) as well as port-specific algorithms and
keys. Similarly, firewall policies allow or block traffic based on
port numbers.

Use of port Section saying how numbers in IPsec selectors and firewalls may assume that
the numbers correspond to use Well Known
ports and that you do not need services. It is useful to register them.

-----

WG 04

Cleaned English (removing duplication)

Checked text note
that updates RFC4340 (and remove duplicates).

Updated hash algorithm for SC->s_port

Updated to IANA Section.

Edits in response there is no such requirement; any service may run on any port,
subject to feedback from Tom Phelan, et al.

-----

WG-05:

Various Sections were updated following feedback from the list, some
specific comments were:

Tom Phelan suggested clarification was needed for mutual agreement between the usage endpoint hosts. Use of well-
known ports in Section 1, and various other clarifications.

Eddie Kohler suggested reworking the midbox Section.

Eddie noted the hash function included the highest numbered port,
which is not accessible on all OS.

There was also discussion about the proper server port range to be
used
Service Code may interfere with this method. After previous concerns that using registered
ports could have some (unknown) side effect, use was recommended in
the dynamic range. Text was added to this Section.

Discussions at IETF-71 lead to the idea to removing assumption both within IPsec and
within other firewall systems, but it does not add a new
vulnerability. New implementations of IPsec and firewall systems may
interpret the IANA guidance Service Code when implementing policy rules, but should
not rely on maintaining the registries either port numbers or Service Codes to indicate a new
specific service.

5. IANA Considerations

This document that defines the
policy across the set of transport registries.

Eddie noted that port-reuse is likely to be more common with DCCP
(security considerations).

Lars noted that rate-limiting benchmarking tools may be somewhat
undesirable, and this related to services for testing.

The text recommending an does not update to the IANA allocation procedures for ports and
service codes has been moved to a TSV WG draft.

-----

WG-06:

Updated the updating paragraphs to clarify the specific clauses of
RFC 4340 are changed. Comments from Eddie and Colin.

Very minor editorial corrections.

-----

WG-07:

Portname for Perf in registry changed to all lower case.

Replaced para 2 of intro and updated later parts of the introduction
(feedback in LC from Eddie).

Added citation to the Behave WG Requirements for NATs (now in LC).

-----

WG-08:

New text to address editorial corrections proposed by Alfred Hoenes.

-----

WG-09:Update following review feedback

Gen-ART

Section 3.2: Middlebox [RFC3234] implementors therefore need to note
that new
DCCP connections are identified by the pair of Server Port Number and DCCP Service Code. - Added "in addition to the IP address" to the end
of Codes Registries as defined in RFC
4340.

For completeness, the above sentence for clarity.

Section 3.2: Updated sentence to read: This means document notes that the IANA may
allocate it is not required to
supply an approved document (e.g., a server port published RFC) to more than one DCCP support an
application [RFC4340].

Section 3.3.2 rewritten as: for a DCCP Service Codes are not restricted to
specific ports, Code or port number value, although they
RFCs may be associated with a specific well-
known port. The same DCCP used to request Service Code value may therefore be
associated with more than one server port (in either values via the active or
passive state).

Section 5.3: Added: The Internet Key Exchange protocol (IKEv2), does
not currently specify a method IANA
Considerations section. A specification is however required to use DCCP
allocate a Service Codes as Code that uses a part combination of ASCII digits,
uppercase letters, and character space, '-', '.', and '/') [RFC4340].

6. Acknowledgments

This work has been supported by the information used EC IST SatSix Project.
Significant contributions to setup an IPsec security association.

Sec-Dir

Section 5: Added: this document resulted from discussion
with Joe Touch, and this is gratefully acknowledged. The security considerations of RFC 4340 identifies author also
thanks Ian McDonald, Fernando Gont, Eddie Kohler, and offers guidance the DCCP WG for
helpful comments on security issues relating this topic, and Gerrit Renker for his help in
determining DCCP behavior and review of this document. Mark Handley
provided significant input to DCCP.

Section 5.2: Added new paragraph: The use the text on the definition of Service
Codes provides
more ready feedback and their usage. He also contributed much of the material that a concrete service is associated with a
given port on a servers, than
has formed the historical background section.

7. References

7.1. Normative References

[RFC1122] Braden, R., Ed., "Requirements for a service that does not employing
service codes. By responding Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.

[RFC2119] Bradner, S., "Key words for use in RFCs to an inbound connection request,
systems not using these codes may indicate that some service is, or
is not, available on a given port, but systems using this mechanism
immediately provide confirmation (or denial) that a particular
service is present. This may have implications Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT)
Behavioral Requirements for the Datagram Congestion
Control Protocol", BCP 150, RFC 5597, July 2009.

7.2. Informative References

[ANSI.X3-4.1986]
American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.

[IANA] Internet Assigned Numbers Authority, www.iana.org.

[RTP-DCCP] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", Work in terms of port
scanning Progress, June 2007.

[Rand] Larsen, M. and reconnaissance.

-----

WG-10:Update following IESG review feedback

Typo reported by Iain Calder was fixed: simply to obtain
s/simply/simple/.

Fixed syntax error reported by Jari F. Gont, "Port Randomization", Work in
Progress, March 2009.

[inetd] The extended inetd project, http://xinetd.org.

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.

[RFC814] Clark, D., "Name, addresses, ports, and routes", RFC 814,
July 1982.

[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.

[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.

[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the sample pseudo code, Internet Protocol and
added more discussion of Related Headers", BCP
37, RFC 2780, March 2000.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the algorithm.

A clarification location of ASCII usage, suggested by:

Added text: /a four character ASCII string [ANSI.X3-4.1986], or an
eight digit hexadecimal number. All standards assigned values,
including all values assigned by IANA, are required to use a value
that may be represented using a subset services (DNS SRV)", RFC 2782,
February 2000.

[RFC2993] Hain, T., "Architectural Implications of the ASCII character set.
Private Service Codes do not need to follow this convention, although NAT", RFC 2993,
November 2000.

[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 4340 suggests that users also choose Service Codes that may also
be represented in ASCII./

Added new informational reference:

American National Standards Institute, "Coded

Character Set - 7-bit American Standard Code 3261,
June 2002.

[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, July 2004.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for

Information Interchange", ANSI X3.4, 1986.

URL to iperf changed, since we note CAIDA intends to shutdown all
services associated with the NLANR.NET domain in May 2009.

section 3.3 changed to correct section references (error noted by
Ralph Droms)
Internet Protocol", RFC 4301, December 2005.

[RFC4347] Rescorla, E. and additional text added to clarify sections 3.3.1 N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.

[RFC4566] Handley, M., Jacobson, V., and
3.3.2. New text includes:

/The combination of C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.

[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Service Code and server port disambiguates
incoming DCCP-Requests received by a server. The Service Code is used Datagram Congestion Control Protocol (DCCP)", RFC
5238, May 2008.

[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol
(DCCP) Simultaneous-Open Technique to associate a new DCCP connection with the corresponding application
service. Four cases can arise when two DCCP server applications
passively listen on the same host:/
WG-11: Update following discussion with AD

After discussion, the section on benchmarking was removed, and will
be addressed separately.

Note: This I-D will be a normative reference in draft-ietf-dccp-
simul-open. Facilitate
NAT/Middlebox Traversal", RFC 5596, June 2009.

Author's Address

Godred Fairhurst,
School of Engineering,
University of Aberdeen,
Kings College,
Aberdeen, AB24 3UE,
UK
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry