Internet Relay Chat (IRC) Client to Client Protocol (DCC2) Connection Negotiation

The Direct Client Connection 2.0 (DCC2) is a specification currently under development by the IRC Client Author's community. DCC2 creates a framework for standardized connection negotiation between IRC clients. DCC2's design allows clients to automatically negotiate acceptable connection parameters, and makes it possible for users' clients to review the parameters and automate decision-making in the connection negotiation process. For more information on the DCC2 please consult the DCC2 community documentation.

The current DCC protocol does not address IPv4 vs. IPv6 issues, SSL/TLS encryption negotiation, NAT and Firewall traversal, or multiple file/directory file transfers. Historic DCC file transfers are also flawed in requiring acknowledgement of received bytes during the transfer, something that the underlying TCP protocol already ensures. Many IRC clients have implemented extensions that attempt to solve these problems, but the result has been fragmentation of the historic DCC protocol. This fragmentation is to a point where only the most simple functions work between different clients. DCC2 has been introduced to solve these problems and insure interoperability between all IRC clients. The DCC2 negotiation system has also been designed to be extensible to incorporate future technological developments more easily that the original IRCII DCC implementation.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" in this document are to be interpreted as described in RFC-2119.

DCC2 allows IRC clients to negotiate connection settings using a handshake mechanism for agreement to protocol usage. Protocols available on the offering client are published to the receiving client. The receiving client may then reply to the offering client, listing the subset of the available protocols that must be used. The receiving client also has the option to open the connection if the offering client cannot accept incoming connections. The available protocols and options are presented as a list of case-insensitive, space separated tokens or token=value pairs. These tokens are standardized and listed here. Additional tokens can be added through the DCC2.org community process.

All DCC2 messages are encapsulated in a IRC PRIVMSG from one user to another, or from one user to a channel. The message portion of the PRIVMSG should begin and end with an octal \001 character.

PRIVMSG nickname :/001DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=10a/001

Specifies a list of possible network layers for the connection. Possible values include IPV4 and IPV6.

Network=IPv4,IPv6

Specifies a list of possible transport layers for the connection. Possible values include TCP, SCTP and UDP

Transport=Tcp

Specifies a list of possible encryption layers for this connection. Some possible values include SSL3 and TLS

TransportSecurity=SSL3,TLS

Specifies the common application service for this connection. There are many possible values for this token. Some possible values include IRCChat and IRCFile

Application=IRCFile

Specify that incoming connections are not available. This token never has a value.

Specify a session identifier for this negotiation. It may be possible to infer a session from a user, ip, or file information, however a session token must always be used to avoid ambiguity, especially with multiple concurrent negotiations to the same client since refusals can be silently ignored. This token must have a unique value for each negotiation with a remote user.

Specifies an IPv4 interface is present. When associated with a value, the IPV4 token specifies an IPv4 IP address in dotted-quad notation that can be connected to on a machine.

; an IPv4 IP address in dotted-quad notation IPv4Address = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit ; example IPv4=192.168.23.43

Specifies that an IPv6 interface is present. When associated with a value, the IPV6 token specifies an IPv6 IP address in colon-hexadecimal notation that can be connected to on a machine.

;an IPv6 IP address in colon-hexadecimal notation IPv6Address = hexseq | hexseq "::" [hexseq] | "::" [hexseq] hexseq = hex4 *( ":" hex4 ) hex4 = 1*4hexdig ; example IPv6=::C0A8:6464

The port to connect to on the IPV4 and IPV6 addresses offered. The PORT token always has a value.

Port=9834

Specifies the specific connection tokens that caused the error.

ErrorTokens=Network,TransportSecurity

Specifies a user defined description of why the connection was refused or failed.

ErrorMessage="I do not trust you."

Specify the file name being sent. No directory information is included. If the filename contains spaces, it must be surrounded by double quotes. Limited to a single file transfer per session. Please see the ABNF for specific allowed characters.

File="my file.txt"

Specify the size of a FILE in bytes

Size=93424

A byte offset at which to resume the FILE.

Offset=7543

Specify that file name descriptions and sizes will be specified over the connection. The value is the size in bytes of the Multi XML file.

Multi=9874

The offering client sends a message encapsulated using CTCP indicating the DCC2 options and connection settings supported by the client. Connection tokens without values are sent to the receiving client to indicate options that are supported. The Application, Network, and Sid tokens are always required in a publication message. Using the += delimiter marks a token group as optional. Additional application level tokens can be sent along with the publication tokens. DCC2 file transfer tokens are sent with values to give the receiving client the context of the transfer. This file context is needed if the receiving client opens the listening connection due to NAT negotiation.

The DCC2 publication of connection negotiation parameters allows the client to advertise its supported protocols. The syntax follows, specified using ABNF rules (as per RFC2234):

; Publication string, includes connection tokens and any optional application tokens dcc2-publish = `DCC2` 1*(space (ConnectionTokens | AppTokens)) ; one or more of the connection tokens ConnectionTokens = ConnectionToken [ 1* (space ConnectionToken)] ; one of more application specific tokens AppTokens = Apptoken [ 1* (space AppToken) ] ; a connection token, optionally followed by a list of supported tokens. ConnectionToken = 1*TokenChars [ ('=' | '+=' ) 1*TokenChars [ 1* (',' 1*TokenChars) ] ] AppToken = 1*TokenChars [ ('=' | '+=' ) dcc2-quotedname ] TokenChars = 1* (digit | alpha) ; any valid filename chars, double quotes are optional. necessary with spaces. dcc2-quotedname = 1*filechar | (%d34 1*(filechar | space ) %d34) filechar = digit | alpha | filepunct ; valid file punct. !#$%&'()+,-.=@[]^_{}~ filepunct = %d33 %d35-41 %d43-46 %d61 %d64 %d91 %d93-95 %d123 %d125-126

Proposing a chat session negotiation, with either IPv4 or IPv6 and two optional encryption schemes available DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity+=SSL3,TLS1 SID=1

Proposing a chat session negotiation, with only IPv6 available DCC2 Application=IRCChat Network=IPv6 SID=1

Proposing a chat session negotiation, with only IPv4 available and the offering client cannot accept incoming connections DCC2 Application=IRCChat Network=IPv4 NAT SID=1

Proposing a file transfer session negotiation, with either IPv4 or IPv6 and two manditory encryption schemes available DCC2 Application=IRCFile Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=1 Filename="some file.txt" Size=3423

Proposing a file transfer session negotiation, with only IPv6 available DCC2 Application=IRCFile Network=IPv6 SID=1 Filename=somefile.txt Size=3423

Proposing a file transfer session negotiation, with only IPv4 available and the offering client cannot accept incoming connections DCC2 Application=IRCFile Network=IPv4 NAT SID=1 Filename="somefile.txt" Size=3423

Proposing a file transfer session negotiation, with only IPv4 available and using the DCC2 out of band file descriptions DCC2 Application=IRCFile Network=IPv4 SID=1 Multi=983

The receiving client sends a DCC2 Accept message encapsulated using CTCP indicating the DCC2 options and connection settings that must be used for the transfer. This group of settings is a subset of the published parameters. Connection tokens without values may be sent to the offering client to indicate the protocols to be used. If the offering client indicates it can not accept incoming connections, the receiving client should create a listening port on a supported interface, using the subset of the published parameters. The receiving client should then send the connection parameters with appropriate values to the offering client. If neither the receiving or offering client can accept incoming connections, or can not agree on a common interface, a DCC2 CANNOTACCEPT message may be sent. The CannotAccept message must include the SID and ErrorTokens, and may include an ErrorMessage. If the receiving client denies the connection negotiation, the received publication message can be silently ignored or a DCC2 REFUSED message may be sent. The Refused message must include the SID, and may include an ErrorMessage.

The DCC2 acceptance of connection negotiation parameters allows the clients to find common supported protocols. The syntax follows, specified using ABNF rules (as per RFC2234):

; A DCC2 accept message, or a failure message with the SID dcc2-response = 'DCC2' space ( 'Accept' | 'CannotAccept' | 'Refused' ) 1*(space Token) Token = 1*TokenChars [ '=' dcc2-quotedname ]

Accepting a chat session negotiation, with either IPv4 or IPv6 and two encryption schemes available offering client sent: DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity+=SSL3,TLS1 SID=1 receiving client would like to use IPv6 and TLS1 encryption sends: DCC2 Accept IPv6 TLS1 SID=1 receiving client would like to use IPv4 and no encryption sends: DCC2 Accept IPv4 SID=1

Accepting a chat session negotiation, with only IPv6 available offering client sent: DCC2 Application=IRCChat Network=IPv6 SID=2 receiving client would like to use IPv6 DCC2 Accept IPv6 SID=2 receiving client does not have IPV6, and no IPV4 endpoint was offered DCC2 CannotAccept SID=2 ErrorTokens=Network

Accepting a chat session negotiation, with only IPv4 available and the offering client cannot accept incoming connections offering client sent: DCC2 Application=IRCChat Network=IPv4 NAT SID=1 receiving client will create an IPv4 connection: DCC2 Accept IPv4=192.168.100.100 Port=7323 SID=1 receiving client can not accept incoming connections either: DCC2 CannotAccept SID=1 ErrorTokens=NAT

Accepting a file transfer session negotiation, with either IPv4 or IPv6 and two encryption schemes available offering client sent: DCC2 Application=IRCFile Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 Filename="some file.txt" Size=3423 SID=2 receiving client would like to use IPV4 and SSL3: DCC2 Accept IPv4 SSL3 Filename="some file.txt" Size=3423 SID=2

Accepting a file transfer session negotiation, with only IPv6 available offering client sent: DCC2 Application=IRCFile Network=IPv6 Filename=somefile.txt Size=3423 SID=a receiving client will accept the transfer and resume a download: DCC2 Accept IPv6 Filename=somefile.txt Size=3423 Offset=1202 SID=a receiving client cannot accept IPV6: DCC2 CannotAccept SID=a ErrorTokens=Network receiving client refuses the file: DCC2 Refused SID=a ErrorMessage="We've already got one!"

Accepting a file transfer session negotiation, with only IPv4 available and the offering client cannot accept incoming connections offering client sent: DCC2 Application=IRCFile Network=IPv4 NAT Filename="somefile.txt" Size=3423 SID=1 receiving client will accept the transfer and open a listening connection: DCC2 Accept IPv4=192.168.23.342 PORT=8732 Filename="somefile.txt" Size=3423 SID=1 receiving client can not accept incoming connections either: DCC2 CannotAccept SID=1 ErrorTokens=NAT

Accepting a file transfer session negotiation, with only IPv4 available and using the DCC2 out of band file descriptions offering client send: DCC2 Application=IRCFile Network=IPv4 Multi=983 SID=1 receiving client will accept the file transfer: DCC2 Accept IPv4 Multi=983 SID=1 receiving client does not support multi-file transfers: DCC2 CannotAccept SID=1 ErrorTokens=Multi

The offering client receives a DCC2 ACCEPT message encapsulated using CTCP indicating the DCC2 options and connection settings that will be used for the transfer. If the connection parameters have values, the receiving client is listening for a connection. The offering client will connect to the specified port. There is no need for an additional CTCP message If the connection parameters do not have associated values, the offering client creates a listening socket using the protocols dictated by the ACCEPT message. The Offering client then sends another DCC2 Accept message using the parameters associated with the listening socket.

The DCC2 negotiation parameters have been specified to use a common supported protocol. The syntax specified using ABNF rules (as per RFC2234) is documented in the previous section.

Finalizing a chat session negotiation, using IPv6 and TLS1 receiving client would like to use IPv6 and TLS1 encryption sends: DCC2 Accept IPv6 TLS1 SID=1 offering client sends: DCC2 Accept IPv6=::C0A8:6464 Port=8543 TLS1 SID=1

Finalizing a chat session negotiation, with only IPv6 available receiving client would like to use IPv6 DCC2 Accept IPv6 SID=1 offering client sends: DCC2 Accept IPv6=::C0A8:6464 Port=8543 SID=1

Finalizing a file transfer session negotiation, with either IPv4 or IPv6 and two encryption schemes available receiving client would like to resume using IPV4 and SSL3: DCC2 Accept IPv4 SSL3 Filename="some file.txt" Size=3423 Offset=1003 SID=2 offering client sends: DCC2 Accept IPv4=192.168.34.231 Port=9341 SSL3 Filename="some file.txt" Size=3423 SID=2

Finalizing a file transfer session negotiation with IPv6 receiving client will accept the transfer: DCC2 Accept IPv6 Filename=somefile.txt Size=3423 SID=1 offering client will send: DCC2 Accept IPv6=::C0A8:6464 Filename=somefile.txt Size=3423 SID=1

Finalizing a file transfer session negotiation with IPv4 available and using the DCC2 out of band file descriptions receiving client will accept the file transfer: DCC2 Accept IPv4 Multi=983 SID=1 offering client will send: DCC2 Accept IPv4=192.168.34.231 Port=9251 Multi=983 SID=1

Proposing a chat session negotiation, with either IPv4 or IPv6 and manditory encryption with two schemes available. ; Offering client sends initial publication with manditory Transport Security DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=10a ; Receiving client accepts using an ipv6 interface and tls1 DCC2 Accept IPv6 TLS1 SID=10a ; Offering client creates a listening port and sends connection information DCC2 Accept IPv6=::C0A8:6464 Port=4521 TLS1 SID=10a

Proposing a file transfer with IPv6 and one optional encryption schemes available ; Offering client sends initial publication with optional Transport Security DCC2 Application=IRCFile Network=IPv6 TransportSecurity+=TLS1 SID=abde3 Filename="todo.txt" Size=98342 ; Receiving client accepts using an ipv6 interface and no encryption DCC2 Accept IPv6 SID=abde3 Filename="todo.txt" Size=98342 ; Offering client creates a listening port and sends connection information DCC2 Accept IPv6=::C0A8:6464 Port=3412 TLS1 SID=10a Filename="todo.txt" Size=98342

Proposing a chat session negotiation, with either IPv4 or IPv6 and manditory encryption with two schemes available. ; Offering client sends initial publication with manditory Transport Security DCC2 Application=IRCChat Network=IPv4,IPv6 TransportSecurity=SSL3,TLS1 SID=405 ; Receiving client creates a listening port and sends connection information DCC2 Accept IPv6=::C0A8:6464 Port=7322 TLS1 SID=405

Historic DCC connections use a set of positional parameters to relate port and address information. Most clients ignore extra positional parameters in historic DCC, allowing DCC2 to be used in a backward compatible manner. If a client wishes to create a connection that could be possible under historic dcc, such as an ipv4 connection with no encryption or firewall traversal, the sending client can create a listening socket and send a historic dcc request. The client should append a DCC2 publication request to the end of the historic dcc request. If the receiving client supports dcc2, and would like to use additional features such as encrypting for this connection, it can send a DCC2 accept message to the sending client instead of accepting the transfer. The sending client should then close the connection created for the historic dcc request, and create the proper DCC2 connection. If the receiving client does not support DCC2, it will connect using the historic dcc procedure.

Ports under 1024 are privileged on unix systems, and should not be used for direct client connections. IRC client writers should be careful with directory structures when dealing with file sharing operations. Relative paths using ../ can lead to security risks IRC clients should look carefully at the speed of sending DCC2 REFUSED and DCC2 CANNOTACCEPT due to the potential for flooding attacks. When possible the messages should be sent to give the user context as to why the transfer failed

This draft is also present on the DCC2 site at the address http://www.dcc2.org/specifications/draft-smith-irc-dcc2-negotiation-00.txt. Enriched HTML and XML versions can be found at the addresses http://www.dcc2.org/specifications/draft-smith-irc-dcc2-negotiation-00.htm and http://www.dcc2.org/specifications/draft-smith-irc-dcc2-negotiation-00.xml respectively. The XML version is compliant to RFC-2629.

This draft was produced by the DCC2 community; please see authors and contributors. Thanks to Marshall Rose for his conversion tools from the RFC-2629 XML format to HTML and RFC.