Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
updated by
- rfc-5332 — MPLS Multicast Encapsulations
Extracted elements (22)
Fragmentation is disallowed by default because reassembly at the tunnel tail (a router) is likely undesirable due to performance constraints. MTUs should be engineered large enough to avoid fragmentation in practice, as silently dropping oversized packets can cause hard-to-diagnose operational problems.
MPLS-in-IP is more efficient than MPLS-in-GRE and is generally preferred. MPLS-in-GRE is applicable when two routers are already adjacent over an existing GRE tunnel (making double-encapsulation inefficient) or when hardware implementation constraints require GRE in the fastpath.
The optional GRE key, sequence number, and checksum fields are not used by default because they are unnecessary for MPLS tunneling (MPLS labels handle demultiplexing), the GRE key is only a weak 32-bit cleartext password, and omitting them facilitates high-speed implementations and ensures interoperability.
An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide authentication and integrity; implementations MUST support ESP with null encryption. ESP with encryption MAY be supported for confidentiality. The tunnel tail MUST verify the source IP address on a given SA.
An MPLS-in-GRE decapsulator MUST be able to process packets correctly without the optional GRE checksum, key, and sequence number fields. It MAY also process packets with these optional fields.
An MPLS-in-GRE encapsulator MUST be able to generate packets without the optional GRE fields, and the default state MUST be that packets are generated without these fields. The encapsulator MUST NOT include optional fields unless it is known the decapsulator can process them.
If a control protocol is used to set up tunnels, it MUST have an authentication mechanism that MUST be used when the tunnel is set up. If BGP is used for automatic setup, BGP's MD5-based authentication is satisfactory.
If IPv4 is used and packets are not to be fragmented, the tunnel MUST set the DF (Don't Fragment) bit to prevent intermediate nodes from performing fragmentation.
If the tunnel head receives an MPLS packet whose size exceeds the Tunnel MTU, that packet MUST be discarded.
IPsec transport mode SHOULD be used for MPLS-in-IP or MPLS-in-GRE tunnels secured with IPsec, treating the tunnel head and tail as endpoints of a Security Association.
Manual keying MUST be supported for IPsec. If automatic keying is implemented, IKE in main mode with preshared keys MUST be supported.
The tunnel head SHOULD perform Path MTU Discovery (RFC 1191 for IPv4, RFC 1981 for IPv6) and MUST maintain a Tunnel MTU for each tunnel, defined as the minimum of an administratively configured value and the discovered Path MTU minus encapsulation overhead.
The tunnel tail MUST know precisely which labels it has distributed to tunnel heads of IPsec-secured tunnels. Those labels MUST NOT be distributed to any other LSP adjacencies, and MPLS packets received without IPsec encapsulation bearing such labels MUST be discarded.
Whether fragmentation of tunneled packets is allowed MUST be configurable at the tunnel head, and the default value MUST be that packets are not fragmented.
The encapsulating LSR (tunnel head) must know both the IP address of the decapsulating LSR (tunnel tail) and that the tunnel tail supports the particular encapsulation. This knowledge may be conveyed by manual configuration or a discovery/setup protocol; the means are outside the scope of this document.
The tunnel head MAY copy the TTL from the MPLS label stack into the TTL/Hop Limit field of the encapsulating IP header. The tunnel tail MAY copy the TTL/Hop Limit from the encapsulating IP header into the MPLS header, but only if this does not increase the MPLS TTL value.
When sending an MPLS packet into an MPLS-in-IP or MPLS-in-GRE tunnel, the DS field of the encapsulating IP header MAY be set based on the Behavior Aggregate of the MPLS packet, per RFC 3270. Similarly, at the tunnel tail the DS field MAY determine the Behavior Aggregate of the encapsulated MPLS packet.
IANA allocated IP Protocol Number 137 for MPLS-in-IP encapsulation. No future IANA actions are required for this document. The MPLS-in-GRE encapsulation requires no IANA action.
The core security problems for IP/GRE tunnels are: (1) a packet appearing to come from the tunnel but not placed there by the tunnel transmit endpoint (no encapsulator authentication); (2) packet alteration in transit (no integrity guarantee); (3) packet content exposure in transit (no privacy). IPsec support is defined as OPTIONAL due to varying security requirements.
Without IPsec, address filtering at administrative domain boundaries can help prevent spoofed tunnel packets. Source address filtering alone is insufficient unless the decapsulator validates the IP source address; effective protection requires destination-based or combined source+destination filtering.
MPLS-in-GRE packets consist of an IP header (IPv4 or IPv6), followed by a GRE header, followed by an MPLS label stack. The GRE protocol type field MUST be set to Ethertype 0x8847 (MPLS Unicast) or 0x8848 (MPLS Multicast).
MPLS-in-IP packets consist of an IPv4 or IPv6 header (source/destination set to encapsulating/decapsulating LSR addresses), followed by an MPLS Label Stack as defined in RFC 3032, followed by the message body. The IPv4 Protocol Number or IPv6 Next Header is set to 137.