Summary

  • RFC 7510 places locally generated flow entropy in the outer UDP source port so ordinary IP routers can distribute MPLS traffic across ECMP paths and link-aggregation members.
  • Neither that source port nor destination port 6635 proves a session, an identity or permission. Tunnel endpoints, configuration, packet filters, checksum policy, congestion control, the MPLS label stack and optional security protection remain separate control surfaces.

A port that behaves unlike a port

A packet analyst is trained to read a UDP source port as one half of a conversation. Together with source and destination addresses, the destination port and the protocol number, it helps identify a flow. Stateful devices often expect a reply to reverse the same pair of ports. Monitoring systems may group packets under that familiar five-tuple.

Then an MPLS-in-UDP packet arrives. Its source port can remain stable across packets, and its destination is a registered service number. The header looks like a transport exchange. In RFC 7510, however, the resemblance has a strict limit: the source port “serves solely as a source of entropy.” The tunnel is unidirectional, and return traffic is not sent back to that source port.

That distinction is operationally consequential. A value can help choose a path without identifying an application. It can group packets according to a local rule without establishing a session. It can be visible to routers while saying nothing about whether the encapsulator is trusted. The field has retained its position in the header but has been assigned a narrower job.

Why MPLS borrowed UDP

The motivation begins with hardware already present in IP networks. Many routers distribute TCP and UDP microflows across Equal-Cost Multipath routes or Link Aggregation Groups by hashing the five-tuple. Directly encapsulated MPLS traffic may not expose enough variation to those devices. Several flows can then land on the same member even when other paths have spare capacity.

RFC 7510 wraps the MPLS packet in IP and UDP. The outer source and destination addresses identify the tunnel endpoints. The UDP protocol and ports give an intermediate IP router fields it already knows how to hash. The source port supplies variation, allowing different MPLS flows to spread across available paths without requiring every transit device to inspect the label stack.

The wire diagram makes the division explicit. It shows Source Port = Entropy, Dest Port = MPLS, then the UDP length and checksum. Only after those outer fields comes the MPLS label stack, followed by the message body. Three surfaces sit one behind another: an IP tunnel, a UDP distribution envelope and an MPLS forwarding context.

The arrangement is an adapter. It lets an MPLS flow use IP equipment’s existing load-sharing behavior. That practical reuse is not a claim that MPLS has become a UDP application or that the outer source port has acquired the semantics of an application endpoint.

The encapsulator defines the flow

RFC 7510 says the source port contains a 16-bit entropy value generated by the encapsulator to identify a flow. It immediately narrows that statement: what constitutes a flow is determined locally, and the algorithm used to calculate the value is outside the document’s scope.

This means two implementations can make different grouping choices while complying with the same encapsulation. One may hash inner headers. Another may use fields available at an earlier forwarding stage. The standard does not make the entropy value globally interpretable, and a collector cannot reverse the port number into an authoritative description of the underlying traffic.

If a tunnel does not need entropy, packets in one flow should use a randomly selected constant value. The reason is packet order, not identity. Changing the value could move successive packets onto different paths and produce reordering. Stability is therefore an operating property of the chosen path bucket; it is not proof of a durable conversation.

The RFC also offers a construction for environments that expect source ports in the dynamic/private range from 49152 through 65535. An encapsulator can calculate a 14-bit hash and set the upper two bits to binary 11. The resulting field carries useful variation while avoiding lower port numbers reserved for named applications and protocols.

Even then, the space is small and local. Collisions are possible. A value can be reused by another encapsulator or another locally defined flow. Reading it as a customer, tenant, application or security principal would create meaning the sender never promised and the standard never specified.

6635 identifies payload, not authority

The destination side is less variable but no more authoritative. RFC 7510 sets the UDP destination port to 6635, which IANA’s service-name and port-number registry records as mpls-udp. The allocation tells a configured decapsulator that the UDP payload is an MPLS packet.

It does not tell the endpoint who sent the packet, whether that sender is entitled to use the tunnel or whether the enclosed label stack is valid in the receiver’s forwarding context. Registration creates a common parsing rendezvous. It does not create an access-control relationship.

RFC 7510 separately requires the encapsulator to know that the endpoint can decapsulate MPLS-in-UDP. That knowledge may come from manual configuration or dynamic advertisement, but the method is outside the document. Capability and admission therefore precede the packet. Receiving a datagram on port 6635 is not itself the capability negotiation.

This separation is easy to lose in firewall rules. A rule that admits traffic merely because its destination is 6635 treats a payload label as an authorization credential. A safer policy binds the expected source and destination addresses, interface or domain, tunnel configuration and security requirements, then permits the registered port inside that relationship.

The label stack still does the forwarding work

After decapsulation, the receiver processes the payload as an MPLS label stack. RFC 3032 defines how that stack is encoded. RFC 3031, co-authored by Eric Rosen, Arun Viswanathan and Ross Callon, describes a label as a short, fixed-length, locally significant identifier used in forwarding.

“Locally significant” is another useful boundary. The top label has meaning in the forwarding context in which it was assigned. A globally registered UDP destination port does not make the enclosed labels globally meaningful. The decapsulator must enter the correct label space and apply the correct downstream- or upstream-assignment rules.

There is also more than one kind of entropy in an MPLS system. RFC 6790 defines an Entropy Label Indicator and Entropy Label inside the MPLS stack. RFC 7510 instead places entropy in the outer UDP source port so IP equipment can see it. The two mechanisms occupy different layers and may help different forwarding devices.

Neither mechanism authenticates a packet. An entropy label is not a user identity because it appears deeper in the stack, and a UDP source port is not a session because it appears in a familiar transport header. Location changes which device can use the signal; it does not turn the signal into authority.

The middlebox tells on the abstraction

RFC 7510’s unidirectional rule exposes how far this tunnel differs from an ordinary UDP exchange. MPLS-in-UDP traffic goes to the allocated destination port. It is never returned to the source port used for entropy. A stateful firewall or NAT that assumes bidirectional traffic will reverse one common port pair may therefore need a separate rule for each direction.

That is not a minor compatibility footnote. It warns operators that session-shaped telemetry can be false. A device may display a five-tuple and a stable source port, yet there may be no transport session to time out, no application bound to the source port and no reply path expressed by the same tuple.

Observability should keep the two meanings apart. The outer tuple can identify a tunnel packet and an entropy bucket. The tunnel configuration identifies the expected peer relationship. The label stack identifies the forwarding context. Higher-layer information, when visible, identifies the carried traffic. Combining those records may be useful; collapsing them into one “session” is not.

Checksums reveal the cost allocation

The UDP checksum policy shows the same layered trade-off. For IPv4, RFC 7510 recommends a zero UDP checksum for performance or implementation reasons, while noting that label corruption may matter for some VPN traffic. For IPv6, a checksum is required by default.

RFC 6935 permits a constrained IPv6 zero-checksum mode for tunnels. RFC 6936 supplies the applicability requirements: the environment must be tightly controlled, corruption characteristics understood and the residual risk consciously accepted. A middlebox that discards IPv6 UDP packets with zero checksums can black-hole the tunnel.

RFC 8085 later places source-port entropy inside broader UDP usage guidance. Its value here is not that it turns the port into a conventional endpoint. It reinforces that UDP tunnel designers must account for checksum coverage, middlebox behavior and congestion rather than borrowing only the convenient hash fields.

The checksum decision allocates risk. Removing computation may improve throughput, but somebody then owns the consequences of undetected corruption. The entropy field cannot compensate for that choice. A well-distributed damaged packet is still damaged.

A tunnel bounded by cooperation

RFC 7510 does not authorize unrestricted MPLS-in-UDP across the Internet. Its applicability statement limits the technology to one operator’s network or an adjacent set of cooperating operators where traffic is managed to avoid congestion. Packet filters should stop the traffic from escaping that domain through errors or misconfiguration.

This is a boundary of incentives as much as topology. Within a controlled domain, operators can coordinate capacity, admission, monitoring and response. Across the open Internet, a UDP tunnel without suitable congestion behavior can shift its costs onto unrelated flows and networks. A convenient encapsulation cannot manufacture the cooperation on which its safety depends.

Security has the same structure. The RFC states that MPLS-in-UDP alone cannot ensure integrity or privacy and cannot authenticate the encapsulator. It discusses IPsec and DTLS when those properties are needed. IANA port 6636 identifies the DTLS variant, but even that registered number is only part of the mechanism; keys, peers and policy still have to be established.

The complete trust boundary therefore includes the tunnel endpoint addresses, the configuration or signaling that establishes capability, the permitted operating domain, packet filters, congestion management, checksum policy, label-space context and any integrity or authentication layer. Port 6635 is legible inside that boundary. It is not a substitute for it.

Ross Callon in a shared record

The IETF Datatracker profile for Ross Callon lists eight RFCs, including the MPLS architecture in RFC 3031 and MPLS-in-UDP in RFC 7510. The record spans work on OSI address allocation, IPv6 transition, MPLS and provider VPNs. It supplies a documented line of technical authorship without assigning him sole ownership of any outcome.

RFC 7510 has five authors and is an IETF consensus document. RFC 3031 has three authors and sits inside a much larger standards history. Implementers decide which fields to hash. Operators decide where the tunnel may run. IANA maintains the port registration. The person profile should not compress those institutions and decisions into a heroic biography.

What the record does support is a useful continuity of concern. RFC 3031 described the forwarding meaning of a locally significant label. RFC 7510 later placed that label stack inside an outer header that existing IP equipment could distribute. In both cases, the mechanism works only when each field’s scope is respected.

That scope is the article’s central lesson. A source port can be entropy without becoming a session. A registered destination port can identify a payload without authorizing it. A label can select forwarding behavior without naming an owner. Technical interoperability depends on those limited meanings precisely because no field is forced to carry every kind of truth.

Evidence limits

The public sources establish RFC 7510’s format, applicability limits, checksum and security guidance, IANA’s port registrations, the MPLS label-stack standards and Ross Callon’s recorded co-authorship. They do not establish current deployment volume, vendor-specific behavior, a measured incident caused by entropy collision or any current institutional authority held by Callon.

The claim that operators should not treat UDP entropy as identity is an editorial inference from the standard’s explicit field semantics and security limits. It is not a report of a named breach. Likewise, the article does not claim that outer source-port entropy and in-stack MPLS entropy labels are interchangeable, or that either is always preferable.

Sources