ietf-corpus

rfc-4182

Removing a Restriction on the use of MPLS Explicit NULL

E. Rosen
date2005-09 streamIETF areartg wgmpls statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc4182 doi10.17487/RFC4182 errataview
The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack. This document updates RFC 3032. [STANDARDS-TRACK]

updated by

updates

Extracted elements (9)

design-rationale §3

The original RFC 3032 restriction was removed because it caused problems in practice: binding Explicit NULL to a FEC was only safe when every incoming packet for that FEC contained exactly one label stack entry ('Condition L'), a condition that rarely holds and cannot generally be determined in advance.

mpls

design-rationale §3

The Pipe Model of RFC 3270 (MPLS DiffServ support) requires the LSP egress to bind Explicit NULL to the tunnel FEC so that LSP Diff-Serv information is carried in the EXP bits of the Explicit NULL entry while tunneled Diff-Serv information is carried in whatever lies below it. This naturally produces label stacks where Explicit NULL is at the top but not the only entry, making the old restriction incompatible with the Pipe Model.

mpls, diffserv, qos

design-rationale §3

Using Explicit NULL allows an LSP egress to determine immediately, without a Label Information Base (LIB) lookup, that further forwarding is governed by the label or IP header below. This forwarding-performance benefit motivates binding Explicit NULL rather than an ordinary label to a tunnel FEC.

mpls

interoperability-note §4

Implementations not conforming to this specification may not interoperate: if a router advertises a binding of Explicit NULL but its upstream LDP peer refuses to transmit packets with multiple label stack entries and Explicit NULL at the top, the Pipe Model cannot function until that peer is brought into compliance.

mpls, diffserv

interoperability-note §4

Legacy router implementations preceding this specification may discard any received packet that has multiple label stack entries with a top label value of Explicit NULL. Such routers should be configured to not advertise any bindings to Explicit NULL to avoid packet loss.

mpls

normative-requirement §2 MAY

IPv4 Explicit NULL (label value 0) and IPv6 Explicit NULL (label value 2) MAY now occur at any position in the MPLS label stack, not only at the bottom. This removes the restriction previously stated in RFC 3032.

mpls

protocol-element §2

IPv4 Explicit NULL (label value 0) at the top of the label stack signals that the stack must be popped. If other labels remain, the packet is forwarded based on the label that rises to the top; if the stack is now empty, the packet is forwarded as IPv4.

mpls, ip

protocol-element §2

IPv6 Explicit NULL (label value 2) at the top of the label stack signals that the stack must be popped. If other labels remain, the packet is forwarded based on the label that rises to the top; if the stack is now empty, the packet is forwarded as IPv6.

mpls, ip

security-consideration §5

Allowing Explicit NULL to appear at any position in the label stack does not impose any new security considerations beyond those already discussed in RFC 3032.

mpls, security