draft-ietf-mpls-1stnibble-08.txt		draft-ietf-mpls-1stnibble-09.txt
	MPLS Working Group K. Kompella		MPLS Working Group K. Kompella
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Updates: 4928 (if approved) S. Bryant		Updates: 4928 (if approved) S. Bryant
	Intended status: Standards Track University of Surrey 5GIC		Intended status: Standards Track University of Surrey 5GIC
	Expires: 20 December 2024 M. Bocci		Expires: 26 January 2025 M. Bocci
	Nokia		Nokia
	G. Mirsky, Ed.		G. Mirsky, Ed.
	Ericsson		Ericsson
	L. Andersson		L. Andersson
	J. Dong		J. Dong
	Huawei Technologies		Huawei Technologies
	18 June 2024		25 July 2024
	IANA Registry for the First Nibble Following a Label Stack		IANA Registry for the First Nibble Following a Label Stack
	draft-ietf-mpls-1stnibble-08		draft-ietf-mpls-1stnibble-09
	Abstract		Abstract
	The goal of this memo is to create a new IANA registry (called the		This memo creates a new IANA registry (called the Post-stack First
	Post-stack First Nibble registry) for the first nibble (4-bit field)		Nibble registry) for the first nibble (4-bit field) immediately
	immediately following an MPLS label stack. The memo offers a		following an MPLS label stack. The memo offers a rationale for such
	rationale for such a registry, describes how the registry should be		a registry, describes how the registry should be managed, and
	managed, and provides some initial entries. Furthermore, this memo		provides some initial entries. Furthermore, this memo sets out some
	sets out some documentation requirements for registering new values.		documentation requirements for registering new values. Finally, it
	Finally, it provides some recommendations that make processing MPLS		provides some recommendations that make processing MPLS packets
	packets easier and more robust.		easier and more robust.
	The relationship between the IANA IP Version Numbers (RFC 2780) and		The relationship between the IANA IP Version Numbers (RFC 2780) and
	the Post-stack First Nibble registry is described in this document.		the Post-stack First Nibble registry is described in this document.
	This memo, if published, would update RFC 4928.		This document updates RFC 4928 by deprecating the heuristic method
			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 Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 20 December 2024.		This Internet-Draft will expire on 26 January 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3		1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4
	1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Reference Figures . . . . . . . . . . . . . . . . . . . . 4
	2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Why Look at the First Nibble . . . . . . . . . . . . . . 6		2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1.1. Load Balancing . . . . . . . . . . . . . . . . . . . 6		2.1. Why Look at the First Nibble . . . . . . . . . . . . . . 7
	2.2. Updates of RFC 4928 . . . . . . . . . . . . . . . . . . . 8		2.1.1. Load Balancing . . . . . . . . . . . . . . . . . . . 8
	2.3. Why Create a Registry . . . . . . . . . . . . . . . . . . 10		2.2. Updates of RFC 4928 . . . . . . . . . . . . . . . . . . . 9
			2.3. Why Create a Registry . . . . . . . . . . . . . . . . . . 11
	2.4. IP Version Numbers versus Post-stack First Nibble		2.4. IP Version Numbers versus Post-stack First Nibble
	Values . . . . . . . . . . . . . . . . . . . . . . . . . 10		Values . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		2.5. Next Step to More Deterministic Load -balancing in an MPLS
	3.1. The Post-stack First Nibble Registry . . . . . . . . . . 11		Network . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 12		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		3.1. The Post-stack First Nibble Registry . . . . . . . . . . 12
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6.1. Normative References . . . . . . . . . . . . . . . . . . 12		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	6.2. Informative References . . . . . . . . . . . . . . . . . 14		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		6.1. Normative References . . . . . . . . . . . . . . . . . . 14
			6.2. Informative References . . . . . . . . . . . . . . . . . 15
			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). By		header" (PSH) and an optional embedded packet (in that order). By
	PSH, we mean existing artifacts such as Control Words, BIER headers		PSH, we mean existing artifacts such as Control Words [RFC4385], BIER
	and the like, as well as new types of PSH being discussed by the MPLS		headers [RFC8296] and the like, as well as new types of PSH being
	Working Group. However, in the data plane, there are scant clues		discussed by the MPLS Working Group. However, in the data plane,
	regarding the PSH, and no clue as to the type of embedded packet;		there are scant clues regarding the PSH, and no clue as to the type
	this information is communicated via other means, such as the routing		of embedded packet; this information is communicated via other means,
	protocols that signal the labels in the stack. Nonetheless, in order		such as the routing protocols that signal the labels in the stack.
	to better handle an MPLS packet in the data plane, it is common		Nonetheless, in order to better handle an MPLS packet in the data
	practice for network equipment to "guess" the type of embedded		plane, it is common practice for network equipment to "guess" the
	packet. Such equipment may also need to process the PSH. Both of		type of embedded packet. Such equipment may also need to process the
	these require parsing the data after the label stack. To do this,		PSH. Both of these require parsing the data after the label stack.
	the "first nibble" (the top four bits of the first octet following		To do this, the "first nibble" (the top four bits of the first octet
	the label stack) is often used. Although some existing network		following the label stack) is often used. Although some existing
	devices may use such a method, it needs to be stressed that the		network devices may use such a method, it needs to be stressed that
	correct interpretation of the Post-stack First Nibble (PFN) in a PSH		the correct interpretation of the Post-stack First Nibble (PFN) in a
	can be made only in the context of the Label Stack Element (LSE) or		PSH can be made only in the context associated using the control or
	group of LSEs in the preceding label stack that characterize the type		management plane with the Label Stack Element (LSE) or group of LSEs
	of the PSH, and that any attempt to rely on the value in any other		in the preceding label stack that characterize the type of the PSH,
	context is unreliable.		and that any attempt to rely on the value in any other context is
			unreliable.
	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 memo serves four purposes:		nor are the assignments of values. This memo serves four purposes:
	* To document the assignments already made.		* To document the values already in use.
	* To provide straightforward documentation of future assignments		* To provide a mechanism to document future assignments through the
	through the creation of a "Post-stack First Nibble registry".		creation of a "Post-stack First Nibble registry".
	* Provide a method for tracking usage by requiring more consistent		* 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 the importance that any MPLS packet not carrying plain
	IPv4 or IPv6 packets contains a PSH.		IPv4 or IPv6 packets contains a PSH, including any new version of
			IP (Section 2.4).
	This memo introduces a requirement and a recommendation. The first		This memo introduces a requirement and a recommendation. The first
	builds on Section 2.1.1, and the second deprecates the use of the		builds on Section 2.1.1, and the second deprecates the use of the
	heuristic in Section 2.1.1.1 and recommends using a dedicated label		heuristic in Section 2.1.1.1 and recommends using a dedicated label
	value for load balancing. The intent of both is for legacy routers		value for load balancing. The intent of both is for legacy routers
	to continue operating as they have, with no new problems introduced		to continue operating as they have, with no new problems introduced
	as a result of this memo. However, new implementations that follow		as a result of this memo. However, new implementations that follow
	this memo enable a more robust network operation.		this memo enable a more robust network operation.
	This document, if published, would update [RFC4928] by deprecating		This document updates [RFC4928] by deprecating the heuristic method
	the heuristic method for identifying the type of packet encapsulated		for identifying the type of packet encapsulated in MPLS. This
	in MPLS. This document clearly states that the type of encapsulated		document clearly states that the type of encapsulated packet cannot
	packet cannot be determined based on the PFN alone.		be determined based on the PFN alone.
	1.1. Conventions and Definitions		1.1. Conventions and Definitions
	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		"OPTIONAL" in this document are to be interpreted as described in BCP
	BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all		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.		MPLS packet: one whose Layer 2 header declares the type to be MPLS.
	For Ethernet, that means the Ethertype is 0x8847 or 0x8848.		For Ethernet, that means the Ethertype is 0x8847 or 0x8848.
	Label Stack: (of an MPLS packet) all labels (four-octet fields)		Label Stack: (of an MPLS packet) all labels (four-octet fields)
	after the Layer 2 header, up to and including the label with the		after the Layer 2 header, up to and including the label with the
	BoS bit set ([RFC3032]).		Bottom of Stack bit set ([RFC3032]).
	Post-stack First Nibble (PFN): the most significant four bits of the		Post-stack First Nibble (PFN): the most significant four bits of the
	first octet following the label stack.		first octet following the label stack.
	MPLS Payload: all data after the label stack, including the PFN, an		MPLS Payload: all data after the label stack, including the PFN, an
	optional post-stack header, and the embedded packet.		optional post-stack header, and the embedded packet.
	Post-stack Header (PSH): optional field of interest to the egress		Post-stack Header (PSH): optional field of interest to the egress
	LSR (and possibly to transit LSRs). Examples include a control		Label Switching Router (LSR) (and possibly to transit LSRs).
	word or an associated channel. The PSH MUST indicate its length,		Examples include a control word [RFC4385] or an associated channel
	so that a parser knows where the embedded packet starts.		[RFC4385], [RFC5586]. The PSH MUST indicate its length, so that a
			parser knows where the embedded packet starts.
	Embedded Packet: all octets beyond the PSH (if any). That could be		Embedded Packet: an embedded packet follows immediately after the
	an IPv4 or IPv6 packet , an Ethernet packet (for VPLS ([RFC4761],		MPLS Label Stack and an optional PSH. That could be an IPv4 or
	[RFC4762]) or EVPN [RFC7432]), or some other type of Layer 2 frame		IPv6 packet, an Ethernet packet (for VPLS ([RFC4761], [RFC4762])
	[RFC4446].		or EVPN [RFC7432]), or some other type of Layer 2 frame [RFC4446].
	Deprecation: regardless of how the deprecation is understood in		Deprecation: regardless of how the deprecation is understood in
	other IETF documents, the interpretation in this document is that		other IETF documents, the interpretation in this document is that
	if a practice has been deprecated, that practice should not be		if a practice has been deprecated, that practice should not be
	included in the new implementations or deployed in deployments.		included in new implementations or deployed in deployments.
			1.2. Reference Figures
	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 | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 37 ¶		skipping to change at page 6, line 37 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PSH | |		| PSH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	... |		... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| end of PSH | |		| end of PSH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| embedded packet | |		| embedded packet | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	Figure 2		Figure 2: Examples of an MPLS Packet Payload With and Without
			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 Layer 2 header X and a label stack
	Y ending with Label-n. Then, there are three examples of an MPLS		Y ending with Label-n. Then, there are three examples of an MPLS
	payload. The complete MPLS packet thus would consist of [X Y A], or		payload displayed in Figure 2. The complete MPLS packet thus would
	[X Y B], or [X Y C].		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		A. The first payload is a bare IP packet, i.e., no PSH. The PFN in
	this case overlaps with the IP version number.		this case overlaps with the IP version number.
	B. The next payload is a bare non-IP packet; again, no PSH. The PFN		B. The next payload is a bare non-IP packet; again, no PSH. The PFN
	here is the first nibble of the payload, whatever it happens to be.		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		C. The last example is an MPLS Payload that starts with a PSH
	followed by the embedded packet. Here, the embedded packet could be		followed by the embedded packet. Here, the embedded packet could be
	IP or non-IP.		IP or non-IP.
	1.2. Abbreviations		1.3. Abbreviations
	LSR: Label Switching Router		LSR: Label Switching Router
	LSE: Label Stack Element		LSE: Label Stack Element
	PSH: Post-Stack Header		PSH: Post-Stack Header
	PFN: Post-stack First Nibble		PFN: Post-stack First Nibble
	FAT: Flow-Aware Transport		FAT: Flow-Aware Transport
	SPL: Special Purpose Label		SPL: Special Purpose Label
	PW: Pseudowire		PW: Pseudowire
			MNA: MPLS Network Action
	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 many types of embedded packets. The most		An MPLS packet can contain one of many types of embedded packets.
	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 MAC
	address.		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, in the past, packets of		embedded packet is permissible. Indeed, in the past, packets of
	Point-to-Point Protocol, Frame Relay, and Asynchronous Transfer Mode		Point-to-Point Protocol, Frame Relay, and Asynchronous Transfer Mode
	protocols were reasonably common.		protocols were reasonably common.
	In addition, there may be a PSH ahead of the embedded packet, and it		In addition, there may be a PSH ahead of the embedded packet. The
	needs to be parsed. The PFN is currently used for both of these		value of PFN is considered to ensure that the PSH can be correctly
	purposes.		parsed. If no PSH follows the label stack, then the value of PFN
			indicates the version number of the IP packet header.
	2.1.1. Load Balancing		2.1.1. 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. One can use the top label alone.
	2. One can do better by using all of the non-SPL (Special Purpose		2. One can do better by using all of the non-SPLs (Special Purpose
	Label) labels in the stack.		Labels) labels[RFC7274] in the stack.
	3. One can do even better by "divining" the type of embedded packet,		3. One can do even better by "divining" the type of embedded packet,
	and using fields from the guessed header. The ramifications of		and using fields from the guessed header. The ramifications of
	using this load-balancing technique are discussed in detail in		using this load-balancing technique are discussed in detail in
	Section 2.2.		Section 2.1.1.1.
	4. One can do best by using either an Entropy Label [RFC6790] or a		4. One can do best by using either an Entropy Label [RFC6790] or a
	Flow-Aware Transport (FAT) Pseudowire Label [RFC6391]; see		Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see
	Section 2.2.)		Section 2.1.1.1).
	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 -- this 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. If, however, 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 dangerous) 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, i.e., the
	four most significant bits of the first octet, of an IP header		four most significant bits of the first octet, of an IP header
	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 Load Balancing		2.1.1.1. Heuristic for 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 Figure 2, A. However, this heuristic
	can work very badly for Figure 2, B. For example, if payload B is an		can work very badly for Figure 2, B. For example, if payload B is an
	Ethernet frame, then the PFN is the first nibble of the OUI of the		Ethernet frame, then the PFN is the first nibble of the
	destination MAC address, which can be 0x4 or 0x6, and if so would		Organizationally Unique Identifier of the destination MAC address,
	lead to very bad load-balancing. This behavior can happen to other		which can be 0x4 or 0x6, and if so would lead to the packet being
	types of non-IP payloads as well.		treated as an IPv4 or IPv6 packet such that data at the offsets of
			specific relevant fields would be used as input to the load-balancing
			heuristic resulting in 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] or a BIER		control word [RFC4385], a DetNet control word [RFC8964] or a BIER
	header [RFC8296]) where the PFN is not 0x4 or 0x6, to explicitly		header [RFC8296]) where the PFN is not 0x4 or 0x6, to explicitly
	prevent forwarding engines from confusing the MPLS payload with an IP		prevent forwarding engines from confusing the MPLS payload with an IP
	packet. [RFC8469] recommends the use of a control word when the		packet. [RFC8469] recommends the use of a control word when the
	embedded packet is an Ethernet frame. RFC 8469 was published at the		embedded packet is an Ethernet frame. RFC 8469 was published at the
	request of the operator community and the IEEE Registration Authority		request of the operator community and the IEEE Registration Authority
	Committee as a result of operational difficulties with pseudowires		Committee as a result of operational difficulties with pseudowires
	that did not contain the control word.		that did not contain the control word.
	It is RECOMMENDED that where load-balancing of MPLS packets is		It is RECOMMENDED that where load-balancing of MPLS packets is
	desired, the load-balancing mechanism uses the value of a dedicated		desired, the load-balancing mechanism uses the value of a dedicated
	label, for example, either an Entropy Label [RFC6790] or a FAT		label, for example, either an Entropy Label [RFC6790] or a FAT
	Pseudowire Label [RFC6391]. Furthermore, the heuristic of guessing		Pseudowire Label [RFC6391]. Furthermore, the heuristic of guessing
	the type of the embedded packet, as discussed above, SHOULD NOT be		the type of the embedded packet, as discussed above, SHOULD NOT be
	used.		used.
	A consequence of that 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 router will		may look for a PFN of 0x4 [RFC0791] or 0x6 [RFC8200], no legacy
	look for any other PFN, regardless of what future IP version numbers		router will look for any other PFN, regardless of what future IP
	will be, for load-balancing purposes. This means that the values 0x4		version numbers will be, for load-balancing purposes. This means
	and 0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6		that the values 0x4 and 0x6 are used to (sometimes incorrectly)
	packets, but no other First Nibble values will be used to identify IP		identify IPv4 and IPv6 packets, but no other of PFN values will be
	packets.		used to identify IP packets.
	This document creates a new PFN Registry for all 16 possible values.		This document creates a new PFN Registry for all 16 possible values.
	2.2. Updates of RFC 4928		2.2. Updates of RFC 4928
	Paragraph 3 in Section 3 of RFC 4928 [RFC4928] states that:		Paragraph 3 in Section 3 of RFC 4928 [RFC4928] states that:
	OLD TEXT		OLD TEXT
	| It is REQUIRED, however, that applications dependent upon in-order		| It is REQUIRED, however, that applications dependent 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.
	END		END
	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. RFC 4928 is now
	updated as follows:		updated as follows:
	NEW TEXT:		NEW TEXT:
	| Network equipment that complies with RFC XXXX MUST use a PSH		| Network equipment MUST use a PSH (Post-Stack Header) with a PFN
	| (Post-Stack Header) with a PFN (Post-stack First Nibble) value		| (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all
	| that is neither 0x4 nor 0x6 in all cases when the MPLS payload is		| cases when the MPLS payload is not an IP packet.
	| not an IP packet.
	END		END
	[RFC Ed.: Throughout the docuemnt, replace XXXX with the actual RFC
	number assigned to this document and remove this note.]
	The recommendation (see Section 2.1.1.1) replaces the paragraph 4 in		The recommendation (see Section 2.1.1.1) replaces the paragraph 4 in
	Section 3 of RFC 4928 [RFC4928] as follows:		Section 3 of RFC 4928 [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 load-split 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 load-
	| splitting, but would also not be able to get the performance		| splitting, but would also not be able to get the performance
	| benefits.		| benefits.
	NEW TEXT:		NEW TEXT:
	| RFC XXXX deprecated the practice of deducing the payload type to		| The practice of deducing the payload type based on the PFN value
	| avoid inaccurate load balancing based on the PFN value. This		| is deprecated to avoid inaccurate load balancing. This means that
	| means that older implementations and deployments can continue to		| means that older implementations and deployments can continue to
	| use that heuristic, while it must not be part of new		| use that heuristic, while it must not be part of new
	| implementations or deployments. The deprecation also means that		| implementations or deployments. It also means that concerns about
	| concerns about load balancing for future IP versions with a		| load balancing for future IP versions with a version number of 0x0
	| version number of 0x0 or 0x1 are now moot.		| or 0x1 are no longer relevant.
	|
	| At the time RFC XXXX was written, it was planned to obsolete MPLS
	| encapsulations without PSH of non-IP payload when sufficient
	| evidence exists that there are no marketed or deployed
	| implementations using the heuristic practice.
	END		END
	Furthermore, the following text is appended to Section 1.1 of RFC		Furthermore, the following text is appended to Section 1.1 of RFC
	4928 [RFC4928]:		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		END
	2.3. Why Create a Registry		2.3. Why Create a Registry
	The MPLS WG is currently engaged in updating the MPLS architecture;		Support for MPLS Network Actions (MNAs) is described in
	part of this work may involve the use of PSHs. That might be more		[I-D.ietf-mpls-mna-fwk] and is an enhancement to the MPLS
	challenging if PFN values are allocated on an ad hoc basis, and their		architecture. The use of post-stack data (PSD) to encode the MNA
	parsing and semantics are ill-specified. Consider that the PFN value		indicators and ancillary data is described in section 3.6 might place
	of 0x0 has two different formats, depending on whether the PSH is a		data in the PFN that could conflict with other uses of that nibble.
	pseudowire control word or a DetNet control word; disambiguation		This issue is described in section 3.6.1 of [I-D.ietf-mpls-mna-fwk]
	requires the context of the service label. This was a considered		and is further illustrated by the PFN value of 0x0 which has two
	decision; documenting this would be helpful to future implementors.		different formats depending on whether the PSH is a pseudowire
			control word or a DetNet control word: disambiguation requires the
			context of the service label.
			With a registry, PSHs become easier to parse; not needing means
			outside the data plane to interpret them correctly; and their
			semantics and usage are documented.
	With a registry, PSHs become easier to parse; not needing means		With a registry, PSHs become easier to parse; not needing means
	outside the data plane to interpret them correctly; and their		outside the data plane to interpret them correctly; and their
	semantics and usage are documented.		semantics and usage are documented.
	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
	skipping to change at page 11, line 5 ¶		skipping to change at page 12, line 10 ¶
	version numbers in an IP header.		version numbers in an IP header.
	2. The Post-stack First Nibble registry's purpose is to track PSH		2. The Post-stack First Nibble registry's purpose is to track PSH
	types.		types.
	The only intersection points between the two registries is for values		The only intersection points between the two registries is for values
	0x4 and 0x6 (for backward compatibility). There is no need to track		0x4 and 0x6 (for backward compatibility). There is no need to track
	future IP version number allocations in the Post-stack First Nibble		future IP version number allocations in the Post-stack First Nibble
	registry.		registry.
			2.5. Next Step to More Deterministic Load -balancing in an MPLS Network
			Network evolution is impossible to control, but it develops over a
			period of time determined by various factors. This document prevents
			further proliferation of the implementations that could lead to
			undesired effects affecting data flow. At some time in the future,
			it was planned to obsolete MPLS encapsulations without PSH of non-IP
			payload. Before that it is paramount to collect sufficient evidence
			that there are no marketed or deployed implementations using the
			heuristic practice to load-balancing MPLS data flows.
	3. IANA Considerations		3. IANA Considerations
	3.1. The Post-stack First Nibble Registry		3.1. The Post-stack First Nibble Registry
	This memo requests IANA to create a registry group called “Post-Stack		This memo requests IANA to create a registry group called "Post-Stack
	First Nibble Registry” that consists of a single registry called		First Nibble Registry" that consists of a single registry called
	"Post-Stack First Nibble Registry". The registry should be created		"Post-Stack First Nibble Registry". The registry should be created
	as shown in Table 1. The assignment policy for the registry is		as shown in Table 1. The assignment policy for the registry is
	Standards Action. It is important to note, that the same PFN value		Standards Action. It is important to note, that the same PFN value
	can be used in more than one protocol. The correct interpretation of		can be used in more than one protocol. The correct interpretation of
	the PFN in a PSH can be made only in the context of the LSE or a		the PFN in a PSH can be made only in the context of the LSE or a
	group of LSEs in the preceding label stack that characterize the type		group of LSEs in the preceding label stack that characterize the type
	of the PSH and, consequently, PFN.		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 | RFC 8964 |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
	| NSH | 0x0 | NSH Base Header, payload | RFC 8300 |		| NSH | 0x0 | NSH (Network Service Header) | RFC 8300 |
	+----------+-----------+------------------------------+-----------+		| | | Base Header, payload | |
	| PW | 0x0 | PW Control Word | RFC 4385 |		+----------+-------+------------------------------+-----------+
	+----------+-----------+------------------------------+-----------+		| PW | 0x0 | PW Control Word | RFC 4385 |
	| DetNet | 0x1 | DetNet Associated Channel | RFC 9546 |		+----------+-------+------------------------------+-----------+
	+----------+-----------+------------------------------+-----------+		| DetNet | 0x1 | DetNet Associated Channel | RFC 9546 |
	| MPLS | 0x1 | MPLS G-ACh | RFC 5586 |		+----------+-------+------------------------------+-----------+
	+----------+-----------+------------------------------+-----------+		| MPLS | 0x1 | MPLS Generic Associated | RFC 5586 |
	| PW | 0x1 | PW Associated Channel | RFC 4385 |		| | | Channel | |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
	| NSH | 0x2 | NSH Base Header, OAM | RFC 8300 |		| PW | 0x1 | PW Associated Channel | RFC 4385 |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
	| | 0x3 | Unassigned | |		| NSH | 0x2 | NSH Base Header, OAM | RFC 8300 |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
	| | 0x4 | Reserved, not to be assigned | |		| | 0x3 | Unassigned | |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
	| BIER | 0x5 | BIER Header | RFC 8296 |		| | 0x4 | Reserved, not to be assigned | |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
	| | 0x6 | Reserved, not to be assigned | |		| BIER | 0x5 | BIER Header | RFC 8296 |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
	| | 0x7 - 0xF | Unassigned | |		| | 0x6 | Reserved, not to be assigned | |
	+----------+-----------+------------------------------+-----------+		+----------+-------+------------------------------+-----------+
			| | 0x7 - | Unassigned | |
			| | 0xF | | |
			+----------+-------+------------------------------+-----------+
	Table 1: Post-stack First Nibble Values		Table 1: Post-stack First Nibble Values
	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 and specifies changes
	to the treatment in the data plane of packets based on the first		to the treatment in the data plane of packets based on the first
	nibble of data beyond the MPLS label stack. One intent of this is to		nibble of data beyond the MPLS label stack. One intent of this is to
	reduce or eliminate errors in determining whether a packet being		reduce or eliminate errors in determining whether a packet being
	transported by MPLS is IP or not. While such errors have primarily		transported by MPLS is IP or not. While such errors have primarily
	skipping to change at page 14, line 18 ¶		skipping to change at page 16, line 5 ¶
	2021, <https://www.rfc-editor.org/info/rfc8964>.		2021, <https://www.rfc-editor.org/info/rfc8964>.
	[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>.
	6.2. Informative References		6.2. Informative References
			[I-D.ietf-mpls-mna-fwk]
			Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
			Network Actions (MNA) Framework", Work in Progress,
			Internet-Draft, draft-ietf-mpls-mna-fwk-09, 19 June 2024,
			<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
			mna-fwk-09>.
	[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>.
	[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private		[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
	LAN Service (VPLS) Using Label Distribution Protocol (LDP)		LAN Service (VPLS) Using Label Distribution Protocol (LDP)
	Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,		Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
	<https://www.rfc-editor.org/info/rfc4762>.		<https://www.rfc-editor.org/info/rfc4762>.
			[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
			"MPLS Generic Associated Channel", RFC 5586,
			DOI 10.17487/RFC5586, June 2009,
			<https://www.rfc-editor.org/info/rfc5586>.
			[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
			and Retiring Special-Purpose MPLS Labels", RFC 7274,
			DOI 10.17487/RFC7274, June 2014,
			<https://www.rfc-editor.org/info/rfc7274>.
	[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,		[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
	Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based		Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
	Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February		Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
	2015, <https://www.rfc-editor.org/info/rfc7432>.		2015, <https://www.rfc-editor.org/info/rfc7432>.
	Authors' Addresses		Authors' Addresses
	Kireeti Kompella		Kireeti Kompella
	Juniper Networks		Juniper Networks
	1133 Innovation Way		1133 Innovation Way
End of changes. 45 change blocks.
	149 lines changed or deleted		191 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/