rfc9790.original		rfc9790.txt
	MPLS Working Group K. Kompella		Internet Engineering Task Force (IETF) K. Kompella
	Internet-Draft Juniper Networks		Request for Comments: 9790 Juniper Networks
	Updates: 4928 (if approved) S. Bryant		Updates: 4928 S. Bryant
	Intended status: Standards Track University of Surrey 5GIC		Category: Standards Track University of Surrey 5GIC
	Expires: 8 June 2025 M. Bocci		ISSN: 2070-1721 M. Bocci
	Nokia		Nokia
	G. Mirsky, Ed.		G. Mirsky, Ed.
	Ericsson		Ericsson
	L. Andersson		L. Andersson
	J. Dong		J. Dong
	Huawei Technologies		Huawei Technologies
	5 December 2024		July 2025
	IANA Registry and Processing Recommendations for the First Nibble		IANA Registry and Processing Recommendations for the First Nibble
	Following a Label Stack		Following a Label Stack
	draft-ietf-mpls-1stnibble-13
	Abstract		Abstract
	This document creates a new IANA registry (called the Post-stack		This document creates a new IANA registry (called the "Post-Stack
	First Nibble registry) for the first nibble (4-bit field) immediately		First Nibble" registry) for the first nibble (4-bit field)
	following an MPLS label stack. Furthermore, this document sets out		immediately following an MPLS label stack. Furthermore, this
	some documentation requirements for registering new values, and		document presents some requirements for registering new values and
	requirements that make processing MPLS packets easier and more		making the processing of MPLS packets easier and more robust.
	robust.
	The relationship between the IANA IP Version Numbers (RFC 2780) and		The relationship between the IANA "Post-Stack First Nibble" registry
	the Post-stack First Nibble registry is described in this document.		and the "IP Version Numbers" registry (RFC 2780) is described in this
			document.
	This document updates RFC 4928 by deprecating the heuristic method		This document updates RFC 4928 by deprecating the heuristic method
	for identifying the type of packet encapsulated in MPLS.		for identifying the type of packet encapsulated in MPLS.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is a product of the Internet Engineering Task Force
	Task Force (IETF). Note that other groups may also distribute		(IETF). It represents the consensus of the IETF community. It has
	working documents as Internet-Drafts. The list of current Internet-		received public review and has been approved for publication by the
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	Internet-Drafts are draft documents valid for a maximum of six months		Information about the current status of this document, any errata,
	and may be updated, replaced, or obsoleted by other documents at any		and how to provide feedback on it may be obtained at
	time. It is inappropriate to use Internet-Drafts as reference		https://www.rfc-editor.org/info/rfc9790.
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 8 June 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4		1.1. Requirements Language
	1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Definitions
	1.3. Reference Figures . . . . . . . . . . . . . . . . . . . . 5		1.3. Abbreviations
	2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7		1.4. Reference Figures
	2.1. Why Look at the First Nibble . . . . . . . . . . . . . . 7		2. Rationale
	2.1.1. ECMP Load Balancing . . . . . . . . . . . . . . . . . 7		2.1. Why Look at the First Nibble
	2.2. Updates of RFC 4928 . . . . . . . . . . . . . . . . . . . 9		2.1.1. ECMP Load Balancing
	2.3. Why Create a Registry . . . . . . . . . . . . . . . . . . 10		2.2. Updates to RFC 4928
	2.4. IP Version Numbers versus Post-stack First Nibble		2.3. Why Create a Registry
	Values . . . . . . . . . . . . . . . . . . . . . . . . . 11		2.4. IP Version Numbers Versus Post-Stack First Nibble Values
	2.5. Next Step to More Deterministic Load-balancing in MPLS		2.5. Next Step to More Deterministic Load Balancing in MPLS
	Networks . . . . . . . . . . . . . . . . . . . . . . . . 11		Networks
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		3. IANA Considerations
	3.1. The Post-stack First Nibble Registry . . . . . . . . . . 12		4. Security Considerations
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. References
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Normative References
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.2. Informative References
	6.1. Normative References . . . . . . . . . . . . . . . . . . 13		Acknowledgements
	6.2. Informative References . . . . . . . . . . . . . . . . . 15		Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	An MPLS packet consists of a label stack, an optional "post-stack		An MPLS packet consists of a label stack, an optional Post-Stack
	header" (PSH) and an optional embedded packet (in that order).		Header (PSH), and an optional embedded packet (in that order).
	Examples of PSH include existing artifacts such as Control Words		Examples of PSHs include existing headers such as control words
	[RFC4385], BIER (Bit-Indexed Explicit Replication) headers [RFC8296]		[RFC4385], BIER (Bit Index Explicit Replication) headers [RFC8296]
	and the like, as well as new types of PSH being discussed by the MPLS		and the like, as well as new types of PSH being discussed by the MPLS
	Working Group. However, in the data plane, there are very few clues		Working Group. However, in the data plane, there are very few clues
	regarding the PSH, and no clue as to the type of embedded packet;		regarding the PSH and no clue as to the type of embedded packet; this
	this information is communicated via other means, such as the routing		information is communicated via other means, such as the routing
	protocols that signal the labels in the stack. Nonetheless, in order		protocols that signal the labels in the stack. Nonetheless, in order
	to better handle an MPLS packet in the data plane, it is common		to better handle an MPLS packet in the data plane, it is common
	practice for network equipment to "guess" the type of embedded		practice for network equipment to "guess" the type of embedded
	packet. Such equipment may also need to process the PSH. Both of		packet. Such equipment may also need to process the PSH. Both of
	these require parsing the data after the label stack. To do this,		these require parsing the data after the label stack. To do this,
	the "first nibble" (the top four bits of the first octet following		the "first nibble" (the top four bits of the first octet following
	the label stack) is often used. Although some existing network		the label stack) is often used. Although some existing network
	devices may use such a method, it needs to be stressed that the		devices may use such a method, it needs to be stressed that the
	correct interpretation of the Post-stack First Nibble (PFN) in a PSH		correct interpretation of the Post-stack First Nibble (PFN) in a PSH
	can be made only in the context associated using the control or		can be made only in the context established through the control or
	management plane with the Label Stack Element (LSE) or group of LSEs		management plane with the Label Stack Entry (LSE) or group of LSEs in
	in the preceding label stack that characterize the type of the PSH,		the preceding label stack that characterizes the type of the PSH.
	and that any attempt to rely on the value in any other context is		Any attempt to rely on the value in any other context is unreliable.
	unreliable. Because the PFN value should not be used to deduce the		Because the PFN value should not be used to deduce the type of PSH by
	type of PSH by itself, and the space of PFN values is limited, the		itself and the space of PFN values is limited, the reuse of PFN
	re-use of PFN values, where that is possible, is encouraged.		values is encouraged when possible.
	The semantics and usage of the first nibble are not well documented,		The semantics and usage of the first nibble are not well documented,
	nor are the assignments of values. This document serves four		nor are the assignments of values. This document serves four
	purposes:		purposes:
	* To document the values already in use.		* To document the values already in use.
	* To provide a mechanism to document future assignments through the		* To provide a mechanism to document future assignments through the
	creation of a new IANA "Post-stack First Nibble registry", and		creation of a new IANA "Post-Stack First Nibble" registry and
	document the relationship between it and the IANA IP Version		describe the relationship between it and the IANA "IP Version
	Numbers [RFC2780].		Numbers" registry [RFC2780].
	* Provide a method for tracking usage by requiring more detailed		* Provide a method for tracking usage by requiring more detailed
	documentation.		documentation.
	* To stress the importance that any MPLS packet not carrying plain		* To stress that any MPLS packet not carrying plain IPv4 or IPv6
	IPv4 or IPv6 packets contains a PSH, including any new version of		packets contains a PSH. This also applies to packets of any new
	IP (Section 2.4).		version of IP (see Section 2.4).
	Based on the analysis of load-balancing techniques in Section 2.1.1,		Section 2.1.1 of this document includes an analysis of load-balancing
	this document, in Section 2.1.1.1, introduces a requirement that		techniques; based on this, Section 2.1.1.1 introduces a requirement
	deprecates the use of the heuristic and recommends using a dedicated		that deprecates the use of the heuristic method for identifying the
	label value for load balancing. The intent of both is for legacy		type of packet encapsulated in MPLS and recommends using a dedicated
	routers to continue operating as they have, with no new problems		label value for load balancing. The intent is for legacy routers to
	introduced as a result of this document. However, new		continue operating as they have, with no new problems introduced as a
	implementations that follow this document enable a more robust		result of this document. However, new implementations that follow
	network operation.		this document enable more robust network operation.
	Furthermore, this document updates [RFC4928] by deprecating the		Furthermore, this document updates [RFC4928] by deprecating the
	heuristic method for identifying the type of packet encapsulated in		heuristic method for identifying the type of packet encapsulated in
	MPLS. This document clearly states that the type of encapsulated		MPLS. This document clearly states that the type of encapsulated
	packet cannot be determined based on the PFN alone.		packet cannot be determined based on the PFN alone.
	1.1. Conventions and Definitions		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	MPLS packet: one whose Layer 2 header declares the type to be MPLS.		1.2. Definitions
	For example, for Ethernet the Ethertype is 0x8847 or 0x8848, and
	for PPP the Protocol field is 0x0281 or 0x0283.
	Label Stack: (of an MPLS packet) all labels (four-octet fields)		Deprecation: Regardless of how the deprecation is understood in
	after the Layer 2 header, up to and including the label with the		other IETF documents, the interpretation in this document is that
	Bottom of Stack bit set ([RFC3032]).		if a practice has been deprecated, that practice should not be
			included in new implementations or deployed in new deployments.
	Post-stack First Nibble (PFN): the most significant four bits of the		Embedded Packet: A packet that follows immediately after the MPLS
	first octet following the label stack.		label stack and an optional PSH. The embedded packet could be an
			IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN
			Service (VPLS) [RFC4761] [RFC4762] or EVPN [RFC7432]), or some
			other type of Layer 2 frame [RFC4446].
	MPLS Payload: all data after the label stack, including the PFN, an		Label Stack: A label stack is represented as a consecutive sequence
	optional post-stack header, and the embedded packet.		of "label stack entries" (four-octet fields) after the Layer 2
			header but before any network layer header. The last label stack
			entry of a label stack has its Bottom of Stack bit set.
	Post-stack Header (PSH): optional field of interest to the egress		MPLS Packet: A packet whose Layer 2 header declares the type to be
	Label Switching Router (LSR) (and possibly to transit LSRs).		MPLS. For example, the Ethertype is 0x8847 or 0x8848 for
	Examples include a control word [RFC4385], [RFC8964] or an		Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.
	associated channel [RFC4385], [RFC5586], [RFC9546]. The PSH MUST
	indicate its length, so that a parser knows where the embedded
	packet starts.
	Embedded Packet: an embedded packet follows immediately after the		MPLS Payload: All data after the label stack and any optional PSHs.
	MPLS Label Stack and an optional PSH. That could be an IPv4 or		It is possible that more than one type of PSH may be present in a
	IPv6 packet, an Ethernet packet (for VPLS ([RFC4761], [RFC4762])		packet, and some PSH specifications might allow multiple PSHs of
	or EVPN [RFC7432]), or some other type of Layer 2 frame [RFC4446].		the same type. The presence rules for multiple PSHs are a matter
			for the documents that define those PSHs, e.g., [MNA-PS-HDR].
	Deprecation: regardless of how the deprecation is understood in		Post-stack First Nibble (PFN): The most significant four bits of the
	other IETF documents, the interpretation in this document is that		first octet following the label stack.
	if a practice has been deprecated, that practice should not be
	included in new implementations or deployed in new deployments.
	1.2. Abbreviations		Post-Stack Header (PSH): A field containing information that may be
			of interest to the egress Label Switching Router (LSR) or transit
			LSRs. Examples include a control word [RFC4385] [RFC8964] or an
			associated channel header [RFC4385] [RFC5586] [RFC9546].
	LSR: Label Switching Router		1.3. Abbreviations
	LSE: Label Stack Element
	PSH: Post-Stack Header		BIER: Bit Index Explicit Replication
	PFN: Post-stack First Nibble		FAT: Flow-Aware Transport
	FAT: Flow-Aware Transport		LSE: Label Stack Entry
	SPL: Special Purpose Label		LSR: Label Switching Router
	PW: Pseudowire		MNA: MPLS Network Action
	MNA: MPLS Network Action		PFN: Post-stack First Nibble
	BIER: Bit-Indexed Explicit Replication		PSH: Post-Stack Header
	1.3. Reference Figures		PW: Pseudowire
			SPL: Special-Purpose Label
			1.4. Reference Figures
	Figure 1 echoes the format of MPLS packets as defined in [RFC3032]		Figure 1 echoes the format of MPLS packets as defined in [RFC3032]
	where TC indicates the Traffic Class field [RFC5462] that replaced		where TC indicates the Traffic Class field [RFC5462] that replaced
	the EXP (Experimental Use) field, S is the Bottom-of-Stack flag, and		the EXP (Experimental Use) field, S is the Bottom of Stack flag, and
	TTL is the Time to Live field.		TTL is the Time to Live field.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	X | Layer 2 Header | |		X | Layer 2 Header | |
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	TC S TTL		TC S TTL
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	Y | Label-1 | TC |0| TTL | |		Y | Label-1 | TC |0| TTL | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label-2 | TC |0| TTL | |		| Label-2 | TC |0| TTL | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... | TC |0| TTL | |		| ... | TC |0| TTL | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label-n | TC |1| TTL | |		| Label-n | TC |1| TTL | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	Figure 1: Example of an MPLS Packet With Label Stack		Figure 1: Example of an MPLS Packet with Label Stack
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	A | (PFN) | IP header | |		A | (PFN) | IP header | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| data | |		| data | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... |		... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| end of IP packet | |		| end of IP packet | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	skipping to change at page 6, line 37 ¶		skipping to change at line 266 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PSH | |		| PSH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... |		... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| end of PSH | |		| end of PSH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| embedded packet | |		| embedded packet | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	Figure 2: Examples of an MPLS Packet Payload With and Without		Figure 2: Examples of an MPLS Packet Payload With and Without a
	Post-Stack Header		Preceding Post-Stack Header
	Figure 1 shows an MPLS packet with Layer 2 header X and a label stack		Figure 1 shows an MPLS packet with a Layer 2 header X and a label
	Y ending with Label-n. Then, there are three examples of an MPLS		stack Y ending with Label-n. Figure 2 displays three examples of an
	payload displayed in Figure 2. The complete MPLS packet thus would		MPLS payload:
	consist of [X Y A], or [X Y B], or [X Y C].
	A. The first payload is a bare IP packet, i.e., no PSH. The PFN in		Example A: The first payload is a bare IP packet, i.e., no PSH. The
	this case overlaps with the IP version number.		PFN in this case overlaps with the IP version number.
	B. The next payload is a bare non-IP packet; again, no PSH. The PFN		Example B: The next payload is a bare non-IP packet; again, no PSH.
	here is the first nibble of the payload, whatever it happens to be.		The PFN here is the first nibble of the payload, whatever it
			happens to be.
	C. The last example is an MPLS Payload that starts with a PSH		Example C: This example is an MPLS Payload that follows a PSH.
	followed by the embedded packet. Here, the embedded packet could be		Here, the embedded packet could be IP or non-IP.
	IP or non-IP.
			Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or
			[X Y C].
	2. Rationale		2. Rationale
	2.1. Why Look at the First Nibble		2.1. Why Look at the First Nibble
	An MPLS packet can contain one of many types of embedded packets.		An MPLS packet can contain one of many types of embedded packets.
	Three common types are:		Three common types are:
	1. An IPv4 packet (whose IP header has version number 4).		1. An IPv4 packet (whose IP header has version number 4).
	2. An IPv6 packet (whose IP header has version number 6).		2. An IPv6 packet (whose IP header has version number 6).
	3. A Layer 2 Ethernet frame (i.e., not including the Preamble or the		3. A Layer 2 Ethernet frame (i.e., not including the Preamble or the
	Start frame delimiter), starting with the destination MAC		Start frame delimiter), starting with the destination Media
	address.		Access Control (MAC) address.
	Many other packet types are possible; in principle, any Layer 2		Many other packet types are possible; in principle, any Layer 2
	embedded packet is permissible. Indeed, at some points in time,		embedded packet is permissible. Indeed, at some points in time,
	packets of Point-to-Point Protocol, Frame Relay, and Asynchronous		packets of the Point-to-Point Protocol, Frame Relay, and Asynchronous
	Transfer Mode protocols were reasonably common, and may become so		Transfer Mode were reasonably common and may become so again.
	again.
	In addition, there may be a PSH ahead of the embedded packet. The		In addition, there may be a PSH ahead of the embedded packet. The
	value of PFN is considered to ensure that the PSH can be correctly		value of PFN is considered to ensure that the PSH can be correctly
	parsed.		parsed.
	2.1.1. ECMP Load Balancing		2.1.1. ECMP Load Balancing
	There are four common ways to load balance an MPLS packet:		There are four common ways to load balance an MPLS packet:
	1. One can use the top label alone.		1. Use the top label alone.
	2. One can do better by using all of the non-SPLs (Special Purpose		2. Use all of the non-SPLs [RFC7274] in the stack. This is better
	Labels) [RFC7274] in the stack.		than using the top label alone.
	3. One can do even better by "divining" the type of embedded packet,		3. "Divine" the type of embedded packet and use fields from the
	and using fields from the guessed header. The ramifications of		guessed header. The ramifications of using this load-balancing
	using this load-balancing technique are discussed in detail in		technique are discussed in detail in Section 2.1.1.1. This way
	Section 2.1.1.1.		is better than the two ways above.
	4. One can do best by using either an Entropy Label [RFC6790] or a		4. Use either an Entropy Label [RFC6790] or a Flow-Aware Transport
	Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see		(FAT) Pseudowire Label [RFC6391] (see Section 2.1.1.1). This is
	Section 2.1.1.1).		the best way.
	Load balancing based on just the top label means that all packets		Load balancing based on just the top label means that all packets
	with that top label will go the same way -- this is far from ideal.		with that top label will go the same way, which is far from ideal.
	Load balancing based on the entire label stack (not including SPLs)		Load balancing based on the entire label stack (not including SPLs)
	is better, but it may still be uneven. If, however, the embedded		is better, but it may still be uneven. However, if the embedded
	packet is an IP packet, then the combination of (<source IP address>,		packet is an IP packet, then the combination of (<source IP address>,
	<dest IP address>, <transport protocol>, <source port>, and <dest		<dest IP address>, <transport protocol>, <source port>, and <dest
	port>) from the IP header of the embedded packet forms an excellent		port>) from the IP header of the embedded packet forms an excellent
	basis for load-balancing. This is what is typically used for load		basis for load balancing. This is what is typically used for load
	balancing IP packets.		balancing IP packets.
	An MPLS packet doesn't, however, carry a payload type identifier.		An MPLS packet doesn't, however, carry a payload type identifier.
	There is a simple (but risky) heuristic that is commonly used to		There is a simple (but risky) heuristic that is commonly used to
	guess the type of the embedded packet. The first nibble, i.e., the		guess the type of the embedded packet. The first nibble of an IP
	four most significant bits of the first octet, of an IP header		header, i.e., the four most significant bits of the first octet,
	contains the IP version number. That, in turn, indicates where to		contains the IP version number. That, in turn, indicates where to
	find the relevant fields for load-balancing. The heuristic goes		find the relevant fields for load balancing. The heuristic goes
	roughly as described in Section 2.1.1.1.		roughly as described in Section 2.1.1.1.
	2.1.1.1. Heuristic for ECMP Load Balancing		2.1.1.1. Heuristic for ECMP Load Balancing
	1. If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet,		1. If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet,
	and find the relevant fields for load-balancing on that basis.		and find the relevant fields for load balancing on that basis.
	2. If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet,		2. If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet,
	and find the relevant fields for load-balancing on that basis.		and find the relevant fields for load balancing on that basis.
	3. If the PFN is anything else, the MPLS payload is not an IP		3. If the PFN is anything else, the MPLS payload is not an IP
	packet; fall back to load-balancing using the label stack.		packet; fall back to load balancing using the label stack.
	This heuristic has been implemented in many (legacy) routers, and		This heuristic has been implemented in many (legacy) routers and
	performs well in the case of Figure 2, A. However, this heuristic		performs well in the case of example A in Figure 2. However, this
	can work very badly for non-IP packet as shown in Figure 2, B. For		heuristic can work very badly for the non-IP packet as shown in
	example, if payload B is an Ethernet frame, then the PFN is the first		example B in Figure 2. For example, if payload B is an Ethernet
	nibble of the Organizationally Unique Identifier of the destination		frame, then the PFN is the first nibble of the Organizationally
	MAC address, which can be 0x4 or 0x6, and if so would lead to the		Unique Identifier of the destination MAC address, which can be 0x4 or
	packet being treated as an IPv4 or IPv6 packet such that data at the		0x6. This would lead to the packet being treated as an IPv4 or IPv6
	offsets of specific relevant fields would be used as input to the		packet such that data at the offsets of specific relevant fields
	load-balancing heuristic resulting in unpredictable load balancing.		would be used as input to the load-balancing heuristic, resulting in
	This behavior can happen to other types of non-IP payloads as well.		unpredictable load balancing. This behavior can happen to other
			types of non-IP payloads as well.
	That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire		That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire
	control word [RFC4385], a DetNet control word [RFC8964], a Network		control word [RFC4385], a Deterministic Networking (DetNet) control
	Service Header [RFC8300], or a BIER header [RFC8296]) where the PFN		word [RFC8964], a Network Service Header (NSH) [RFC8300], or a BIER
	is not 0x4 or 0x6, to explicitly prevent forwarding engines from		header [RFC8296]) where the PFN is not 0x4 or 0x6; this explicitly
	confusing the MPLS payload with an IP packet. [RFC8469] recommends		prevents forwarding engines from confusing the MPLS payload with an
	the use of a control word when the embedded packet is an Ethernet		IP packet. [RFC8469] recommends the use of a control word when the
	frame. RFC 8469 was published at the request of the operator		embedded packet is an Ethernet frame. [RFC8469] was published at the
	community and the IEEE Registration Authority Committee as a result		request of the operator community and the IEEE Registration Authority
	of operational difficulties with pseudowires that did not contain the		Committee as a result of operational difficulties with pseudowires
	control word.		that did not contain the control word.
	It is RECOMMENDED that where load-balancing of MPLS packets is		Where load balancing of MPLS packets is desired, it is RECOMMENDED
	desired, the load-balancing mechanism uses the value of a dedicated		that the load-balancing mechanism use the value of a dedicated label,
	label, for example, either an Entropy Label [RFC6790] or a FAT		for example, either an Entropy Label [RFC6790] or a FAT Pseudowire
	Pseudowire Label [RFC6391]. Furthermore, the heuristic of guessing		Label [RFC6391]. Furthermore, the heuristic of guessing the type of
	the type of the embedded packet, as discussed above, SHOULD NOT be		the embedded packet, as discussed above, SHOULD NOT be used.
	used.
	A consequence of the heuristic approach is that while legacy routers		A consequence of the heuristic approach is that while legacy routers
	may look for a PFN of 0x4 [RFC0791] or 0x6 [RFC8200], no legacy		may look for a PFN of 0x4 [RFC0791] or 0x6 [RFC8200], no legacy
	router will look for any other PFN, regardless of what future IP		router will look for any other PFN for load-balancing purposes,
	version numbers will be, for load-balancing purposes. This means		regardless of what future IP version numbers will be. This means
	that the values 0x4 and 0x6 are used to (sometimes incorrectly)		that the values 0x4 and 0x6 are used to (sometimes incorrectly)
	identify IPv4 and IPv6 packets, but no other of PFN values will be		identify IPv4 and IPv6 packets, but no other PFN values will be used
	used to identify IP packets.		to identify IP packets.
	This document creates a new PFN Registry for all 16 possible values.		This document creates a new registry for all 16 possible values (see
			Section 3).
	2.2. Updates of RFC 4928		2.2. Updates to RFC 4928
	The text in RFC 4928 [RFC4928] concerning the first nibble after the		The text in RFC 4928 [RFC4928] concerning the first nibble after the
	MPLS Label Stack has been updated by this document and the heuristic		MPLS label stack has been updated by this document, and the heuristic
	for snooping this nibble has been deprecated. RFC 4928 is now		for snooping this nibble has been deprecated. Section 3 of [RFC4928]
	updated as follows:		is updated as follows:
	OLD TEXT		OLD TEXT:
	| It is REQUIRED, however, that applications dependent upon in-order		| It is REQUIRED, however, that applications depend upon in-order
	| packet delivery restrict the first nibble values to 0x0 and 0x1.		| packet delivery restrict the first nibble values to 0x0 and 0x1.
	| This will ensure that their traffic flows will not be affected if		| This will ensure that their traffic flows will not be affected if
	| some future routing equipment does similar snooping on some future		| some future routing equipment does similar snooping on some future
	| version(s) of IP.		| version(s) of IP.
	NEW TEXT:		NEW TEXT:
	| Network equipment MUST use a PSH (Post-Stack Header) with a PFN		| Network equipment MUST use a PSH (Post-Stack Header) with a PFN
	| (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all		| (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all
	| cases when the MPLS payload is neither an IPv6 nor an IPv4 packet.		| cases where the MPLS payload is neither an IPv6 nor an IPv4
			| packet.
	The requirement (see Section 2.1.1.1) replaces the paragraph 4 in		The following requirement (discussed is Section 2.1.1.1) replaces
	Section 3 of RFC 4928 [RFC4928] as follows:		paragraph 4 in Section 3 of [RFC4928] as follows:
	OLD TEXT:		OLD TEXT:
	| This behavior implies that if in the future an IP version is		| This behavior implies that if in the future an IP version is
	| defined with a version number of 0x0 or 0x1, then equipment		| defined with a version number of 0x0 or 0x1, then equipment
	| complying with this BCP would be unable to look past one or more		| complying with this BCP would be unable to look past one or more
	| MPLS headers, and load-split traffic from a single LSP across		| MPLS headers, and loadsplit traffic from a single LSP across
	| multiple paths based on a hash of specific fields in the IPv0 or		| multiple paths based on a hash of specific fields in the IPv0 or
	| IPv1 headers. That is, IP traffic employing these version numbers		| IPv1 headers. That is, IP traffic employing these version numbers
	| would be safe from disturbances caused by inappropriate load-		| would be safe from disturbances caused by inappropriate
	| splitting, but would also not be able to get the performance		| loadsplitting, but would also not be able to get the performance
	| benefits.		| benefits.
	NEW TEXT:		NEW TEXT:
	| The practice of deducing the payload type based on the PFN value		| The practice of deducing the payload type based on the PFN value
	| is deprecated to avoid inaccurate load balancing. This MUST NOT		| is deprecated to avoid inaccurate load balancing. This MUST NOT
	| be part of new implementations or deployments. It also means that		| be part of new implementations or deployments. This also means
	| concerns about load balancing for future IP versions with a		| that concerns about load balancing for future IP versions with a
	| version number of 0x0 or 0x1 are no longer relevant.		| version number of 0x0 or 0x1 are no longer relevant.
	END		Furthermore, the following text is appended to Section 1.1 of
			[RFC4928]:
	Furthermore, the following text is appended to Section 1.1 of RFC
	4928 [RFC4928]:
	NEW TEXT:		NEW TEXT:
	| PSH: Post-Stack Header		| PSH: Post-Stack Header
	|		|
	| PFN: Post-stack First Nibble		| PFN: Post-stack First Nibble
	END
	2.3. Why Create a Registry		2.3. Why Create a Registry
	Support for MPLS Network Actions (MNAs) is described in		The framework for MPLS Network Actions (MNAs) is described in
	[I-D.ietf-mpls-mna-fwk] and is an enhancement to the MPLS		[RFC9789] and is an enhancement to the MPLS architecture. The use of
	architecture. The use of post-stack data (PSD) to encode the MNA		Post-Stack Data (PSD) to encode the MNA indicators and ancillary data
	indicators and ancillary data is described in section 3.6 might place		(described in Section 3.6 of [RFC9789]) might place data in the PFN,
	data in the PFN that could conflict with other uses of that nibble.		which could conflict with other uses of that nibble. This issue is
	This issue is described in section 3.6.1 of [I-D.ietf-mpls-mna-fwk]		described in Section 3.6.1 of [RFC9789] and is further illustrated by
	and is further illustrated by the PFN value of 0x0 which has two		the PFN value of 0x0, which has two different formats depending on
	different formats depending on whether the PSH is a pseudowire		whether the PSH is a pseudowire control word or a DetNet control
	control word or a DetNet control word: disambiguation requires the		word; disambiguation requires the context of the service label.
	context of the service label.
	With a registry, PSHs become easier to identify and parse; not		With a registry, PSHs become easier to identify and parse. In
	needing any means outside the data plane to interpret them correctly;		addition, they do not need a means outside the data plane to
	and their semantics and usage are documented and referenced from the		interpret them correctly, and their semantics and usage are
	registry.		documented and referenced in the registry.
	2.4. IP Version Numbers versus Post-stack First Nibble Values		2.4. IP Version Numbers Versus Post-Stack First Nibble Values
	The use of the PFN stemmed from the desire to heuristically identify		The use of the PFN stemmed from the desire to heuristically identify
	IP packets for load-balancing purposes. It was then discovered that		IP packets for load-balancing purposes. It was then discovered that
	non-IP packets, misidentified as IP when the heuristic failed, were		non-IP packets, misidentified as IP when the heuristic failed, were
	being badly load balanced, leading to [RFC4928]. This situation may		being badly load balanced, leading to the scenario described in
	confuse some as to the relationship between the Post-stack First		[RFC4928]. This situation may confuse some as to the relationship
	Nibble Registry and the IP Version Numbers registry. These		between the "Post-Stack First Nibble" registry and the "IP Version
	registries are quite different:		Numbers" registry. These registries are quite different:
	1. The IP Version Numbers registry's explicit purpose is to track IP		1. The explicit purpose of the "IP Version Numbers" registry is to
	version numbers in an IP header.		track IP version numbers in an IP header.
	2. The Post-stack First Nibble registry's purpose is to track PSH		2. The purpose of the "Post-Stack First Nibble" registry is to track
	types.		PSH types.
	The only intersection points between the two registries is for values		The only intersection points between the two registries are the
	0x4 and 0x6 (for backward compatibility).		values 0x4 and 0x6 (for backward compatibility).
	2.5. Next Step to More Deterministic Load-balancing in MPLS Networks		2.5. Next Step to More Deterministic Load Balancing in MPLS Networks
	Network evolution is impossible to control, but it develops over a		Network evolution is impossible to control, but it develops over a
	period of time determined by various factors.		period of time determined by various factors.
	This document discourages further proliferation of the		This document discourages further proliferation of the
	implementations that could lead to undesired effects affecting data		implementations that could lead to undesired effects on data flows.
	flows. In doing so, it limits the scope of future protocol		In doing so, it limits the scope of future protocol developments and
	developments, and so helps to ensure that future network evolution		thus helps to ensure that future network evolution will be smoother.
	will be smoother.
	It would assist with the progress toward a simpler, more coherent		Section 2 of [RFC4385] suggests the use of a PSH solely for the
	system of MPLS data encapsulation if the use a PSH for non-IP		purpose of avoiding IP ECMP treatment of non-IP payloads encapsulated
	payloads encapsulated in MPLS was obsoleted. However, before that		in MPLS. Obsoleting this use of a PSH would assist with the progress
	can be done, it is important to collect sufficient evidence that		toward a simpler, more coherent system of MPLS data encapsulation.
	there are no marketed or deployed implementations using the heuristic		(Other uses of a PSH may still be valid.) However, before that can
	practice to load-balancing MPLS data flows.		be done, it is important to collect sufficient evidence that there
			are no marketed or deployed implementations using the heuristic
			practice to load balance MPLS data flows.
	The next step, therefore, toward more deterministic load-balancing in		Therefore, the next steps toward more deterministic load balancing in
	MPLS networks is to gradulally deprecate non-PSH MPLS encapsulations		MPLS networks are to gradually deprecate non-PSH MPLS encapsulations
	of non-IP data, to cease using heuristic load-balancing, and to		of non-IP data, to cease using heuristic load balancing, and to
	survey the available and deployed implementations to determine when		survey the available and deployed implementations to determine when
	obsoletion may be achieved.		obsoletion may be achieved.
	3. IANA Considerations		3. IANA Considerations
	3.1. The Post-stack First Nibble Registry		Per this document, IANA has created a registry group called "Post-
			Stack First Nibble" that consists of a single registry called the
	This document requests IANA to create a registry group called "Post-		"Post-Stack First Nibble" registry. The initial contents of the
	Stack First Nibble Registry" that consists of a single registry		registry are shown in Table 1. The assignment policy is Standards
	called "Post-Stack First Nibble Registry". The registry should be		Action [RFC8126]. It is important to note that the same PFN value
	created as shown in Table 1. The assignment policy for the registry		can be used in more than one protocol. The correct interpretation of
	is Standards Action [RFC8126]. It is important to note, that the		the PFN in a PSH can be made only in the context of the LSE or group
	same PFN value can be used in more than one protocol. The correct		of LSEs in the preceding label stack that characterizes the type of
	interpretation of the PFN in a PSH can be made only in the context of		the PSH and, consequently, the PFN.
	the LSE or a group of LSEs in the preceding label stack that
	characterize the type of the PSH and, consequently, PFN.
	+==========+=======+==============================+===========+		+==========+=======+=================================+===========+
	| Protocol | Value | Description | Reference |		| Protocol | Value | Description | Reference |
	+==========+=======+==============================+===========+		+==========+=======+=================================+===========+
	| DetNet | 0x0 | DetNet Control Word | RFC 8964 |		| DetNet | 0x0 | DetNet Control Word | [RFC8964] |
	+----------+-------+------------------------------+-----------+		+----------+-------+---------------------------------+-----------+
	| NSH | 0x0 | NSH (Network Service Header) | RFC 8300 |		| NSH | 0x0 | NSH Base Header, payload | [RFC8300] |
	| | | Base Header, payload | |		+----------+-------+---------------------------------+-----------+
	+----------+-------+------------------------------+-----------+		| PW | 0x0 | PW Control Word | [RFC4385] |
	| PW | 0x0 | PW Control Word | RFC 4385 |		+----------+-------+---------------------------------+-----------+
	+----------+-------+------------------------------+-----------+		| DetNet | 0x1 | DetNet Associated Channel | [RFC9546] |
	| DetNet | 0x1 | DetNet Associated Channel | RFC 9546 |		+----------+-------+---------------------------------+-----------+
	+----------+-------+------------------------------+-----------+		| MPLS | 0x1 | MPLS Generic Associated Channel | [RFC5586] |
	| MPLS | 0x1 | MPLS Generic Associated | RFC 5586 |		+----------+-------+---------------------------------+-----------+
	| | | Channel | |		| PW | 0x1 | PW Associated Channel | [RFC4385] |
	+----------+-------+------------------------------+-----------+		+----------+-------+---------------------------------+-----------+
	| PW | 0x1 | PW Associated Channel | RFC 4385 |		| NSH | 0x2 | NSH Base Header, OAM | [RFC8300] |
	+----------+-------+------------------------------+-----------+		+----------+-------+---------------------------------+-----------+
	| NSH | 0x2 | NSH Base Header, OAM | RFC 8300 |		| | 0x3 | Unassigned | |
	+----------+-------+------------------------------+-----------+		+----------+-------+---------------------------------+-----------+
	| | 0x3 | Unassigned | |		| | 0x4 | Reserved | this |
	+----------+-------+------------------------------+-----------+		| | | | document |
	| | 0x4 | Reserved, not to be assigned | |		+----------+-------+---------------------------------+-----------+
	+----------+-------+------------------------------+-----------+		| BIER | 0x5 | BIER Header | [RFC8296] |
	| BIER | 0x5 | BIER Header | RFC 8296 |		+----------+-------+---------------------------------+-----------+
	+----------+-------+------------------------------+-----------+		| | 0x6 | Reserved | this |
	| | 0x6 | Reserved, not to be assigned | |		| | | | document |
	+----------+-------+------------------------------+-----------+		+----------+-------+---------------------------------+-----------+
	| | 0x7 - | Unassigned | |		| | 0x7 - | Unassigned | |
	| | 0xF | | |		| | 0xF | | |
	+----------+-------+------------------------------+-----------+		+----------+-------+---------------------------------+-----------+
	Table 1: Post-stack First Nibble Values		Table 1: Post-Stack First Nibble Registry
	4. Security Considerations		4. Security Considerations
	This document creates a new IANA registry for and specifies changes		This document creates a new IANA registry for PFNs and specifies
	to the treatment in the data plane of packets based on the first		changes to the treatment of packets in the data plane based on the
	nibble of data beyond the MPLS label stack. One intent of this is to		first nibble of data beyond the MPLS label stack. One intent of this
	reduce or eliminate errors in determining whether a packet being		is to reduce or eliminate errors in determining whether or not a
	transported by MPLS is IP or not. While such errors have primarily		packet being transported by MPLS is IP. While such errors have
	caused unbalanced and, thus, inefficient multi-pathing, they have the		primarily caused unbalanced, and thus inefficient, multipathing, they
	potential to cause more severe security problems.		have the potential to cause more severe security problems.
	For general MPLS label stack security considerations, see [RFC3032].
	5. Acknowledgements
	The authors express their appreciation and gratitude to Donald E.
	Eastlake 3rd for the review, insightful questions, and helpful
	comments. Also, the authors are gateful to Amanda Baber for helping
	organize the IANA registry in clear and consise manner.
	Eric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and
	Gunter Van de Velde provided helpful comments during IESG review.
	6. References		For general security considerations involving the MPLS label stack,
			see [RFC3032].
	6.1. Normative References		5. References
	[I-D.ietf-mpls-mna-fwk]		5.1. Normative References
	Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
	Network Actions (MNA) Framework", Work in Progress,
	Internet-Draft, draft-ietf-mpls-mna-fwk-14, 2 December
	2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
	mpls-mna-fwk-14>.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 15, line 15 ¶		skipping to change at line 644 ¶
	[RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to		[RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to
	Use the Ethernet Control Word", RFC 8469,		Use the Ethernet Control Word", RFC 8469,
	DOI 10.17487/RFC8469, November 2018,		DOI 10.17487/RFC8469, November 2018,
	<https://www.rfc-editor.org/info/rfc8469>.		<https://www.rfc-editor.org/info/rfc8469>.
	[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,		[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
	S., and J. Korhonen, "Deterministic Networking (DetNet)		S., and J. Korhonen, "Deterministic Networking (DetNet)
	Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January		Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
	2021, <https://www.rfc-editor.org/info/rfc8964>.		2021, <https://www.rfc-editor.org/info/rfc8964>.
	6.2. Informative References		[RFC9789] Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
			Network Actions (MNAs) Framework", RFC 9789,
			DOI 10.17487/RFC9789, July 2025,
			<https://www.rfc-editor.org/info/rfc9789>.
			5.2. Informative References
			[MNA-PS-HDR]
			Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Li,
			T., and J. Dong, "Post-Stack MPLS Network Action (MNA)
			Solution", Work in Progress, Internet-Draft, draft-ietf-
			mpls-mna-ps-hdr-01, 30 May 2025,
			<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
			mna-ps-hdr-01>.
	[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge		[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	Emulation (PWE3)", BCP 116, RFC 4446,		Emulation (PWE3)", BCP 116, RFC 4446,
	DOI 10.17487/RFC4446, April 2006,		DOI 10.17487/RFC4446, April 2006,
	<https://www.rfc-editor.org/info/rfc4446>.		<https://www.rfc-editor.org/info/rfc4446>.
	[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private		[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
	LAN Service (VPLS) Using BGP for Auto-Discovery and		LAN Service (VPLS) Using BGP for Auto-Discovery and
	Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,		Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
	<https://www.rfc-editor.org/info/rfc4761>.		<https://www.rfc-editor.org/info/rfc4761>.
	skipping to change at page 16, line 16 ¶		skipping to change at line 705 ¶
	"Network Service Header (NSH)", RFC 8300,		"Network Service Header (NSH)", RFC 8300,
	DOI 10.17487/RFC8300, January 2018,		DOI 10.17487/RFC8300, January 2018,
	<https://www.rfc-editor.org/info/rfc8300>.		<https://www.rfc-editor.org/info/rfc8300>.
	[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,		[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,
	Administration, and Maintenance (OAM) for Deterministic		Administration, and Maintenance (OAM) for Deterministic
	Networking (DetNet) with the MPLS Data Plane", RFC 9546,		Networking (DetNet) with the MPLS Data Plane", RFC 9546,
	DOI 10.17487/RFC9546, February 2024,		DOI 10.17487/RFC9546, February 2024,
	<https://www.rfc-editor.org/info/rfc9546>.		<https://www.rfc-editor.org/info/rfc9546>.
			Acknowledgements
			The authors express their appreciation and gratitude to Donald
			E. Eastlake 3rd for the review, insightful questions, and helpful
			comments. Also, the authors are grateful to Amanda Baber for helping
			organize the IANA registry in a clear and concise manner.
			Éric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and
			Gunter Van de Velde provided helpful comments during IESG review.
			The authors would also like to thank Adrian Farrel for his patient
			and careful shepherding and for helping to finalize the text.
	Authors' Addresses		Authors' Addresses
	Kireeti Kompella		Kireeti Kompella
	Juniper Networks		Juniper Networks
	1133 Innovation Way		1133 Innovation Way
	Sunnyvale, 94089		Sunnyvale, CA 94089
	United States of America		United States of America
	Email: kireeti.ietf@gmail.com		Email: kireeti.ietf@gmail.com
	Stewart Bryant		Stewart Bryant
	University of Surrey 5GIC		University of Surrey 5GIC
	Email: sb@stewartbryant.com		Email: sb@stewartbryant.com
	Matthew Bocci		Matthew Bocci
	Nokia		Nokia
	Email: matthew.bocci@nokia.com		Email: matthew.bocci@nokia.com
	skipping to change at page 16, line 44 ¶		skipping to change at line 746 ¶
	Ericsson		Ericsson
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com
	Loa Andersson		Loa Andersson
	Huawei Technologies		Huawei Technologies
	Email: loa@pi.nu		Email: loa@pi.nu
	Jie Dong		Jie Dong
	Huawei Technologies		Huawei Technologies
	Huawei Campus, No. 156 Beiqing Rd.		Huawei Campus, No. 156 Beiqing Rd.
	Beijing, 100095		Beijing
			100095
	China		China
	Email: jie.dong@huawei.com		Email: jie.dong@huawei.com
End of changes. 97 change blocks.
	322 lines changed or deleted		333 lines changed or added
This html diff was produced by rfcdiff 1.48.