>>>transfer, I think the port to which the person must connect is
>>>specified in the dcc offer, so I don't think nat can guess it in any
>>>easy way :-(
>> 
>> the request itself travels over the irc connection between the irc
>> client and the irc server.  so the endpoint of the server connection
>> is "well known" (like ftp's command connection is well known), but not
>> as well known as you might like it to be.  irc servers commonly run on
>> ports 6665-6669, but there's absolutely nothing stopping anyone from
>> running one on a completely different port.  the messages sent to the
>
>Yes, I know that, and I'd add that thoose ports are the ones used by ircnet irc
>servers, other irc network servers use others (common ones are 5555
>[0-9]0[0-9]0)...

...which basically means it's all over the place.  and can't,
therefore, be "proxied" for you.  the reason that you can accept a dcc
offering is that your client connects out to the "foreign" client.
but you probably knew that.  :)

>> server from your client are:
>> 
>>   NOTICE otherguy :DCC Send filename.txt (192.168.14.127)
>>   PRIVMSG otherguy :^ADCC SEND filename.txt 3232239231 1054 477^A
>> 
>> where the "privmsg" command is the important one.  that's the one that
>> tells the remote client (the other guy) where to connect back to by
>> specifying your address as a single, unsigned integer, then the port,
>> and then some other number.  needless to say, dcc isn't covered in the
>> irc rfc.  :)
>
>I noticed that, this is beacause I didn't have any specific information ;-)

dcc is basically a hack that was invented inside the defined irc
protocol.  since it uses "notice" and "privmsg" in their proscribed
forms and only requires the end client to actually "grok" the meaning
of the commands, it doesn't really "need" to be defined anywhere.  at
least insofar as getting servers to properly implement the dcc
protocol.  there isn't one that low down.  it just works.

>>>> on the port level, so I'm pretty much just guessing. I *think* not having
>>>> a nailed-down port will be an issue, though.)
>>>
>>>The problem is that dcc doesn't have any nailed down ports...
>> 
>> well...no, it doesn't.  and less so that ftp.  :)
>
>well, not exactly, ftp has a well known port for the control connection, even
>if the data connection is negotiated for evety transfer...And anyway ftp has
>passive mode, about which I don't know anything, but it works throught
>firewalls...;-)

ftp has a well known for the command connection and the data
connection.  it just so happens that the latter is almost irrelevent
to proxying.

ftp's passive mode is best described in contrast to "normal" mode.  in
normal mode, your client sends a "port a,b,c,d,e,f" (where a,b,c,d,e,f
are octets) command (which gets proxied), the server responds "200
port command ok", and then your client attempts to "retr" something
from the server.  in the trivial case.  the ftp server then connects
from its port 20 back to the port named in your client's port command
and transfers the data.

passive mode differs from this in that your client says "pasv" instead
of "port" and the server's response is "200 a,b,c,d,e,f" (where
a,b,c,d,e,f are again octets) and your client then connects to that
port before attempting to "retr" something.  this is how you can ftp
through the simpler firewall (or specifically packet filtering router)
configurations, because the tcp connection will be initiated from
inside the firewall.  the syn packet is allowed out, but usually not
in.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."