Port 652: DTCP — The Satellite Listener's Lifeline

Port 652 carries DTCP (Dynamic Tunnel Configuration Protocol) announcements. Every UDP packet on this port is a broadcast saying "I'm here, I'm transmitting, and if you're listening, here's how to reach me."

The Impossible Problem

Imagine you're a satellite receiver. You can hear the broadcast perfectly—crystal clear signal from space. But you can't transmit back. It's a one-way link. The satellite dishes on rooftops across the world face the same reality: they receive, but they don't send.

And yet the Internet expects bidirectional communication. TCP handshakes. Route acknowledgments. The fundamental assumption that if I can send to you, you can respond to me.

How do you route packets across a link that only works in one direction?

DTCP's Answer

DTCP creates bidirectional routing over unidirectional links by establishing tunnels. The protocol was defined in RFC 3077¹ in 2001 by the IETF's UniDirectional Link Routing working group.

Here's how it works:

1. Feeds (sources with transmission capability) broadcast announcement packets to the multicast address 224.0.0.36 on UDP port 652
2. Receivers (devices with receive-only capability) listen on port 652 for these announcements
3. When a receiver hears an announcement, it learns: "This feed exists, here's its address, here's how to tunnel back"
4. The receiver establishes a tunnel back to the feed using a different path—typically a terrestrial Internet connection
5. Now packets can flow both ways: down from satellite (unidirectional link), up through tunnel (return path)

The announcement packets have a TTL of 1—they're meant for directly connected receivers only, not to propagate across the Internet.

Why This Matters

Satellite links are fast and wide. Broadcasting to millions of receivers simultaneously is trivial. But that broadcast is one-way. Without DTCP, those receivers would be passive consumers, unable to participate in Internet routing protocols that assume bidirectional connectivity.

DTCP changed that. Satellite receivers running DTCP can:

• Participate in multicast routing (DVMRP, PIM)
• Run standard routing protocols
• Act as normal Internet nodes despite physical transmission limitations

The protocol makes asymmetric links look symmetric to the rest of the network stack.

The Protocol Details

Port: 652 (UDP)
Multicast address: 224.0.0.36 ("DTCP announcement")
IANA registration: HELLO_PORT / udlr-dtcp
Defined in: RFC 3077¹

DTCP announcements contain:

• Feed router identification
• Tunnel endpoint addresses
• Capability information
• Timing parameters for tunnel maintenance

Receivers use this information to maintain a list of operational feeds and establish tunnels dynamically as needed.

Security Considerations

DTCP announcements are unauthenticated broadcasts. A malicious actor could:

• Advertise fake feeds to redirect tunnel traffic
• Flood the multicast group with announcements
• Cause receivers to establish tunnels to attacker-controlled endpoints

RFC 3077 acknowledges these risks but provides no built-in authentication mechanism. Deployments should:

• Use IPsec or other tunnel security
• Filter announcements at network boundaries
• Validate feed addresses against known-good lists

Who Uses This

DTCP is deployed in:

• Satellite Internet services — Broadcasting content to receive-only dishes
• Digital video broadcasting — IP over satellite (DVB-S, DVB-RCS systems)
• Military communications — One-way tactical data links that need bidirectional routing
• Enterprise multicast — Content distribution over asymmetric wide-area links

It's invisible infrastructure. The satellite receiver on your roof might be listening to port 652 right now, maintaining tunnels you never knew existed.

Checking Port 652

To see if anything is listening on port 652:

Linux/macOS:

sudo lsof -i :652
sudo netstat -an | grep 652

Windows:

netstat -an | findstr :652

If you see activity on this port and don't have satellite equipment or unidirectional link infrastructure, investigate. DTCP is specialized—finding it unexpectedly might indicate:

• Network monitoring software using the port
• Satellite receiver software running in the background
• Unauthorized software (port 652 isn't commonly hijacked, but verify)

The Strangeness of One-Way Links

Port 652 exists because physics and networking protocols disagree about how communication works.

Physics says: satellite broadcasts are one-way. You can't transmit back to a satellite from a consumer dish.

Networking protocols say: everything is bidirectional. Send me a packet, I'll send you an acknowledgment.

DTCP is the bridge. It takes the physical reality of unidirectional transmission and wraps it in tunnels and announcements until the rest of the network stack sees bidirectional routing. The satellite receiver becomes a full Internet participant, even though it's physically incapable of talking back to the satellite.

Every announcement on port 652 is a receiver saying "I can't respond to you directly, but here's how to reach me anyway."

That's not a workaround. That's elegant engineering.