rfc9790.original.xml   rfc9790.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-mpls-1stnibble-13" category="std" ipr="trust200902" obsoletes="" updat <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
es="4928" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version raft-ietf-mpls-1stnibble-13" number="9790" consensus="true" category="std" ipr="
="3"> trust200902" obsoletes="" updates="4928" xml:lang="en" symRefs="true" sortRefs="
<!-- xml2rfc v2v3 conversion 3.16.0 --> true" tocInclude="true" version="3">
<!-- Generated by id2xml 1.5.0 on 2023-03-09T15:36:48Z -->
<front> <front>
<title abbrev="1st nibble">IANA Registry and Processing Recommendations for <title abbrev="First Nibble Following Label Stack">IANA Registry and Process
the First Nibble Following a Label Stack</title> ing Recommendations
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-1stnibble-13"/> for the First Nibble Following a Label Stack</title>
<seriesInfo name="RFC" value="9790"/>
<author initials="K." surname="Kompella" fullname="Kireeti Kompella"> <author initials="K." surname="Kompella" fullname="Kireeti Kompella">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<street>Sunnyvale, 94089</street> <city>Sunnyvale</city> <region>CA</region> <code>94089</code>
<street>United States of America</street> <country>United States of America</country>
</postal> </postal>
<email>kireeti.ietf@gmail.com</email> <email>kireeti.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant"> <author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization>University of Surrey 5GIC</organization> <organization>University of Surrey 5GIC</organization>
<address> <address>
<email>sb@stewartbryant.com</email> <email>sb@stewartbryant.com</email>
</address> </address>
</author> </author>
skipping to change at line 49 skipping to change at line 51
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author initials="L." surname="Andersson" fullname="Loa Andersson"> <author initials="L." surname="Andersson" fullname="Loa Andersson">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>loa@pi.nu</email> <email>loa@pi.nu</email>
</address> </address>
</author> </author>
<author initials="J." surname="Dong" fullname="Jie Dong"> <author initials="J." surname="Dong" fullname="Jie Dong">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<street>Beijing, 100095</street> <city>Beijing</city> <code>100095</code>
<street>China</street> <country>China</country>
</postal> </postal>
<email>jie.dong@huawei.com</email> <email>jie.dong@huawei.com</email>
</address> </address>
</author> </author>
<date year="2024"/> <date year="2025" month="July"/>
<workgroup>MPLS Working Group</workgroup> <area>RTG</area>
<workgroup>mpls</workgroup>
<abstract> <abstract>
<t> <t>
This document creates a new IANA registry (called the This document creates a new IANA registry (called the
Post-stack First Nibble registry) for the first nibble (4-bit field) "Post-Stack First Nibble" registry) for the first nibble (4-bit field)
immediately following an MPLS label stack. Furthermore, this document immediately following an MPLS label stack. Furthermore, this document
sets out some documentation requirements for registering new values, presents some requirements for registering new values
and requirements that make processing MPLS and making the processing of MPLS
packets easier and more robust. packets easier and more robust.
</t> </t>
<t>The relationship between the IANA IP Version Numbers (RFC 2780) <t>The relationship between the IANA "Post-Stack First Nibble" registry and the
and the Post-stack First Nibble registry is described in this document.</t> "IP Version Numbers" registry (RFC 2780)
is described in this document.</t>
<t>This document updates RFC 4928 by deprecating <t>This document updates RFC 4928 by deprecating
the heuristic method for identifying the type of packet encapsulated the heuristic method for identifying the type of packet encapsulated
in MPLS.</t> in MPLS.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>
An MPLS packet consists of a label stack, an optional "post-stack header" (PS <t>
H) and an optional embedded packet (in that order). Examples of An MPLS packet consists of a label stack, an optional Post-Stack Header (PSH),
PSH include existing artifacts such as Control Words <xref target="RFC4385"/> and an optional embedded packet (in that order). Examples of PSHs include exist
, BIER (Bit-Indexed Explicit Replication) headers <xref target="RFC8296"/> ing headers such as control words <xref target="RFC4385"/>, BIER (Bit Index Expl
and the like, as well as new types of PSH being discussed by the MPLS icit Replication) headers <xref target="RFC8296"/> and the like, as well as new
Working Group. However, in the data plane, there are types of PSH being discussed by the MPLS Working Group.
very few clues regarding the PSH, and no clue as to the type of embedded However, in the data plane, there are
very few clues regarding the PSH and no clue as to the type of embedded
packet; this information is communicated via other means, such as the packet; this information is communicated via other means, such as the
routing protocols that signal the labels in the stack. Nonetheless, routing protocols that signal the labels in the stack. Nonetheless,
in order to better handle an MPLS packet in the data plane, it is in order to better handle an MPLS packet in the data plane, it is
common practice for network equipment to "guess" the type of embedded common practice for network equipment to "guess" the type of embedded
packet. Such equipment may also need to process the PSH. packet. Such equipment may also need to process the PSH.
Both of these require parsing the data after the label Both of these require parsing the data after the label
stack. To do this, the "first nibble" (the top four bits of the stack. To do this, the "first nibble" (the top four bits of the
first octet following the label stack) is often used. Although some first octet following the label stack) is often used.
existing network devices may use such a method, it needs to be Although some existing network
stressed that the correct interpretation of the Post-stack First Nibble devices may use such a method, it needs to be stressed that the
(PFN) in a PSH can be made only in the context associated correct interpretation of the Post-stack First Nibble (PFN) in a PSH
using the control or management plane with the Label Stack Element (LSE) or can be made only in the context established through the control or
group management plane with the Label Stack Entry (LSE) or group of LSEs
of LSEs in the preceding label stack that characterize the type of in the preceding label stack that characterizes the type of the PSH.
the PSH, and that any attempt to rely on the value in any other Any attempt to rely on the value in any other context is
context is unreliable. Because the PFN value unreliable.
should not be used to deduce the type of PSH by itself, and the space of PFN Because the PFN value
values is limited, should not be used to deduce the type of PSH by itself and the space of PFN
the re-use of PFN values, where that is possible, is encouraged.</t> values is limited,
the reuse of PFN values is encouraged when possible.</t>
<t> <t>
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 purposes:</t> nor are the assignments of values. This document serves four purposes:</t>
<ul spacing="normal">
<ul spacing="normal">
<li>To document the values already in use.</li> <li>To document the values already in use.</li>
<li>To provide a mechanism to document future assignments <li>To provide a mechanism to document future assignments through the
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 describe the relationship between it and the IANA "IP Version Numbers" r
between it and the IANA IP Version Numbers <xref target="RFC2780"/>.</li> egistry
<xref target="RFC2780"/>.</li>
<li>Provide a method for tracking usage by requiring more detailed <li>Provide a method for tracking usage by requiring more detailed
documentation.</li> documentation.</li>
<li>To stress the importance that any MPLS packet not carrying <li>To stress that any MPLS packet not carrying plain
plain IPv4 or IPv6 packets contains a PSH, including any new version of IP IPv4 or IPv6 packets contains a PSH. This also applies to packets of
(<xref target="sect-2.3"/>).</li> any new version of IP
(see <xref target="sect-2.3"/>).</li>
</ul> </ul>
<t> <t>
Based on the analysis of load-balancing techniques in <xref target="sect-2.1. <xref target="sect-2.1.1"/> of this document includes an analysis of load-bal
1"/>, ancing techniques; based on this,
this document, in <xref target="sect-2.1.1.1"/>, introduces a requirement tha <xref target="sect-2.1.1.1"/> introduces a requirement that deprecates the
t deprecates the use of the use of the heuristic method for identifying the type
heuristic and recommends using a dedicated label value for load balancing. Th of packet encapsulated in MPLS and recommends using a dedicated label value f
e intent of both is for or load balancing. The intent is for
legacy routers to continue operating as they have, with no new problems legacy routers to continue operating as they have, with no new problems
introduced as a result of this document. However, new implementations introduced as a result of this document. However, new implementations
that follow this document enable a more robust network operation. that follow this document enable more robust network operation.
</t> </t>
<t>Furthermore, this document updates <xref target="RFC4928"/> <t>Furthermore, this document updates <xref target="RFC4928"/>
by deprecating the heuristic method for identifying the type of packet by deprecating the heuristic method for identifying the type of packet
encapsulated in MPLS. This document clearly states that the type of encapsulated in MPLS. This document clearly states that the type of
encapsulated packet cannot be determined based on the PFN alone.</t> encapsulated packet cannot be determined based on the PFN alone.</t>
<section anchor="sect-1.1" numbered="true" toc="default"> <section anchor="req-lang" numbered="true" toc="default">
<name>Conventions and Definitions</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="definitions" numbered="true" toc="default">
<name>Definitions</name>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>MPLS packet:</dt> <dt>Deprecation:</dt>
<dd> <dd>Regardless of how the deprecation is understood in other IETF
<t> documents, the interpretation in this document is that if a practice
one whose Layer 2 header declares the type to be MPLS. has been deprecated, that practice should not be included in new
For example, for Ethernet the Ethertype is 0x8847 or 0x8848, and for PPP the implementations or deployed in new deployments.</dd>
Protocol field is 0x0281 or 0x0283. <dt>Embedded Packet:</dt>
</t> <dd>A packet that follows immediately after the MPLS label
</dd> stack and an optional PSH. The embedded packet could be an IPv4 or IP
v6 packet, an
Ethernet packet (for Virtual Private LAN Service (VPLS) <xref target="
RFC4761"
format="default"/> <xref target="RFC4762" format="default"/> or
EVPN <xref target="RFC7432" format="default"/>), or some other type
of Layer 2 frame <xref target="RFC4446" format="default"/>. </dd>
<dt>Label Stack:</dt> <dt>Label Stack:</dt>
<dd> <dd>A label stack is represented as a consecutive sequence of "label s
<t> tack entries" (four-octet fields) after the Layer 2 header but before any networ
(of an MPLS packet) all labels (four-octet fields) k layer header. The last label stack entry of a label stack has its Bottom of St
after the Layer 2 header, up to and including the label with the ack bit set.
Bottom of Stack bit set (<xref target="RFC3032" format="default"/>). </dd>
</t>
</dd> <dt>MPLS Packet:</dt>
<dt>Post-stack First Nibble (PFN):</dt> <dd>A packet whose Layer 2 header declares the type to be MPLS. For
<dd> example, the Ethertype is 0x8847 or 0x8848 for Ethernet, and
<t> the Protocol field is 0x0281 or 0x0283 for PPP.</dd>
the most significant four bits of the first
octet following the label stack.
</t>
</dd>
<dt>MPLS Payload:</dt> <dt>MPLS Payload:</dt>
<dd> <dd>All data after the label stack and any optional PSHs. It
<t> is possible that more than one type of PSH may be present in a
all data after the label stack, including the PFN, an packet, and some PSH specifications might allow multiple PSHs of
optional post-stack header, and the embedded packet. the same type. The presence rules for multiple PSHs are a matter
</t> for the documents that define those PSHs, e.g.,
</dd> <xref target="I-D.ietf-mpls-mna-ps-hdr" format="default"/>.</dd>
<dt>Post-stack Header (PSH):</dt>
<dd> <dt>Post-stack First Nibble (PFN):</dt>
<t> <dd>The most significant four bits of the first octet following the
optional field of interest to the egress Label Switching Router (LSR) (and p label stack.</dd>
ossibly to transit LSRs). Examples include a control
word <xref target="RFC4385"/>, <xref target="RFC8964"/> or an associated c <dt>Post-Stack Header (PSH):</dt>
hannel <xref target="RFC4385"/>, <dd>A field containing information that may be
<xref target="RFC5586"/>, <xref target="RFC9546"/>. The PSH MUST indicate of interest to the egress Label Switching Router (LSR) or transit
its length, LSRs. Examples include a control word
so that a parser knows where the embedded packet starts. <xref target="RFC4385"/> <xref target="RFC8964"/> or an
</t> associated channel header <xref target="RFC4385"/> <xref
</dd> target="RFC5586"/> <xref target="RFC9546"/>.
<dt>Embedded Packet:</dt> </dd>
<dd>
<t>
an embedded packet follows immediately after the MPLS
Label Stack and an optional PSH. That could be
an IPv4 or IPv6 packet, an Ethernet packet (for
VPLS (<xref target="RFC4761" format="default"/>, <xref target="RFC4762" fo
rmat="default"/>)
or EVPN <xref target="RFC7432" format="default"/>), or some other type
of Layer 2 frame <xref target="RFC4446" format="default"/>.
</t>
</dd>
<dt>Deprecation:</dt>
<dd>
<t>
regardless of how the deprecation is understood in other IETF document
s,
the interpretation in this document is that if a practice has been dep
recated,
that practice should not be included in new implementations or deploye
d in new deployments.
</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="abbrev-sec" numbered="true" toc="default"> <section anchor="abbrev-sec" numbered="true" toc="default">
<name>Abbreviations</name> <name>Abbreviations</name>
<t>LSR: Label Switching Router</t>
<t>LSE: Label Stack Element</t> <dl spacing="normal" newline="false" indent="7">
<t>PSH: Post-Stack Header</t> <dt>BIER:</dt><dd>Bit Index Explicit Replication</dd>
<t>PFN: Post-stack First Nibble</t> <dt>FAT:</dt><dd>Flow-Aware Transport</dd>
<t>FAT: Flow-Aware Transport</t> <dt>LSE:</dt><dd>Label Stack Entry</dd>
<t>SPL: Special Purpose Label</t> <dt>LSR:</dt><dd>Label Switching Router</dd>
<t>PW: Pseudowire</t> <dt>MNA:</dt><dd>MPLS Network Action</dd>
<t>MNA: MPLS Network Action</t> <dt>PFN:</dt><dd>Post-stack First Nibble</dd>
<t>BIER: Bit-Indexed Explicit Replication</t> <dt>PSH:</dt><dd>Post-Stack Header</dd>
<dt>PW:</dt><dd>Pseudowire</dd>
<dt>SPL:</dt><dd>Special-Purpose Label</dd>
</dl>
</section> </section>
<section anchor="sect-figs" numbered="true" toc="default"> <section anchor="sect-figs" numbered="true" toc="default">
<name>Reference Figures</name> <name>Reference Figures</name>
<t><xref target="mpls-packet-fig"/> echoes the format of MPLS packets as defined in <t><xref target="mpls-packet-fig"/> echoes the format of MPLS packets as defined in
<xref target="RFC3032"/> where TC indicates the Traffic Class field < xref target="RFC5462"/> <xref target="RFC3032"/> where TC indicates the Traffic Class field < xref target="RFC5462"/>
that replaced the EXP (Experimental Use) field, S is the Bottom-of-St ack flag, and TTL that replaced the EXP (Experimental Use) field, S is the Bottom of St ack flag, and TTL
is the Time to Live field.</t> is the Time to Live field.</t>
<figure anchor="mpls-packet-fig"> <figure anchor="mpls-packet-fig">
<name>Example of an MPLS Packet With Label Stack</name> <name>Example of an MPLS Packet with Label Stack</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="examples-fig"> <figure anchor="examples-fig">
<name>Examples of an MPLS Packet Payload With and Without Post-Stack Hea der</name> <name>Examples of an MPLS Packet Payload With and Without a Preceding Po st&nbhy;Stack Header</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
A | (PFN) | IP header | | A | (PFN) | IP header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | | | data | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end of IP packet | | | end of IP packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
skipping to change at line 280 skipping to change at line 282
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end of PSH | | | end of PSH | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| embedded packet | | | embedded packet | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
<xref target="mpls-packet-fig"/> shows an MPLS packet with Layer 2 header X a <xref target="mpls-packet-fig"/> shows an MPLS packet with a Layer 2 he
nd a label stack ader X and a label stack
Y ending with Label-n. Then, there are three examples of an MPLS Y ending with Label-n. <xref target="examples-fig"/> displays three examples
payload displayed in <xref target="examples-fig"/>. of an MPLS
The complete MPLS packet thus would consist of [X Y A], or [X Y B], or [X Y C payload:</t>
].</t>
<t> <dl spacing="normal" newline="false">
A. The first payload is a bare IP packet, i.e., no PSH. The PFN in this cas <dt>Example A:</dt><dd>The first payload is a bare IP packet, i.e., no PSH.
e overlaps with the IP version number.</t> The
<t> PFN in this case overlaps with the IP version number.</dd>
B. The next payload is a bare non-IP packet; again, no PSH. The PFN <dt>Example B:</dt><dd>The next payload is a bare non-IP packet; again, no
here is the first nibble of the payload, whatever it happens to be.</t> PSH.
<t> The PFN here is the first nibble of the payload, whatever it happens to
C. The last example is an MPLS Payload that starts with a PSH be.</dd>
followed by the embedded packet. Here, the embedded packet could be <dt>Example C: </dt><dd>This example is an MPLS Payload that follows a PSH.
IP or non-IP.</t> Here, the embedded packet could be IP or non-IP.
</dd>
</dl>
<t>Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or [X
Y C].</t>
</section> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>Rationale</name> <name>Rationale</name>
<section anchor="sect-2.1" numbered="true" toc="default"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>Why Look at the First Nibble</name> <name>Why Look at the First Nibble</name>
<t> <t>
An MPLS packet can contain one of many types of embedded packets. Three commo n types are:</t> An MPLS packet can contain one of many types of embedded packets. Three commo n types are:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>An IPv4 packet (whose IP header has version number 4).</li> <li>An IPv4 packet (whose IP header has version number 4).</li>
<li>An IPv6 packet (whose IP header has version number 6).</li> <li>An IPv6 packet (whose IP header has version number 6).</li>
<li>A Layer 2 Ethernet frame (i.e., not including the Preamble or the <li>A Layer 2 Ethernet frame (i.e., not including the Preamble or the
Start frame delimiter), starting with the destination MAC address.</li> Start frame delimiter), starting with the destination Media Access Contro l (MAC) address.</li>
</ol> </ol>
<t> <t>
Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible. Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible.
Indeed, at some points in time, packets of Point-to-Point Protocol, Frame Relay Indeed, at some points in time, packets of the Point-to-Point Protocol, Frame R
, elay,
and Asynchronous Transfer Mode protocols were reasonably common, and may become and Asynchronous Transfer Mode were reasonably common and may become so again.
so again.
</t> </t>
<t> <t>
In addition, there may be a PSH ahead of the embedded packet. 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 parsed . The value of PFN is considered to ensure that the PSH can be correctly parsed .
</t> </t>
<section anchor="sect-2.1.1" numbered="true" toc="default"> <section anchor="sect-2.1.1" numbered="true" toc="default">
<name>ECMP Load Balancing</name> <name>ECMP Load Balancing</name>
<t> <t>
There are four common ways to load balance an MPLS packet:</t> There are four common ways to load balance an MPLS packet:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>One can use the top label alone.</li> <li>Use the top label alone.</li>
<li>One can do better by using all of the non-SPLs (Special Purpose <li>Use all of the non-SPLs <xref target="RFC7274"/> in the stack. T
Labels) <xref target="RFC7274"/> in the stack.</li> his is better than using the
<li>One can do even better by "divining" the type of embedded packet top label alone.</li>
, <li>"Divine" the type of embedded packet
and using fields from the guessed header. The ramifications of using this and use fields from the guessed header. The ramifications of using this l
load-balancing technique oad-balancing technique
are discussed in detail in <xref target="sect-2.1.1.1"/>.</li> are discussed in detail in <xref target="sect-2.1.1.1"/>. This way is bet
<li>One can do best by using either an Entropy Label <xref target="R ter than the two ways above.</li>
FC6790" format="default"/> or a <li>Use either an Entropy Label <xref target="RFC6790" format="defau
Flow-Aware Transport (FAT) Pseudowire Label <xref target="RFC6391" format lt"/> or a
="default"/> (see <xref target="sect-2.1.1.1" format="default"/>).</li> Flow-Aware Transport (FAT) Pseudowire Label <xref target="RFC6391" format
="default"/> (see <xref target="sect-2.1.1.1" format="default"/>). This is the b
est way.</li>
</ol> </ol>
<t> <t>
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 packet is better, but it may still be uneven. However, if the embedded packet
is an IP packet, then the combination of (&lt;source IP address&gt;, &lt;dest IP address&gt;, &lt;transport protocol&gt;, &lt;source port&gt;, and &lt;dest p ort&gt;) is an IP packet, then the combination of (&lt;source IP address&gt;, &lt;dest IP address&gt;, &lt;transport protocol&gt;, &lt;source port&gt;, and &lt;dest p ort&gt;)
from the IP header of the embedded packet forms an excellent basis from the IP header of the embedded packet forms an excellent basis
for load-balancing. This is what is typically used for load for load balancing. This is what is typically used for load balancing IP pac
balancing IP packets.</t> kets.</t>
<t> <t>
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 header, i.e
four most significant bits of the first octet, of an IP header ., the
four most significant bits of the first octet,
contains the IP version number. That, in turn, indicates where to find contains the IP version number. That, in turn, indicates where to find
the relevant fields for load-balancing. The heuristic goes roughly the relevant fields for load balancing. The heuristic goes roughly
as described in <xref target="sect-2.1.1.1"/>.</t> as described in <xref target="sect-2.1.1.1"/>.</t>
<section anchor="sect-2.1.1.1" numbered="true" toc="default"> <section anchor="sect-2.1.1.1" numbered="true" toc="default">
<name>Heuristic for ECMP Load Balancing</name> <name>Heuristic for ECMP Load Balancing</name>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet , <li>If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet ,
and find the relevant fields for load-balancing on that basis.</li> and find the relevant fields for load balancing on that basis.</li>
<li>If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet , <li>If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet ,
and find the relevant fields for load-balancing on that basis.</li> and find the relevant fields for load balancing on that basis.</li>
<li>If the PFN is anything else, the MPLS payload is not an IP <li>If the PFN is anything else, the MPLS payload is not an IP
packet; fall back to load-balancing using the label stack.</li> packet; fall back to load balancing using the label stack.</li>
</ol> </ol>
<t> <t>
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 <xref target="examples-fig"/>, A. However, this performs well in the case of example A in <xref target="examples-fig"/>. How
heuristic ever, this heuristic
can work very badly for non-IP packet as shown in <xref target="examples-fig" can work very badly for the non-IP packet as shown in example B in <xref targ
/>, B. For example, if payload B is an et="examples-fig"/>. For example, if payload B is an
Ethernet frame, then the PFN is the first nibble of the Organizationally Uniq ue Identifier of the Ethernet frame, then the PFN is the first nibble of the Organizationally Uniq ue Identifier of the
destination MAC address, which can be 0x4 or 0x6, and if so would lead to the packet being treated as an IPv4 or IPv6 packet such destination MAC address, which can be 0x4 or 0x6. This would lead to the pack et being treated as an IPv4 or IPv6 packet such
that data at the offsets of specific relevant fields would be used as that data at the offsets of specific relevant fields would be used as
input to the load-balancing heuristic resulting in unpredictable load input to the load-balancing heuristic, resulting in unpredictable load
balancing. This behavior can happen to other balancing. This behavior can happen to other
types of non-IP payloads as well.</t> types of non-IP payloads as well.</t>
<t> <t>
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 <xref target="RFC4385" format="default"/>, a DetNet control word control word <xref target="RFC4385" format="default"/>, a Deterministic Netwo
<xref target="RFC8964" format="default"/>, rking (DetNet) control word <xref target="RFC8964" format="default"/>,
a Network Service Header <xref target="RFC8300"/>, or a BIER a Network Service Header (NSH) <xref target="RFC8300"/>, or a BIER
header <xref target="RFC8296" format="default"/>) where the PFN is not 0x4 or header <xref target="RFC8296" format="default"/>) where the PFN is not 0x4 or
0x6, to 0x6; this
explicitly prevent forwarding engines from confusing the MPLS payload explicitly prevents forwarding engines from confusing the MPLS payload
with an IP packet. <xref target="RFC8469" format="default"/> recommends the use of a control word with an IP packet. <xref target="RFC8469" format="default"/> recommends the use of a control word
when the embedded packet is an Ethernet frame. RFC 8469 was when the embedded packet is an Ethernet frame. <xref target="RFC8469" format ="default"/> was
published at the request of the operator community and the IEEE Registration Authority Committee published at the request of the operator community and the IEEE Registration Authority Committee
as a result of operational difficulties with pseudowires that did not as a result of operational difficulties with pseudowires that did not
contain the control word.</t> contain the control word.</t>
<t> <t>
It is RECOMMENDED that where load-balancing of MPLS Where load balancing of MPLS
packets is desired, the load-balancing mechanism uses the value of a dedicate packets is desired, it is <bcp14>RECOMMENDED</bcp14> that the load-balancing
d label, for example, mechanism use the value of a dedicated label, for example,
either an Entropy Label <xref target="RFC6790"/> or a FAT Pseudowire Label <x ref target="RFC6391"/>. either an Entropy Label <xref target="RFC6790"/> or a FAT Pseudowire Label <x ref target="RFC6391"/>.
Furthermore, the heuristic of guessing the type of the embedded packet, Furthermore, the heuristic of guessing the type of the embedded packet,
as discussed above, SHOULD NOT be used.</t> as discussed above, <bcp14>SHOULD NOT</bcp14> be used.</t>
<t> <t>
A consequence of the heuristic approach is that while legacy routers may A consequence of the heuristic approach is that while legacy routers may
look for a PFN of 0x4 <xref target="RFC0791"/> or 0x6 <xref target="RFC8200"/ >, no legacy router will look for a PFN of 0x4 <xref target="RFC0791"/> or 0x6 <xref target="RFC8200"/ >, no legacy router will
look for any other PFN, regardless of what future IP version numbers look for any other PFN for load-balancing purposes, regardless of what futur
will be, for load-balancing purposes. This means that the values 0x4 and e IP version numbers
will be. This means that the values 0x4 and
0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6 0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6
packets, but no other of PFN values will be used to identify IP packets, but no other PFN values will be used to identify IP
packets.</t> packets.</t>
<t>This document creates a new PFN Registry for all 16 possible values.</t> <t>This document creates a new registry for all 16 possible values (see <xref target="sect-3"/>).</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-2.1.2" numbered="true" toc="default"> <section anchor="sect-2.1.2" numbered="true" toc="default">
<name>Updates of RFC 4928</name> <name>Updates to RFC 4928</name>
<t>The text in RFC 4928 <xref target="RFC4928"/> concerning the first
nibble after the MPLS label stack has been updated by this document,
and the heuristic for snooping this nibble has been deprecated. <xref s
ection="3" sectionFormat="of" target="RFC4928"/> is updated as follows:</t>
<t> <t>OLD TEXT:</t>
The text in RFC 4928 <xref target="RFC4928"/> concerning the first nibble a
fter the MPLS
Label Stack has been updated by this document and
the heuristic for snooping this nibble has been deprecated.
RFC 4928 is now updated as follows:</t>
<t>OLD TEXT</t>
<blockquote> <blockquote>
<t> <t>It is <bcp14>REQUIRED</bcp14>, however, that applications
It is REQUIRED, however, that applications dependent upon in-order depend upon in-order packet delivery restrict the first nibble
packet delivery restrict the first nibble values to 0x0 and 0x1. values to 0x0 and 0x1. This will ensure that their traffic flows
This will ensure that their traffic flows will not be affected if will not be affected if some future routing equipment does similar
some future routing equipment does similar snooping on some future snooping on some future version(s) of IP.</t>
version(s) of IP.
</t>
</blockquote> </blockquote>
<t>NEW TEXT:</t> <t>NEW TEXT:</t>
<blockquote> <blockquote>
<t> <t>Network equipment <bcp14>MUST</bcp14> use a PSH (Post-Stack Header)
Network equipment MUST use a PSH with a PFN (Post-stack First Nibble) value that is neither 0x4 nor 0x6
(Post-Stack Header) with a PFN (Post-stack First Nibble) value in all cases where the MPLS payload is neither an IPv6 nor an IPv4
that is neither 0x4 nor 0x6 in all cases when the MPLS packet.</t>
payload is neither an IPv6 nor an IPv4 packet.
</t>
</blockquote> </blockquote>
<!-- <t>[RFC Ed.: Throughout the docuemnt, replace XXXX with the actual RFC num <t>The following requirement (discussed is <xref target="sect-2.1.1.1"/>) replac
ber assigned to this document and remove this note.]</t> --> es
paragraph 4 in <xref section="3" sectionFormat="of" target="RFC4928"
format="default"/> as follows:</t>
<t>
The requirement (see <xref target="sect-2.1.1.1"/>) replaces the paragraph 4
in Section 3 of RFC 4928 <xref target="RFC4928" format="default"/> as follows:</
t>
<t>OLD TEXT:</t> <t>OLD TEXT:</t>
<blockquote> <blockquote>
<t> <t>This behavior implies that if in the future an IP version is defined
This behavior implies that if in the future an IP version is defined with a v with a version number of 0x0 or 0x1, then equipment complying with this
ersion number of 0x0 or 0x1, BCP would be unable to look past one or more MPLS headers, and
then equipment complying with this BCP would be unable to look past one or mo loadsplit traffic from a single LSP across multiple paths based on a
re MPLS headers, hash of specific fields in the IPv0 or IPv1 headers. That is, IP
and load-split traffic from a single LSP across multiple paths based on a has traffic employing these version numbers would be safe from disturbances
h of specific fields in the IPv0 or IPv1 headers. caused by inappropriate loadsplitting, but would also not be able to
That is, IP traffic employing these version numbers would be safe from distur get the performance benefits.</t>
bances caused by inappropriate load-splitting,
but would also not be able to get the performance benefits.</t>
</blockquote> </blockquote>
<t>NEW TEXT:</t> <t>NEW TEXT:</t>
<blockquote> <blockquote>
<t> <t>The practice of deducing the payload type based on the PFN value is
The practice of deducing the payload type based on the PFN value deprecated to avoid inaccurate load balancing. This <bcp14>MUST
is deprecated to avoid inaccurate load balancing. This NOT</bcp14> be part of new implementations or deployments. This also means
MUST NOT be part of new implementations or that concerns about load balancing for future IP versions with a version
deployments. It also means that concerns about number of 0x0 or 0x1 are no longer relevant.</t>
load balancing for future IP versions with a version number of 0x0 </blockquote>
or 0x1 are no longer relevant.
</t>
</blockquote>
<t>END</t>
<t>Furthermore, the following text is appended to Section 1.1 of RFC 4928 <xr ef target="RFC4928"/>:</t> <t>Furthermore, the following text is appended to <xref section="1.1" section Format="of" target="RFC4928"/>:</t>
<t>NEW TEXT:</t> <t>NEW TEXT:</t>
<blockquote> <blockquote>
<t>PSH: Post-Stack Header</t> <dl spacing="normal" newline="false">
<t>PFN: Post-stack First Nibble</t> <dt>PSH:</dt><dd>Post-Stack Header</dd>
<dt>PFN:</dt><dd>Post-stack First Nibble</dd>
</dl>
</blockquote> </blockquote>
<t>END</t>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default"> <section anchor="sect-2.2" numbered="true" toc="default">
<name>Why Create a Registry</name> <name>Why Create a Registry</name>
<t> <t>
Support for MPLS Network Actions (MNAs) is described in The framework for MPLS Network Actions (MNAs) is described in
<xref target="I-D.ietf-mpls-mna-fwk"/> and is an enhancement to the MPLS <xref target="RFC9789"/> and is an enhancement to the MPLS
architecture. The use of post-stack data (PSD) to encode the MNA architecture. The use of Post-Stack Data (PSD) to encode the MNA
indicators and ancillary data is described in section 3.6 might place indicators and ancillary data (described in <xref section="3.6" sectionFormat
data in the PFN that could conflict with other uses of that nibble. ="of" target="RFC9789"/>) might place
This issue is described in section 3.6.1 of <xref target="I-D.ietf-mpls-mna-f data in the PFN, which could conflict with other uses of that nibble.
wk"/> This issue is described in <xref section="3.6.1" sectionFormat="of" target="R
and is further illustrated by the PFN value of 0x0 which has two FC9789"/>
and is further illustrated by the PFN value of 0x0, which has two
different formats depending on whether the PSH is a pseudowire different formats depending on whether the PSH is a pseudowire
control word or a DetNet control word: disambiguation requires the control word or a DetNet control word; disambiguation requires the
context of the service label. context of the service label.
</t> </t>
<t> <t>
With a registry, PSHs become easier to identify and parse; not needing any m With a registry, PSHs become easier to identify and parse. In addition, they
eans do not need a 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 and referenced from the registry. semantics and usage are documented and referenced in the registry.
</t> </t>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default"> <section anchor="sect-2.3" numbered="true" toc="default">
<name>IP Version Numbers versus Post-stack First Nibble Values</name> <name>IP Version Numbers Versus Post-Stack First Nibble Values</name>
<t> <t>
The use of the PFN stemmed from the desire to The use of the PFN stemmed from the desire to
heuristically identify IP packets for load-balancing purposes. It heuristically identify IP packets for load-balancing purposes. It
was then discovered that non-IP packets, misidentified as IP when the was then discovered that non-IP packets, misidentified as IP when the
heuristic failed, were being badly load balanced, leading to heuristic failed, were being badly load balanced, leading to the scenario des cribed in
<xref target="RFC4928" format="default"/>. This situation may confuse some a s to the relationship <xref target="RFC4928" format="default"/>. This situation may confuse some a s to the relationship
between the Post-stack First Nibble Registry and the IP Version Numbers between the "Post-Stack First Nibble" registry and the "IP Version Numbers"
registry. These registries are quite different:</t> registry. These registries are quite different:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The IP Version Numbers registry's explicit purpose is to track IP <li>The explicit purpose of the "IP Version Numbers" registry is to trac k IP
version numbers in an IP header.</li> version numbers in an IP header.</li>
<li>The Post-stack First Nibble registry's purpose is to track PSH typ es.</li> <li>The purpose of the "Post-Stack First Nibble" registry is to track PSH types.</li>
</ol> </ol>
<t> <t>
The only intersection points between the two registries is for values The only intersection points between the two registries are the values
0x4 and 0x6 (for backward compatibility). 0x4 and 0x6 (for backward compatibility).
</t> </t>
</section> </section>
<section anchor="sect-2.5" numbered="true" toc="default"> <section anchor="sect-2.5" numbered="true" toc="default">
<name>Next Step to More Deterministic Load-balancing in MPLS Networks</n ame> <name>Next Step to More Deterministic Load Balancing in MPLS Networks</n ame>
<t>Network evolution is impossible to control, but it develops over a period of time determined by various factors.</t> <t>Network evolution is impossible to control, but it develops over a period of time determined by various factors.</t>
<t>This document discourages further proliferation of the implementations that c <t>This document discourages further proliferation of the implementations that c
ould lead to undesired effects affecting data flows. ould lead to undesired effects on data flows.
In doing so, it limits the scope of future protocol developments, and so helps t In doing so, it limits the scope of future protocol developments and thus helps
o ensure that future network evolution will be smoother.</t> to ensure that future network evolution will be smoother.</t>
<t>It would assist with the progress toward a simpler, more coherent system of M <t><xref target="RFC4385" sectionFormat="of" section="2" /> suggests the use of
PLS data encapsulation if the use a PSH for a PSH solely for the purpose
non-IP payloads encapsulated in MPLS was obsoleted. However, before that can be of avoiding IP ECMP treatment of non-IP payloads encapsulated in MPLS.
done, it is important to collect sufficient Obsoleting this use of a PSH would assist with the progress toward a
evidence that there are no marketed or deployed implementations using the heuris simpler, more coherent system of MPLS data encapsulation. (Other uses
tic practice to load-balancing MPLS data flows.</t> of a PSH may still be valid.) However, before that can 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.</t>
<t>The next step, therefore, toward more deterministic load-balancing in MPLS ne <t>Therefore, the next steps toward more deterministic load balancing in MPLS ne
tworks is to gradulally deprecate non-PSH MPLS encapsulations tworks are to gradually deprecate non-PSH MPLS encapsulations
of non-IP data, to cease using heuristic load-balancing, and to survey the avail of non-IP data, to cease using heuristic load balancing, and to survey the avail
able and deployed implementations to determine when obsoletion able and deployed implementations to determine when obsoletion
may be achieved.</t> may be achieved.</t>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default"> <section anchor="sect-3" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="sect-3.1" numbered="true" toc="default">
<name>The Post-stack First Nibble Registry</name>
<t> <t>
This document requests IANA to create a registry group called "Post-Stack Fir Per this document, IANA has created a registry group called "Post-Stack First
st Nibble Registry" Nibble"
that consists of a single registry called "Post-Stack First Nibble Registry". that consists of a single registry called the "Post-Stack First Nibble" regis
The registry should be created as shown in <xref target="iana-pfn-value-tbl"/ try.
>. The initial contents of the registry are shown in <xref target="iana-pfn-valu
The assignment policy for the registry is Standards Action <xref target="RFC8 e-tbl"/>.
126"/>. It is important to note, that The assignment policy is Standards Action <xref target="RFC8126"/>. It is imp
ortant to note that
the same PFN value can be used in more than one protocol. The correct interpr etation of the PFN in a PSH the same PFN value can be used in more than one protocol. The correct interpr etation of the PFN in a PSH
can be made only in the context of the LSE or a group of LSEs in the precedin can be made only in the context of the LSE or group of LSEs in the preceding
g label stack that characterize the type label stack that characterizes the type
of the PSH and, consequently, PFN. of the PSH and, consequently, the PFN.
</t> </t>
<table anchor="iana-pfn-value-tbl" align="center"> <table anchor="iana-pfn-value-tbl" align="center">
<name>Post-stack First Nibble Values</name> <name>Post-Stack First Nibble Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Protocol</th> <th align="left">Protocol</th>
<th align="left">Value</th> <th align="left">Value</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">DetNet</td> <td align="left">DetNet</td>
<td align="left">0x0</td> <td align="left">0x0</td>
<td align="center">DetNet Control Word</td> <td align="left">DetNet Control Word</td>
<td align="left">RFC 8964</td> <td align="left"><xref target="RFC8964"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">NSH</td> <td align="left">NSH</td>
<td align="left">0x0</td> <td align="left">0x0</td>
<td align="center">NSH (Network Service Header) Base Header, paylo <td align="left">NSH Base Header, payload</td>
ad</td> <td align="left"><xref target="RFC8300"/></td>
<td align="left">RFC 8300</td>
</tr> </tr>
<tr> <tr>
<td align="left">PW</td> <td align="left">PW</td>
<td align="left">0x0</td> <td align="left">0x0</td>
<td align="center">PW Control Word</td> <td align="left">PW Control Word</td>
<td align="left">RFC 4385</td> <td align="left"><xref target="RFC4385"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">DetNet</td> <td align="left">DetNet</td>
<td align="left">0x1</td> <td align="left">0x1</td>
<td align="center">DetNet Associated Channel</td> <td align="left">DetNet Associated Channel</td>
<td align="left">RFC 9546</td> <td align="left"><xref target="RFC9546"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">MPLS</td> <td align="left">MPLS</td>
<td align="left">0x1</td> <td align="left">0x1</td>
<td align="center">MPLS Generic Associated Channel</td> <td align="left">MPLS Generic Associated Channel</td>
<td align="left">RFC 5586</td> <td align="left"><xref target="RFC5586"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">PW</td> <td align="left">PW</td>
<td align="left">0x1</td> <td align="left">0x1</td>
<td align="center">PW Associated Channel</td> <td align="left">PW Associated Channel</td>
<td align="left">RFC 4385</td> <td align="left"><xref target="RFC4385"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">NSH</td> <td align="left">NSH</td>
<td align="left">0x2</td> <td align="left">0x2</td>
<td align="center">NSH Base Header, OAM</td> <td align="left">NSH Base Header, OAM</td>
<td align="left">RFC 8300</td> <td align="left"><xref target="RFC8300"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x3</td> <td align="left">0x3</td>
<td align="center">Unassigned</td> <td align="left">Unassigned</td>
<td align="left"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x4</td> <td align="left">0x4</td>
<td align="center">Reserved, not to be assigned</td> <td align="left">Reserved</td>
<td align="left"/> <td align="left">this document</td>
</tr> </tr>
<tr> <tr>
<td align="left">BIER</td> <td align="left">BIER</td>
<td align="left">0x5</td> <td align="left">0x5</td>
<td align="center">BIER Header</td> <td align="left">BIER Header</td>
<td align="left">RFC 8296</td> <td align="left"><xref target="RFC8296"/></td>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x6</td> <td align="left">0x6</td>
<td align="center">Reserved, not to be assigned</td> <td align="left">Reserved</td>
<td align="left"/> <td align="left">this document</td>
</tr> </tr>
<tr> <tr>
<td align="left"/> <td align="left"/>
<td align="left">0x7 - 0xF</td> <td align="left">0x7 - 0xF</td>
<td align="center">Unassigned</td> <td align="left">Unassigned</td>
<td align="left"/> <td align="left"/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section>
</section> </section>
<section anchor="sec-sect" numbered="true" toc="default"> <section anchor="sec-sect" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
This document creates a new IANA registry for and specifies changes to the treat This document creates a new IANA registry for PFNs and specifies changes to the
ment in the data plane treatment of packets in the data plane
of packets based on the first nibble of data beyond the MPLS label stack. One in based on the first nibble of data beyond the MPLS label stack. One intent of th
tent of this is to reduce is is to reduce
or eliminate errors in determining whether a packet being transported by MPLS is or eliminate errors in determining whether or not a packet being transported by
IP or not. MPLS is IP.
While such errors have primarily caused unbalanced and, thus, inefficient multi- While such errors have primarily caused unbalanced, and thus inefficient, multip
pathing, athing,
they have the potential to cause more severe security problems. they have the potential to cause more severe security problems.
</t> </t>
<t> <t>
For general MPLS label stack security considerations, see <xref target="RFC 3032"/>. For general security considerations involving the MPLS label stack, see <xr ef target="RFC3032"/>.
</t> </t>
</section> </section>
<section anchor="Ack-sec" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The authors express their appreciation and gratitude to Donald E. Eastl
ake 3rd for the review, insightful questions, and helpful comments.
Also, the authors are gateful to Amanda Baber for helping organize the IAN
A registry in clear and consise manner.</t>
<t>Eric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and Gunter
Van de Velde provided helpful comments during IESG review.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-mpls-mna-ps-hdr" to="MNA-PS-HDR"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.2119.xml"/> 119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8174.xml"/> 174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
FC.3032.xml"/> 032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4385.xml"/> 385.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8200.xml"/> 200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4928.xml"/> 928.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6790.xml"/> 790.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8469.xml"/> 469.xml"/>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/referen <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ce.RFC.8300.xml"/> --> 296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8296.xml"/> 964.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.8964.xml"/> 391.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
FC.6391.xml"/> 791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.27
FC.0791.xml"/> 80.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2780. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
xml"/> 62.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.
xml"/> <!-- draft-ietf-mpls-mna-fwk-15 - companion doc RFC 9789 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-mp <reference anchor="RFC9789" target="https://www.rfc-editor.org/info/rfc9789">
ls-mna-fwk.xml"/> <front>
<title>MPLS Network Actions (MNAs) Framework</title>
<author initials="L." surname="Andersson" fullname="Loa Andersson">
<organization>Huawei Technologies</organization>
</author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization>University of Surrey 5GIC</organization>
</author>
<author initials="M." surname="Bocci" fullname="Matthew Bocci">
<organization>Nokia</organization>
</author>
<author initials="T." surname="Li" fullname="Tony Li">
<organization>Juniper Networks</organization>
</author>
<date month="July" year="2025" />
</front>
<seriesInfo name="RFC" value="9789"/>
<seriesInfo name="DOI" value="10.17487/RFC9789"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refere <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
nce.RFC.4364.xml"/> --> 761.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.4761.xml"/> 432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.7432.xml"/> 446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4446.xml"/> 762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.4762.xml"/> 586.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.5586.xml"/> 274.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
FC.7274.xml"/> 00.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml"/>
<!-- ietf-mpls-mna-ps-hdr.xml I-D Exists as of 2025-07-02 -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300. <reference anchor="I-D.ietf-mpls-mna-ps-hdr" target="https://datatracker.ietf.or
xml"/> g/doc/html/draft-ietf-mpls-mna-ps-hdr-01">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9546. <front>
xml"/> <title>Post-Stack MPLS Network Action (MNA) Solution</title>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126. <author fullname="Jaganbabu Rajamanickam" initials="J." surname="Rajamanickam" r
xml"/> ole="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Rakesh Gandhi" initials="R." surname="Gandhi" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Royi Zigler" initials="R." surname="Zigler">
<organization>Broadcom</organization>
</author>
<author fullname="Tony Li" initials="T." surname="Li">
<organization>Juniper Networks</organization>
</author>
<author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization>
</author>
<date day="30" month="May" year="2025"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-mna-ps-hdr-01"/>
</reference>
</references> </references>
</references> </references>
<section anchor="Ack-sec" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors express their appreciation and gratitude to <contact
fullname="Donald E. Eastlake 3rd"/> for the review, insightful
questions, and helpful comments. Also, the authors are grateful to
<contact fullname="Amanda Baber"/> for helping organize the IANA
registry in a clear and concise manner.</t>
<t><contact fullname="Éric Vyncke"/>, <contact fullname="John
Scudder"/>, <contact fullname="Warren Kumari"/>, <contact
fullname="Murray Kucherawy"/>, and <contact fullname="Gunter Van de
Velde"/> provided helpful comments during IESG review.</t>
<t>The authors would also like to thank <contact fullname="Adrian Farrel"/
> for his patient and careful shepherding and for helping to
finalize the text.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 104 change blocks. 
409 lines changed or deleted 459 lines changed or added

This html diff was produced by rfcdiff 1.48.