[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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 <http://www.dcc2.org/>.

   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 <http://
   www.dcc2.org/>.

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.  !#$%&#38;'()+,-.=@[]^_{}~
   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 <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.html>
   and <http://www.dcc2.org/specifications/
   draft-smith-irc-dcc2-negotiation-00.xml> 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 <http://www.dcc2.org/>; please see
   <http://www.dcc2.org/members/>.

   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]


Html markup produced by rfcmarkup 1.125, available from https://tools.ietf.org/tools/rfcmarkup/