[dcc2] few thoughts

[Dave Johnson]

Timo Sirainen writes:
> I don't really like the idea of using XML. IRC clients haven't been
> required to parse XML so far, so it seems pretty unnecessary
> complication (and possibly extra library dependency).

I'll second that.

> Maybe replace CRC32 checksums with MD5 or SHA1? Or at least support
> them.

It'd be nice if the draft allows any one (or multiples) of the 3, I
already have md5sum support in iroffer, while I'm sure other clients
have or plan to have one or more of those 3.

> NAT traversal chapter in the draft doesn't seem to have anything to do
> with NAT traversal? And how would client know if it's behind NAT to
> advertise the NAT token? Requiring user to tell that doesn't really help
> making DCC user-friendly. Checking local IP against what IRC server
> tells might work pretty well, assuming the user isn't behind a two-way
> address mapping NAT (or whatever it was really called) which wouldn't
> need the NAT-token. Did all IRC servers even tell user his address?

NAT is just one of the causes of the troubles with DCC(1).

I've seen a very wide range of DCC mangling support in NAT devices
(and workarounds) ranging from:

1) device does nothing
  - fake out IP address in CTCP/DCC messages with public IP
  - setup inbound connection forwarding on NAT device on fixed port(s)

2) device mangles DCC SEND/CHAT/ACCEPT and sets up inbound connection
   forwarding automatically
  - client doesn't need to do anything
  - resume broken as some command are mangled by the NAT device but
    not others (very annoying)

3) device mangles DCC SEND/CHAT/ACCEPT/RESUME and sets up inbound
   connection forwarding automatically
  - client doesn't need to do anything, everything works great

While NAT can usualy be detected by noticing a change in the IP the
client sees vs what the server sees, what device is doing NAT and if
it supports any type of automatic DCC2 tranlation isn't going to be
easy to detect.

Even if NAT is not involved people may need to use fixed ports to get
through a firewall or even worse proxies to use DCC.  Detecting this
isn't giong to be easy without some kind of user configuration.  As
the draft is written right now, anyone who cannot accept inbound
connections would need to set the NAT flag, however some NAT users
wont need to set it and some non-NAT users would need to set it
(the token seems poorly named).

The best way to fix this problem in my opinion is to get DCC2 mangling
support in firewall and NAT devices as only that device knows what's
allowed and what isn't, but that isn't going to happen overnight.  In
any event, DCC2 negotiation mangling by network devices should be
covered in detail in the draft.

If a user knows they cannot accept inbound connections for sure,
they can set the NAT token through a configurable.  That's fine, but
the trouble comes when they dont set the NAT token or they dont know
what to do.

For example consider this approach:

A client program assumes by default that it can accept inbound
connections (that is it doesn't set the NAT token)

If it recives a publication request, it accepts using it's local IP
address (which may be a private IP).

If the NAT or firewall device supports DCC2 mangling, it will convert
the IP/port in the message and send it on it's way.  If the device
does not, then the other user is going to get an accept message with
an IP/port that isnt going to work.

In either case the originator can attempt to connect to the IP/port
provided.  If it succeeds, great, but if not then it would be nice if
it could fall back into listening itself and informing the other side
that it couldn't connect but that it should instead try connecting in
the other direction.

If connections don't succeed in either direction then it's hopeless and
the clients should both error out to the user appropriately.

With this approach there is no requriement that the user know what's
going on, it's all automatic internal to the DCC2 protocol.  If the
user knows for sure that connections cant be made inbound, then set
the token and save the possible connectoin time penatly.


-- 
Dave