Port 363 is officially assigned to RSVP Tunnel (rsvp-tunnel), a protocol that carries Resource Reservation Protocol signaling through IP tunnels. When you need guaranteed bandwidth or latency across a network path that includes tunneled segments, port 363 carries the reservation that makes those guarantees stick.1
What RSVP Tunnel Does
RSVP (Resource Reservation Protocol) allows applications to reserve network resources—bandwidth, latency guarantees, packet priority—along the path between sender and receiver. It's the mechanism behind Quality of Service (QoS) on IP networks.2
The problem: IP tunnels break RSVP signaling. When RSVP packets get encapsulated inside a tunnel (IP-in-IP, GRE, MPLS), routers along the tunnel path can't see the original RSVP messages. The reservation dies in the darkness.
RFC 2746 solved this in January 2000 by defining RSVP operation over IP tunnels.3 The protocol uses UDP encapsulation on port 363 to carry RSVP signaling through tunnels, allowing intermediate routers to distinguish packets from different RSVP sessions even when the original IP headers are hidden.
The Problem It Solves
Imagine you're running a voice call across a corporate network. Your phone reserves bandwidth using RSVP to ensure clear audio. But part of the network path uses a VPN tunnel. Without RSVP Tunnel, the reservation stops at the tunnel entrance—the voice packets enter the tunnel with no QoS protection and arrive choppy on the other side.
RSVP Tunnel on port 363 carries the reservation through the tunnel. The promise survives the journey.
Who Created It
The protocol was developed at UCLA by Andreas Terzis, John Krawczyk (ArrowPoint Communications), John Wroclawski (MIT LCS), and Lixia Zhang (UCLA). Terzis, the lead author, was working on RSVP tunneling support at UCLA's Boelter Hall in the late 1990s.3
The team presented their work at IETF meetings, developed the first prototype implementation, and published RFC 2746 in January 2000. Port 363 was registered with IANA by Andreas Terzis as the official transport for this protocol.1
How It Works
RSVP Tunnel operates on both TCP and UDP port 363. The protocol encapsulates RSVP messages inside UDP packets, allowing them to traverse tunnels while remaining visible to intermediate routers that need to process them.
The key insight: use UDP port 363 as a signal. Routers see the port number and know "this is RSVP signaling that needs special handling," even when the original IP headers are buried inside tunnel encapsulation.
Where It's Used
MPLS Networks: RSVP-TE (Traffic Engineering) extensions use RSVP to establish Label Switched Paths with guaranteed resources.4 These paths often traverse tunnel segments where port 363 maintains the signaling.
Enterprise VPNs: Corporate networks using IPsec or GRE tunnels with QoS requirements rely on RSVP Tunnel to maintain service guarantees across encrypted segments.
Service Provider Networks: Telecommunications networks offering QoS-guaranteed services use RSVP Tunnel to maintain reservations across complex topologies involving multiple tunnel types.
Security Considerations
RSVP Tunnel traffic on port 363 should be restricted to trusted network infrastructure. The protocol allows reservation of network resources, making it a potential vector for denial-of-service attacks if exposed to untrusted sources.
Some security databases have flagged port 363 as historically exploited by malware—this doesn't mean the port itself is malicious, but rather that attackers have occasionally used it for covert communications. Monitor traffic on this port and ensure it originates from legitimate RSVP infrastructure.5
Firewall rules should permit port 363 only between routers and network devices that participate in RSVP signaling. End-user hosts typically don't need access.
Related Ports
- Port 1698: RSVP-ENCAP-1, another RSVP encapsulation variant
- Port 1699: RSVP-ENCAP-2, additional RSVP encapsulation support
- Port 3455: RSVP Port, standard RSVP protocol without tunnel encapsulation
Checking Port 363
To see if RSVP Tunnel is listening on port 363:
Linux/macOS:
Windows:
On most networks, you'll only see traffic on port 363 if you're running MPLS, VPN infrastructure with QoS, or service provider equipment that implements RSVP tunneling.
The Honest Truth
RSVP Tunnel is specialized infrastructure. Most networks don't use it. QoS on the modern Internet is more often handled by traffic shaping, priority queuing, and DiffServ markings rather than explicit RSVP reservations.
But in environments where QoS guarantees are contractual—telecommunications carriers, enterprise real-time communications, industrial control networks—RSVP Tunnel on port 363 is the mechanism that ensures a reservation made at point A arrives intact at point B, even when the path between them passes through tunnels that would otherwise break the promise.
The Internet is not one smooth fabric. It's a patchwork of networks, each with different capabilities. Port 363 exists because sometimes a QoS promise needs to cross a boundary that doesn't speak the same language. This port is the translator that keeps the guarantee alive.
Was this page helpful?