Port 1699: RSVP-ENCAPSULATION-2 — The Second Door for a Protocol That Never Took Over

Port 1699 is IANA-registered as rsvp-encap-2 on both TCP and UDP. It is the second of two ports assigned for encapsulating RSVP (Resource Reservation Protocol) messages inside UDP datagrams, used when RSVP must travel through IP tunnels that would otherwise hide it from the network.¹

Its companion is port 1698 (rsvp-encap-1). Together, they solve a specific problem: RSVP normally travels as IP protocol number 46 — its own protocol, separate from TCP and UDP. But when a tunnel wraps packets in a new IP header, intermediate routers see only the outer header. The inner RSVP traffic becomes invisible. Encapsulating RSVP inside UDP on known ports makes it visible again, allowing tunnel-aware routers to process it.²

What Is RSVP?

RSVP is a signaling protocol designed to let applications reserve bandwidth along a network path before sending data. The idea: before streaming video or placing a VoIP call, your device could ask each router along the route to hold bandwidth in reserve. Routers that supported RSVP would guarantee that the reserved traffic got through without delay or loss.³

It was a compelling vision. RFC 2205 defined it in 1997, and for a time it seemed like the Internet might gain the same quality-of-service guarantees that telephone networks had.⁴

It mostly didn't happen. RSVP works well in controlled environments — enterprise networks, MPLS cores, some telecommunications infrastructure — but scaling it to the open Internet proved impractical. Every router on the path needs to maintain per-flow state. At Internet scale, that's billions of flows. The routers couldn't keep up.

Today, RSVP survives in MPLS traffic engineering and some managed networks. Port 1699 exists for the cases where it still runs through tunnels.

Why Two Ports?

The IANA assignment of two separate encapsulation ports (1698 and 1699) allows different RSVP sessions or tunnel types to be distinguished by port number alone, simplifying handling at the tunnel endpoints. RFC 2746 describes the mechanics of RSVP over IP tunnels and the use of UDP encapsulation.²

In practice, both ports are rarely seen on general-purpose networks. If you're scanning your own system and see something on port 1699, it's almost certainly not RSVP unless you're running specialized networking equipment or a managed network that explicitly uses it.

How to Check What's Using Port 1699

# macOS / Linux — show process listening on port 1699
sudo lsof -i :1699

# Linux alternative
sudo ss -tlnp sport = :1699

# Windows
netstat -ano | findstr :1699

If something is listening and you don't recognize it, lsof (on macOS/Linux) will show you the process name and PID, which you can then look up.

Security Considerations

Port 1699 has no known active exploit history specific to the RSVP-ENCAPSULATION-2 assignment. Some older security databases flag it with a generic warning about trojans using registered ports, but no specific, named malware has been documented using this port.⁵

If port 1699 is open and active on a host that has no business running RSVP or related network infrastructure software, investigate what's using it.

Related Ports