DCC — Direct Client-to-Client — is one of those IRC features that was brilliant in 1990 and increasingly frustrating ever since. The concept is simple: instead of routing data through the IRC server, two clients establish a direct TCP connection between them. The IRC server is used only to negotiate the connection; the actual data transfer happens peer-to-peer.
In the era of public IP addresses and no firewalls, this was elegant. In the era of NAT, firewalls, and CGNAT? It's a constant source of "why isn't this working" messages in help channels.
What Is DCC?
DCC is a protocol extension for IRC that enables direct connections between two clients. It's not part of the core IRC protocol (RFC 1459/2812) — it's implemented through CTCP messages, which are themselves a convention built on top of PRIVMSG.
The main DCC types:
- DCC SEND: File transfer from one client to another
- DCC CHAT: Private text conversation over a direct connection (faster and more private than PRIVMSG through the server)
- DCC RESUME: Resume an interrupted DCC SEND transfer
- DCC ACCEPT: Acknowledgment of a resume request
How DCC Works
The DCC negotiation happens via CTCP messages through the IRC server:
1. Alice wants to send a file to Bob.
2. Alice's client opens a TCP listening socket on a local port.
3. Alice's client sends a CTCP message to Bob through the IRC server:
PRIVMSG Bob :\x01DCC SEND filename ip port filesize\x01
4. Bob's client receives the CTCP message.
5. Bob accepts the transfer (manually or automatically).
6. Bob's client connects directly to Alice's IP:port.
7. Alice sends the file data over this direct connection.
8. The IRC server is no longer involved.The IP address in the DCC request is encoded as a 32-bit unsigned integer (for IPv4), not as a dotted-quad string. So 192.168.1.100 becomes 3232235876. This encoding is a historical artifact that causes confusion and parsing bugs to this day.
# IP to integer conversion:
192.168.1.100 → (192 × 16777216) + (168 × 65536) + (1 × 256) + 100 = 3232235876
# The DCC SEND message looks like:
\x01DCC SEND myfile.zip 3232235876 4567 1048576\x01
# (filename, IP as integer, port, filesize in bytes)DCC SEND: File Transfers
DCC SEND was the primary file transfer mechanism on IRC for over a decade. The protocol is simple: the sender opens a socket, the receiver connects, and the file data streams over the connection. No HTTP, no FTP, no intermediary — just raw TCP.
The original DCC SEND protocol had no flow control — the sender blasted data as fast as the connection allowed, and the receiver had to keep up. Later implementations added acknowledgment packets (the receiver sends back a 4-byte count of bytes received periodically), which provided basic flow control and transfer progress tracking.
Transfer speeds were limited only by the network path between the two clients. In the days when the IRC server itself was often the bottleneck, DCC was significantly faster than any server-mediated approach. On a modern network, the difference is negligible, but the principle of eliminating the middleman is sound.
DCC CHAT: Private Conversations
DCC CHAT establishes a direct text connection between two clients. Messages sent over DCC CHAT do not pass through the IRC server at all — they go directly between the two participants.
The advantages over regular PRIVMSG:
- Privacy: The IRC server (and its operators) cannot see DCC CHAT messages. With PRIVMSG, the server operator can read everything.
- Speed: No server relay means lower latency.
- Resilience: If the IRC server goes down during a conversation, the DCC CHAT session continues — it's independent of the server connection.
DCC CHAT was heavily used by Eggdrop bots. The bot's "party line" — a private chat space for authorized bot users — was implemented over DCC CHAT. Bot operators could configure, manage, and communicate through the party line without any of that traffic touching the IRC server.
DCC RESUME: Picking Up Where You Left Off
When a DCC SEND transfer is interrupted (network hiccup, client crash, netsplit), DCC RESUME allows you to continue from where it stopped instead of starting over. The protocol:
1. Bob already has partial_file.zip (first 500,000 bytes of 1,000,000)
2. Alice offers the file again: DCC SEND partial_file.zip ...
3. Bob's client responds: DCC RESUME partial_file.zip port 500000
4. Alice's client responds: DCC ACCEPT partial_file.zip port 500000
5. Transfer resumes from byte 500,000This was genuinely useful when transferring a 700MB file over a 56k modem connection that dropped every few hours. You could chip away at a download over several days, resuming each time the connection died. On modern broadband, it's less critical but still a nice feature.
The NAT Problem
DCC was designed in a world where every computer had a public IP address. The sender opens a listening socket and tells the receiver to connect to their public IP. Simple.
Then NAT happened. Most computers are now behind a router that performs Network Address Translation. The computer's local IP (192.168.x.x or 10.x.x.x) is not reachable from the internet. The DCC request contains the local IP, which the receiver can't connect to. The transfer fails.
Workarounds exist but are all imperfect:
- Port forwarding: Configure your router to forward a range of ports to your computer. Set your IRC client to use those ports for DCC. Works but requires router access and configuration.
- UPnP/NAT-PMP: Some clients can automatically configure port forwarding if your router supports UPnP. Works sometimes, security implications are significant.
- DCC reverse (passive DCC): An extension where the receiver opens the listening socket instead of the sender. This helps when only one side is behind NAT, but fails when both are.
- XDCC/IRC server relay: Some servers can relay DCC connections, acting as a middleman. This defeats the purpose of "direct" but at least works.
In 2026, with widespread CGNAT (carrier-grade NAT, where even your router doesn't have a public IP), DCC is increasingly non-functional without explicit port forwarding. This is the main reason DCC has become a legacy feature rather than a daily-use tool.
Security Considerations
DCC has several security concerns that are worth understanding:
IP address exposure: DCC requests contain the sender's IP address. On networks where your hostname is cloaked, sending a DCC request reveals your real IP. Some clients have options to use a specific IP or to block DCC entirely for this reason.
Arbitrary port connections: Accepting a DCC connection means your client initiates a TCP connection to an IP and port specified by a stranger. In theory, this could be used to scan ports, bounce attacks, or exploit vulnerable services. Most modern clients mitigate this by restricting DCC accept to manual confirmation.
File content: There's no content validation on DCC file transfers. Malware can be sent just as easily as legitimate files. The same caution that applies to email attachments applies to DCC — don't open files from untrusted sources.
No encryption: Standard DCC connections are unencrypted. The data travels in plaintext between the two clients. Some clients support TLS-wrapped DCC (SDCC), but support is not universal.
Modern Alternatives
For file transfer, DCC has been largely superseded by:
- Paste services: For text and code snippets, paste.debian.net, bpa.st, or self-hosted alternatives like PrivateBin
- File hosting: For larger files, services like Firefox Send (while it lasted), Transfer.sh, or self-hosted solutions
- HTTP uploads: Some IRC bouncers and servers support HTTP-based file uploads that generate URLs, neatly bypassing DCC's NAT issues
For private chat, TLS-encrypted PRIVMSG with OTR or OMEMO provides better security than DCC CHAT, without the NAT complications.
DCC remains interesting as a piece of protocol history — a clever solution to a real problem that was eventually undermined by fundamental changes in network architecture. If you have port forwarding sorted and need to transfer a file to someone on IRC, DCC still works fine. But the days when it was the primary file transfer method are long past.
Frequently Asked Questions
Why does DCC show my real IP address?
DCC includes your IP address in the connection request so the other person's client knows where to connect. This is inherent to the protocol — without an IP address, the direct connection can't be established. If you want to keep your IP private, avoid initiating DCC connections or use a VPN.
Can DCC work through a VPN?
Yes, as long as the VPN assigns you a public IP and allows incoming connections on the ports your IRC client uses for DCC. The DCC request will contain the VPN's IP, not your real one. However, you'll need to ensure port forwarding is configured on the VPN side as well.
Why does my DCC transfer fail immediately?
The most common causes: NAT/firewall blocking the incoming connection, wrong IP address in the DCC request (local IP instead of public IP), or the receiver's client is configured to auto-reject DCC. Check your client's DCC settings, verify your public IP, and ensure the receiving port is accessible.
Is DCC used for anything in 2026?
DCC SEND is still used in some XDCC distribution channels (particularly for anime fansubbing) and between users who have properly configured port forwarding. DCC CHAT is mostly replaced by encrypted PRIVMSG. The practical usage of DCC has declined significantly due to NAT issues, but the protocol still works when both sides are properly configured.
FAQ
What is DCC on IRC?
DCC (Direct Client-to-Client) is a protocol extension that allows IRC users to establish direct connections for file transfers and private chats, bypassing the IRC server.
Is DCC safe?
DCC transfers expose your IP address to the other party. Files received via DCC should be treated with the same caution as email attachments. Use a VPN or bouncer if IP exposure is a concern.
Does DCC still work through NAT?
Many clients support DCC with passive mode (reverse DCC) to work through NAT and firewalls. The receiver initiates the connection instead of the sender, which helps when one party is behind NAT.