Network Working Group D. Smith, Ed.
Internet-Draft Algenta
Expires: October 22, 2004 April 23, 2004
Internet Relay Chat (IRC) Client to Client Protocol (DCC2) Connection
Negotiation
draft-smith-irc-dcc2-negotiation-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 22, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Direct Client Connection v2 (DCC2) connection negotiation
specification describes how to establish connections between
individual IRC clients. This draft describes a direct client
connection protocol which supports the publishing of supported
protocol options and connection negotiation. The DCC2 protocol is
intended to be part of the IRC Client to Client Protocol (CTCP)
framework.
Smith Expires October 22, 2004 [Page 1]
Internet-Draft IRC DCC2 Negotiation April 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. DCC2 Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DCC2 Message Encapsulation . . . . . . . . . . . . . . . . . . 6
4. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 DCC2 Publication Tokens . . . . . . . . . . . . . . . . . 7
4.1.1 Network . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2 Transport . . . . . . . . . . . . . . . . . . . . . . 7
4.1.3 TransportSecurity . . . . . . . . . . . . . . . . . . 7
4.1.4 Application . . . . . . . . . . . . . . . . . . . . . 7
4.1.5 NAT . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.6 SID . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 DCC2 Connection Tokens . . . . . . . . . . . . . . . . . . 8
4.2.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.3 Port . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.4 ErrorTokens . . . . . . . . . . . . . . . . . . . . . 8
4.2.5 ErrorMessage . . . . . . . . . . . . . . . . . . . . . 8
4.3 DCC2 IRCFile Transfer Tokens . . . . . . . . . . . . . . . 9
4.3.1 File . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2 Size . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.3 Offset . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.4 Multi . . . . . . . . . . . . . . . . . . . . . . . . 9
5. DCC2 negotiation . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Publication of Connection Parameters . . . . . . . . . . . 10
5.1.1 Publication Description . . . . . . . . . . . . . . . 10
5.1.2 Publish Syntax . . . . . . . . . . . . . . . . . . . . 10
5.1.3 Publication Examples . . . . . . . . . . . . . . . . . 11
5.2 Accepting of Connection Parameters . . . . . . . . . . . . 12
5.2.1 Accepting a negotiation . . . . . . . . . . . . . . . 12
5.2.2 Accept Syntax . . . . . . . . . . . . . . . . . . . . 12
5.2.3 Accept Examples . . . . . . . . . . . . . . . . . . . 12
5.3 Connecting . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.1 Establishing the TCP connection . . . . . . . . . . . 15
5.3.2 Negotiated DCC2 message . . . . . . . . . . . . . . . 15
5.3.3 Final negotiated Examples . . . . . . . . . . . . . . 15
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1 DCC2 Chat Session . . . . . . . . . . . . . . . . . . . . 17
6.2 DCC2 File Session . . . . . . . . . . . . . . . . . . . . 17
6.3 DCC2 Nat Traversal . . . . . . . . . . . . . . . . . . . . 17
7. Backwards Compatibility with historic DCC . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
Smith Expires October 22, 2004 [Page 2]
Internet-Draft IRC DCC2 Negotiation April 2004
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22
Smith Expires October 22, 2004 [Page 3]
Internet-Draft IRC DCC2 Negotiation April 2004
1. Introduction
1.1 Background
The Direct Client Connection 2.0 (DCC2) is a specification currently
under development by the .
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 .
1.2 Motivation
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.
1.3 Conventions
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" in
this document are to be interpreted as described in RFC-2119 [1].
Smith Expires October 22, 2004 [Page 4]
Internet-Draft IRC DCC2 Negotiation April 2004
2. DCC2 Overview
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.
Smith Expires October 22, 2004 [Page 5]
Internet-Draft IRC DCC2 Negotiation April 2004
3. DCC2 Message Encapsulation
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
Smith Expires October 22, 2004 [Page 6]
Internet-Draft IRC DCC2 Negotiation April 2004
4. Tokens
4.1 DCC2 Publication Tokens
4.1.1 Network
Specifies a list of possible network layers for the connection.
Possible values include IPV4 and IPV6.
Network=IPv4,IPv6
4.1.2 Transport
Specifies a list of possible transport layers for the connection.
Possible values include TCP, SCTP and UDP
Transport=Tcp
4.1.3 TransportSecurity
Specifies a list of possible encryption layers for this connection.
Some possible values include SSL3 and TLS
TransportSecurity=SSL3,TLS
4.1.4 Application
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
4.1.5 NAT
Specify that incoming connections are not available. This token
never has a value.
4.1.6 SID
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.
Smith Expires October 22, 2004 [Page 7]
Internet-Draft IRC DCC2 Negotiation April 2004
4.2 DCC2 Connection Tokens
4.2.1 IPv4
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
4.2.2 IPv6
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
4.2.3 Port
The port to connect to on the IPV4 and IPV6 addresses offered. The
PORT token always has a value.
Port=9834
4.2.4 ErrorTokens
Specifies the specific connection tokens that caused the error.
ErrorTokens=Network,TransportSecurity
4.2.5 ErrorMessage
Specifies a user defined description of why the connection was
refused or failed.
ErrorMessage="I do not trust you."
Smith Expires October 22, 2004 [Page 8]
Internet-Draft IRC DCC2 Negotiation April 2004
4.3 DCC2 IRCFile Transfer Tokens
4.3.1 File
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"
4.3.2 Size
Specify the size of a FILE in bytes
Size=93424
4.3.3 Offset
A byte offset at which to resume the FILE.
Offset=7543
4.3.4 Multi
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
Smith Expires October 22, 2004 [Page 9]
Internet-Draft IRC DCC2 Negotiation April 2004
5. DCC2 negotiation
5.1 Publication of Connection Parameters
5.1.1 Publication Description
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.
5.1.2 Publish Syntax
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 [3]):
; 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
Smith Expires October 22, 2004 [Page 10]
Internet-Draft IRC DCC2 Negotiation April 2004
5.1.3 Publication Examples
5.1.3.1 DCC2 Chat
1.
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
2.
Proposing a chat session negotiation, with only IPv6 available
DCC2 Application=IRCChat Network=IPv6 SID=1
3.
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
5.1.3.2 DCC2 File Sharing
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
2.
Proposing a file transfer session negotiation, with only IPv6
available
DCC2 Application=IRCFile Network=IPv6 SID=1 Filename=somefile.txt Size=3423
3.
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
4.
Proposing a file transfer session negotiation, with only IPv4
available and using the DCC2 out of band file descriptions
Smith Expires October 22, 2004 [Page 11]
Internet-Draft IRC DCC2 Negotiation April 2004
DCC2 Application=IRCFile Network=IPv4 SID=1 Multi=983
5.2 Accepting of Connection Parameters
5.2.1 Accepting a negotiation
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.
5.2.2 Accept Syntax
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 [3]):
; 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 ]
5.2.3 Accept Examples
5.2.3.1 DCC2 Chat
1.
Smith Expires October 22, 2004 [Page 12]
Internet-Draft IRC DCC2 Negotiation April 2004
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
2.
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
3.
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
5.2.3.2 DCC2 File Sharing
1.
Smith Expires October 22, 2004 [Page 13]
Internet-Draft IRC DCC2 Negotiation April 2004
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
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!"
3.
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
4.
Smith Expires October 22, 2004 [Page 14]
Internet-Draft IRC DCC2 Negotiation April 2004
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
5.3 Connecting
5.3.1 Establishing the TCP connection
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.
5.3.2 Negotiated DCC2 message
The DCC2 negotiation parameters have been specified to use a common
supported protocol. The syntax specified using ABNF rules (as per
RFC2234 [3]) is documented in the previous section.
5.3.3 Final negotiated Examples
5.3.3.1 DCC2 Chat
1.
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:
Smith Expires October 22, 2004 [Page 15]
Internet-Draft IRC DCC2 Negotiation April 2004
DCC2 Accept IPv6=::C0A8:6464 Port=8543 TLS1 SID=1
2.
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
5.3.3.2 DCC2 File Sharing
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
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
3.
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
Smith Expires October 22, 2004 [Page 16]
Internet-Draft IRC DCC2 Negotiation April 2004
6. Examples
6.1 DCC2 Chat Session
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
6.2 DCC2 File Session
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
6.3 DCC2 Nat Traversal
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
Smith Expires October 22, 2004 [Page 17]
Internet-Draft IRC DCC2 Negotiation April 2004
7. Backwards Compatibility with historic DCC
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.
Smith Expires October 22, 2004 [Page 18]
Internet-Draft IRC DCC2 Negotiation April 2004
8. Security Considerations
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
Smith Expires October 22, 2004 [Page 19]
Internet-Draft IRC DCC2 Negotiation April 2004
9. Notes
This draft is also present on the DCC2 site at the address .
Enriched HTML and XML versions can be found at the addresses
and respectively. The XML
version is compliant to RFC-2629 [2].
Smith Expires October 22, 2004 [Page 20]
Internet-Draft IRC DCC2 Negotiation April 2004
10. Acknowledgments
This draft was produced by the ; please see
.
Thanks to Marshall Rose for his conversion tools from the RFC-2629
[2] XML format to HTML and RFC.
11 References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
[3] Crocker, D. and P. Overel, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Author's Address
Dan Smith (editor)
Algenta Technologies L.L.C.
1640 Sky Line Dr
Stevens Point, WI 54481
USA
Phone: 01-608-213-2867
EMail: dan @ algenta
URI: http://www.algenta.com
Smith Expires October 22, 2004 [Page 21]
Internet-Draft IRC DCC2 Negotiation April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Smith Expires October 22, 2004 [Page 22]
Internet-Draft IRC DCC2 Negotiation April 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Smith Expires October 22, 2004 [Page 23]