MPLS Segment Routing over IP
Extracted elements (25)
MPLS-over-UDP (RFC 7510) is preferred over MPLS-over-IP (RFC 4023) because its UDP source port field can encode entropy for ECMP and LAG load balancing, whereas MPLS-over-IP provides no entropy mechanism.
SR-MPLS-over-IP allows incremental deployment by tunneling SR-MPLS packets across portions of a network that are not SR-MPLS capable, connecting islands of SR-MPLS over a legacy IP network without requiring upgrades to intermediate routers.
The explicit NULL label is inserted at the penultimate SR-MPLS node because if the final label were popped and the payload encapsulated directly in MPLS-over-UDP, it would appear as an MPLS packet carrying a non-MPLS payload, confusing the egress node.
The source-routing instructions are uniformly encoded as an MPLS label stack regardless of whether the underlay is IPv4, IPv6 (including SRv6), or MPLS, making no changes to SR-MPLS specifications and enabling interworking with existing SR-MPLS implementations.
MPLS-over-IP (RFC 4023) does not provide an entropy mechanism for ECMP/LAG load balancing, in contrast to MPLS-over-UDP (RFC 7510) where the UDP source port serves as an entropy field.
SR-MPLS-over-IP operates across MPLS, IPv4, and IPv6 data planes including SRv6 (RFC 8354) networks, enabling SR in networks where routers do not support SRv6 and where native MPLS forwarding is not available.
When IGP dynamic port negotiation (via ISIS-ENCAP or OSPF-ENCAP extensions) is not used, the port numbers specified in RFC 7510 (6635 for MPLS, 6636 for MPLS with DTLS) MUST be used for SR-MPLS-over-UDP tunnels.
DTLS (RFC 6347) SHOULD be used where security is needed on an SR-MPLS-over-UDP segment, including when the IP segment crosses the public Internet or an untrusted environment.
If SR-MPLS-capable routers A and E are in different routing domains, the Prefix-SID advertisement and tunnel encapsulation information MUST be flooded into both domains so that router A knows the characteristics of router E.
IP header fields (ECN, DSCP, IPv6 Flow Label) on each UDP-encapsulated SR-MPLS segment SHOULD be configurable according to operator policy; they may be copied from the incoming header, promoted from the payload, or set per SID instructions.
Network ingress nodes can easily detect attempts to smuggle IP packets via UDP packets with the MPLS destination port set, and such filtering SHOULD be applied.
The IP tunnel selected to carry SR-MPLS MUST have its remote endpoint (destination) address equal to the address of the next node capable of SR-MPLS identified as being on the SR path (i.e., the egress of the active segment).
To avoid recalculating entropy, the entropy value from the incoming packet's UDP source port MAY be retained when stripping the UDP header and reused as the entropy value of the outgoing encapsulated packet.
When encapsulating an SR-MPLS packet in an IP tunnel capable of encoding entropy (such as MPLS-over-UDP), the entropy field (UDP source port) MAY be filled with a value generated by the encapsulator to uniquely identify a flow.
When Router E advertises the Prefix-SID SID(E) of prefix P(E), it MUST also advertise the egress endpoint address and the encapsulation type of any tunnel used to reach E, and this information is flooded domain wide.
An SR-MPLS-capable router constructs a FIB entry for a Prefix-SID by either popping the top label (PHP case, when NP-Flag in OSPF or P-Flag in IS-IS is clear) or swapping the top label to SID(E) plus the lower bound of E's SRGB (no-PHP case, when the flag is set).
In the no-PHP case (NP-Flag/P-Flag set), the SR-MPLS label for each segment is left in place until the end of that segment, where it is popped and the next instruction is processed, rather than being pre-popped by the penultimate node.
Local policy MAY dictate use of MPLS-over-UDP even when the next hop toward the next segment is MPLS-capable; in that case the router replaces the top label with an MPLS-over-UDP tunnel rather than forwarding as native SR-MPLS.
MPLS-over-UDP uses destination port 6635 for plain MPLS payloads and port 6636 for MPLS-over-UDP utilizing DTLS, per RFC 7510; IGP dynamic port negotiation mechanisms (ISIS-ENCAP, OSPF-ENCAP) may override these to a Dynamic Port.
Six types of nodes are defined in an SR-MPLS domain: (1) domain ingress nodes, (2) legacy IP-only transit nodes, (3) SR-MPLS-capable transit nodes not identified by a SID in the stack, (4) SR-MPLS-capable transit nodes identified by a SID, (5) the penultimate SR-MPLS-capable node, and (6) the domain egress node.
When a received SR-MPLS packet has a top label indicating an Adjacency SID and the adjacent node cannot perform MPLS forwarding, the top label is replaced by an IP tunnel toward that adjacent node and forwarded over the link indicated by the Adjacency SID.
When an SR-MPLS-capable router (the penultimate node) pops the final SR-MPLS label and the next hop is IP-only, it MUST insert an explicit NULL label (RFC 3032) before encapsulating the payload in an MPLS-over-UDP tunnel toward the egress node to avoid delivering a raw non-MPLS payload inside an MPLS-over-UDP tunnel.
If dynamic UDP port negotiation mechanisms (RFC 8665 or RFC 8667) are applied, a wider variety of UDP port numbers may be in use, making port-based filtering harder and potentially weakening ingress filtering defenses.
MPLS packet injection attacks are difficult because operators have experience excluding MPLS-carrying IP tunnel payloads at network boundaries; ingress filtering of UDP packets with the MPLS destination port SHOULD be applied and is straightforward to detect.
Where control-plane techniques (IGP, BGP, or management protocols) are used to advertise SR capabilities and tunnel information, those protocols MUST be adequately secured for the environment as discussed in RFC 6862 and RFC 5920.