IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack
draft-ietf-mpls-1stnibble-13

MPLS Working Group                                           K. Kompella
Internet-Draft                                          Juniper Networks
Updates: 4928 (if approved)                                    S. Bryant
Intended status: Standards Track               University of Surrey 5GIC
Expires: 8 June 2025                                            M. Bocci
                                                                   Nokia
                                                          G. Mirsky, Ed.
                                                                Ericsson
                                                            L. Andersson
                                                                 J. Dong
                                                     Huawei Technologies
                                                         5 December 2024

   IANA Registry and Processing Recommendations for the First Nibble
                        Following a Label Stack
                      draft-ietf-mpls-1stnibble-13

Abstract

   This document creates a new IANA registry (called the Post-stack
   First Nibble registry) for the first nibble (4-bit field) immediately
   following an MPLS label stack.  Furthermore, this document sets out
   some documentation requirements for registering new values, and
   requirements that make processing MPLS packets easier and more
   robust.

   The relationship between the IANA IP Version Numbers (RFC 2780) and
   the Post-stack First Nibble registry is described in this document.

   This document updates RFC 4928 by deprecating the heuristic method
   for identifying the type of packet encapsulated in MPLS.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Kompella, et al.           Expires 8 June 2025                  [Page 1]
Internet-Draft                 1st nibble                  December 2024

   This Internet-Draft will expire on 8 June 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   4
     1.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Reference Figures . . . . . . . . . . . . . . . . . . . .   5
   2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Why Look at the First Nibble  . . . . . . . . . . . . . .   7
       2.1.1.  ECMP Load Balancing . . . . . . . . . . . . . . . . .   7
     2.2.  Updates of RFC 4928 . . . . . . . . . . . . . . . . . . .   9
     2.3.  Why Create a Registry . . . . . . . . . . . . . . . . . .  10
     2.4.  IP Version Numbers versus Post-stack First Nibble
           Values  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     2.5.  Next Step to More Deterministic Load-balancing in MPLS
           Networks  . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     3.1.  The Post-stack First Nibble Registry  . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   An MPLS packet consists of a label stack, an optional "post-stack
   header" (PSH) and an optional embedded packet (in that order).
   Examples of PSH include existing artifacts such as Control Words
   [RFC4385], BIER (Bit-Indexed Explicit Replication) headers [RFC8296]
   and the like, as well as new types of PSH being discussed by the MPLS
   Working Group.  However, in the data plane, there are very few clues

Kompella, et al.           Expires 8 June 2025                  [Page 2]
Internet-Draft                 1st nibble                  December 2024

   regarding the PSH, and no clue as to the type of embedded packet;
   this information is communicated via other means, such as the routing
   protocols that signal the labels in the stack.  Nonetheless, 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
   packet.  Such equipment may also need to process the PSH.  Both of
   these require parsing the data after the label stack.  To do this,
   the "first nibble" (the top four bits of the first octet following
   the label stack) is often used.  Although some existing network
   devices may use such a method, it needs to be stressed that the
   correct interpretation of the Post-stack First Nibble (PFN) in a PSH
   can be made only in the context associated using the control or
   management plane with the Label Stack Element (LSE) or group of LSEs
   in the preceding label stack that characterize the type of the PSH,
   and that any attempt to rely on the value in any other context is
   unreliable.  Because the PFN value should not be used to deduce the
   type of PSH by itself, and the space of PFN values is limited, the
   re-use of PFN values, where that is possible, is encouraged.

   The semantics and usage of the first nibble are not well documented,
   nor are the assignments of values.  This document serves four
   purposes:

   *  To document the values already in use.

   *  To provide a mechanism to document future assignments through the
      creation of a new IANA "Post-stack First Nibble registry", and
      document the relationship between it and the IANA IP Version
      Numbers [RFC2780].

   *  Provide a method for tracking usage by requiring more detailed
      documentation.

   *  To stress the importance that any MPLS packet not carrying plain
      IPv4 or IPv6 packets contains a PSH, including any new version of
      IP (Section 2.4).

   Based on the analysis of load-balancing techniques in Section 2.1.1,
   this document, in Section 2.1.1.1, introduces a requirement that
   deprecates the use of the heuristic and recommends using a dedicated
   label value for load balancing.  The intent of both is for legacy
   routers to continue operating as they have, with no new problems
   introduced as a result of this document.  However, new
   implementations that follow this document enable a more robust
   network operation.

Kompella, et al.           Expires 8 June 2025                  [Page 3]
Internet-Draft                 1st nibble                  December 2024

   Furthermore, this document updates [RFC4928] by deprecating the
   heuristic method for identifying the type of packet encapsulated in
   MPLS.  This document clearly states that the type of encapsulated
   packet cannot be determined based on the PFN alone.

1.1.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   MPLS packet:  one whose Layer 2 header declares the type to be MPLS.
      For example, for Ethernet the Ethertype is 0x8847 or 0x8848, and
      for PPP the Protocol field is 0x0281 or 0x0283.

   Label Stack:  (of an MPLS packet) all labels (four-octet fields)
      after the Layer 2 header, up to and including the label with the
      Bottom of Stack bit set ([RFC3032]).

   Post-stack First Nibble (PFN):  the most significant four bits of the
      first octet following the label stack.

   MPLS Payload:  all data after the label stack, including the PFN, an
      optional post-stack header, and the embedded packet.

   Post-stack Header (PSH):  optional field of interest to the egress
      Label Switching Router (LSR) (and possibly to transit LSRs).
      Examples include a control word [RFC4385], [RFC8964] or an
      associated channel [RFC4385], [RFC5586], [RFC9546].  The PSH MUST
      indicate its length, so that a parser knows where the embedded
      packet starts.

   Embedded Packet:  an embedded packet follows immediately after the
      MPLS Label Stack and an optional PSH.  That could be an IPv4 or
      IPv6 packet, an Ethernet packet (for VPLS ([RFC4761], [RFC4762])
      or EVPN [RFC7432]), or some other type of Layer 2 frame [RFC4446].

   Deprecation:  regardless of how the deprecation is understood in
      other IETF documents, the interpretation in this document is that
      if a practice has been deprecated, that practice should not be
      included in new implementations or deployed in new deployments.

1.2.  Abbreviations

   LSR: Label Switching Router

Kompella, et al.           Expires 8 June 2025                  [Page 4]
Internet-Draft                 1st nibble                  December 2024

   LSE: Label Stack Element

   PSH: Post-Stack Header

   PFN: Post-stack First Nibble

   FAT: Flow-Aware Transport

   SPL: Special Purpose Label

   PW: Pseudowire

   MNA: MPLS Network Action

   BIER: Bit-Indexed Explicit Replication

1.3.  Reference Figures

   Figure 1 echoes the format of MPLS packets as defined in [RFC3032]
   where TC indicates the Traffic Class field [RFC5462] that replaced
   the EXP (Experimental Use) field, S is the Bottom-of-Stack flag, and
   TTL is the Time to Live field.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   X |                        Layer 2 Header                         | |
     |                                                               | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
                                               TC   S       TTL
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   Y |             Label-1                   | TC  |0|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Label-2                   | TC  |0|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               ...                     | TC  |0|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Label-n                   | TC  |1|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

            Figure 1: Example of an MPLS Packet With Label Stack

Kompella, et al.           Expires 8 June 2025                  [Page 5]
Internet-Draft                 1st nibble                  December 2024

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   A | (PFN) |                   IP header                           | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             data                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        end of IP packet                       | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   B | (PFN) |                 non-IP packet                         | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             data                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      end of non-IP packet                     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   C | (PFN) |                      PSH                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              PSH                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          end of PSH                           | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        embedded packet                        | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

       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
   Y ending with Label-n.  Then, there are three examples of an MPLS
   payload displayed in Figure 2.  The complete MPLS packet thus would
   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
   this case overlaps with the IP version number.

   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.

Kompella, et al.           Expires 8 June 2025                  [Page 6]
Internet-Draft                 1st nibble                  December 2024

   C.  The last example is an MPLS Payload that starts with a PSH
   followed by the embedded packet.  Here, the embedded packet could be
   IP or non-IP.

2.  Rationale

2.1.  Why Look at the First Nibble

   An MPLS packet can contain one of many types of embedded packets.
   Three common types are:

   1.  An IPv4 packet (whose IP header has version number 4).

   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
       Start frame delimiter), starting with the destination MAC
       address.

   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, and Asynchronous
   Transfer Mode protocols were reasonably common, and may become so
   again.

   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.

2.1.1.  ECMP Load Balancing

   There are four common ways to load balance an MPLS packet:

   1.  One can use the top label alone.

   2.  One can do better by using all of the non-SPLs (Special Purpose
       Labels) [RFC7274] in the stack.

   3.  One can do even better by "divining" the type of embedded packet,
       and using fields from the guessed header.  The ramifications of
       using this load-balancing technique are discussed in detail in
       Section 2.1.1.1.

   4.  One can do best by using either an Entropy Label [RFC6790] or a
       Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see
       Section 2.1.1.1).

Kompella, et al.           Expires 8 June 2025                  [Page 7]
Internet-Draft                 1st nibble                  December 2024

   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.
   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 an IP packet, then the combination of (<source IP address>,
   <dest IP address>, <transport protocol>, <source port>, and <dest
   port>) from the IP header of the embedded packet forms an excellent
   basis for load-balancing.  This is what is typically used for load
   balancing IP packets.

   An MPLS packet doesn't, however, carry a payload type identifier.
   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
   four most significant bits of the first octet, of an IP header
   contains the IP version number.  That, in turn, indicates where to
   find the relevant fields for load-balancing.  The heuristic goes
   roughly as described in Section 2.1.1.1.

2.1.1.1.  Heuristic for ECMP Load Balancing

   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.

   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.

   3.  If the PFN is anything else, the MPLS payload is not an IP
       packet; fall back to load-balancing using the label stack.

   This heuristic has been implemented in many (legacy) routers, and
   performs well in the case of Figure 2, A.  However, this heuristic
   can work very badly for non-IP packet as shown in Figure 2, B.  For
   example, if payload B is an Ethernet frame, then the PFN is the first
   nibble of the Organizationally Unique 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 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.

Kompella, et al.           Expires 8 June 2025                  [Page 8]
Internet-Draft                 1st nibble                  December 2024

   That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire
   control word [RFC4385], a DetNet control word [RFC8964], a Network
   Service Header [RFC8300], or a BIER header [RFC8296]) where the PFN
   is not 0x4 or 0x6, to explicitly prevent forwarding engines from
   confusing the MPLS payload with an IP packet.  [RFC8469] recommends
   the use of a control word when the embedded packet is an Ethernet
   frame.  RFC 8469 was 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 contain the
   control word.

   It is RECOMMENDED that where load-balancing of MPLS packets is
   desired, the load-balancing mechanism uses the value of a dedicated
   label, for example, either an Entropy Label [RFC6790] or a FAT
   Pseudowire Label [RFC6391].  Furthermore, the heuristic of guessing
   the type of the embedded packet, as discussed above, SHOULD NOT be
   used.

   A consequence of the heuristic approach is that while legacy routers
   may look for a PFN of 0x4 [RFC0791] or 0x6 [RFC8200], no legacy
   router will look for any other PFN, regardless of what future IP
   version numbers will be, for load-balancing purposes.  This means
   that the values 0x4 and 0x6 are used to (sometimes incorrectly)
   identify IPv4 and IPv6 packets, but no other of PFN values will be
   used to identify IP packets.

   This document creates a new PFN Registry for all 16 possible values.

2.2.  Updates of RFC 4928

   The text in RFC 4928 [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.  RFC 4928 is now
   updated as follows:

   OLD TEXT

   |  It is REQUIRED, however, that applications dependent upon in-order
   |  packet delivery restrict the first nibble values to 0x0 and 0x1.
   |  This will ensure that their traffic flows will not be affected if
   |  some future routing equipment does similar snooping on some future
   |  version(s) of IP.

   NEW TEXT:

   |  Network equipment MUST use a PSH (Post-Stack Header) with a PFN
   |  (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all
   |  cases when the MPLS payload is neither an IPv6 nor an IPv4 packet.

Kompella, et al.           Expires 8 June 2025                  [Page 9]
Internet-Draft                 1st nibble                  December 2024

   The requirement (see Section 2.1.1.1) replaces the paragraph 4 in
   Section 3 of RFC 4928 [RFC4928] as follows:

   OLD TEXT:

   |  This behavior implies that if in the future an IP version is
   |  defined with a version number of 0x0 or 0x1, then equipment
   |  complying with this BCP would be unable to look past one or more
   |  MPLS headers, and load-split traffic from a single LSP across
   |  multiple paths based on a hash of specific fields in the IPv0 or
   |  IPv1 headers.  That is, IP traffic employing these version numbers
   |  would be safe from disturbances caused by inappropriate load-
   |  splitting, but would also not be able to get the performance
   |  benefits.

   NEW TEXT:

   |  The practice of deducing the payload type based on the PFN value
   |  is deprecated to avoid inaccurate load balancing.  This MUST NOT
   |  be part of new implementations or deployments.  It also means that
   |  concerns about load balancing for future IP versions with a
   |  version number of 0x0 or 0x1 are no longer relevant.

   END

   Furthermore, the following text is appended to Section 1.1 of RFC
   4928 [RFC4928]:

   NEW TEXT:

   |  PSH: Post-Stack Header
   |  
   |  PFN: Post-stack First Nibble

   END

2.3.  Why Create a Registry

   Support for MPLS Network Actions (MNAs) is described in
   [I-D.ietf-mpls-mna-fwk] and is an enhancement to the MPLS
   architecture.  The use of post-stack data (PSD) to encode the MNA
   indicators and ancillary data is described in section 3.6 might place
   data in the PFN that could conflict with other uses of that nibble.
   This issue is described in section 3.6.1 of [I-D.ietf-mpls-mna-fwk]
   and is further illustrated by the PFN value of 0x0 which has two
   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.

Kompella, et al.           Expires 8 June 2025                 [Page 10]
Internet-Draft                 1st nibble                  December 2024

   With a registry, PSHs become easier to identify and parse; not
   needing any means outside the data plane to interpret them correctly;
   and their semantics and usage are documented and referenced from the
   registry.

2.4.  IP Version Numbers versus Post-stack First Nibble Values

   The use of the PFN stemmed from the desire to heuristically identify
   IP packets for load-balancing purposes.  It was then discovered that
   non-IP packets, misidentified as IP when the heuristic failed, were
   being badly load balanced, leading to [RFC4928].  This situation may
   confuse some as to the relationship between the Post-stack First
   Nibble Registry and the IP Version Numbers registry.  These
   registries are quite different:

   1.  The IP Version Numbers registry's explicit purpose is to track IP
       version numbers in an IP header.

   2.  The Post-stack First Nibble registry's purpose is to track PSH
       types.

   The only intersection points between the two registries is for values
   0x4 and 0x6 (for backward compatibility).

2.5.  Next Step to More Deterministic Load-balancing in MPLS Networks

   Network evolution is impossible to control, but it develops over a
   period of time determined by various factors.

   This document discourages further proliferation of the
   implementations that could lead to undesired effects affecting data
   flows.  In doing so, it limits the scope of future protocol
   developments, and so helps to ensure that future network evolution
   will be smoother.

   It would assist with the progress toward a simpler, more coherent
   system of MPLS data encapsulation if the use a PSH for non-IP
   payloads encapsulated in MPLS was obsoleted.  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-balancing MPLS data flows.

   The next step, therefore, toward more deterministic load-balancing in
   MPLS networks is to gradulally deprecate non-PSH MPLS encapsulations
   of non-IP data, to cease using heuristic load-balancing, and to
   survey the available and deployed implementations to determine when
   obsoletion may be achieved.

Kompella, et al.           Expires 8 June 2025                 [Page 11]
Internet-Draft                 1st nibble                  December 2024

3.  IANA Considerations

3.1.  The Post-stack First Nibble Registry

   This document requests IANA to create a registry group called "Post-
   Stack First Nibble Registry" that consists of a single registry
   called "Post-Stack First Nibble Registry".  The registry should be
   created as shown in Table 1.  The assignment policy for the registry
   is Standards Action [RFC8126].  It is important to note, that the
   same PFN value 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 group of LSEs in the preceding label stack that
   characterize the type of the PSH and, consequently, PFN.

      +==========+=======+==============================+===========+
      | Protocol | Value |         Description          | Reference |
      +==========+=======+==============================+===========+
      | DetNet   | 0x0   |     DetNet Control Word      | RFC 8964  |
      +----------+-------+------------------------------+-----------+
      | NSH      | 0x0   | NSH (Network Service Header) | RFC 8300  |
      |          |       |     Base Header, payload     |           |
      +----------+-------+------------------------------+-----------+
      | PW       | 0x0   |       PW Control Word        | RFC 4385  |
      +----------+-------+------------------------------+-----------+
      | DetNet   | 0x1   |  DetNet Associated Channel   | RFC 9546  |
      +----------+-------+------------------------------+-----------+
      | MPLS     | 0x1   |   MPLS Generic Associated    | RFC 5586  |
      |          |       |           Channel            |           |
      +----------+-------+------------------------------+-----------+
      | PW       | 0x1   |    PW Associated Channel     | RFC 4385  |
      +----------+-------+------------------------------+-----------+
      | NSH      | 0x2   |     NSH Base Header, OAM     | RFC 8300  |
      +----------+-------+------------------------------+-----------+
      |          | 0x3   |          Unassigned          |           |
      +----------+-------+------------------------------+-----------+
      |          | 0x4   | Reserved, not to be assigned |           |
      +----------+-------+------------------------------+-----------+
      | BIER     | 0x5   |         BIER Header          | RFC 8296  |
      +----------+-------+------------------------------+-----------+
      |          | 0x6   | Reserved, not to be assigned |           |
      +----------+-------+------------------------------+-----------+
      |          | 0x7 - |          Unassigned          |           |
      |          | 0xF   |                              |           |
      +----------+-------+------------------------------+-----------+

                  Table 1: Post-stack First Nibble Values

Kompella, et al.           Expires 8 June 2025                 [Page 12]
Internet-Draft                 1st nibble                  December 2024

4.  Security Considerations

   This document creates a new IANA registry for and specifies changes
   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
   reduce or eliminate errors in determining whether a packet being
   transported by MPLS is IP or not.  While such errors have primarily
   caused unbalanced and, thus, inefficient multi-pathing, they have the
   potential to cause more severe security problems.

   For general MPLS label stack security considerations, see [RFC3032].

5.  Acknowledgements

   The authors express their appreciation and gratitude to Donald E.
   Eastlake 3rd for the review, insightful questions, and helpful
   comments.  Also, the authors are gateful to Amanda Baber for helping
   organize the IANA registry in clear and consise manner.

   Eric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and
   Gunter Van de Velde provided helpful comments during IESG review.

6.  References

6.1.  Normative 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-14, 2 December
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              mpls-mna-fwk-14>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
              Values In the Internet Protocol and Related Headers",
              BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
              <https://www.rfc-editor.org/info/rfc2780>.

Kompella, et al.           Expires 8 June 2025                 [Page 13]
Internet-Draft                 1st nibble                  December 2024

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
              February 2006, <https://www.rfc-editor.org/info/rfc4385>.

   [RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
              Cost Multipath Treatment in MPLS Networks", BCP 128,
              RFC 4928, DOI 10.17487/RFC4928, June 2007,
              <https://www.rfc-editor.org/info/rfc4928>.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <https://www.rfc-editor.org/info/rfc5462>.

   [RFC6391]  Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
              Regan, J., and S. Amante, "Flow-Aware Transport of
              Pseudowires over an MPLS Packet Switched Network",
              RFC 6391, DOI 10.17487/RFC6391, November 2011,
              <https://www.rfc-editor.org/info/rfc6391>.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
              for Bit Index Explicit Replication (BIER) in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/info/rfc8296>.

Kompella, et al.           Expires 8 June 2025                 [Page 14]
Internet-Draft                 1st nibble                  December 2024

   [RFC8469]  Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to
              Use the Ethernet Control Word", RFC 8469,
              DOI 10.17487/RFC8469, November 2018,
              <https://www.rfc-editor.org/info/rfc8469>.

   [RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
              S., and J. Korhonen, "Deterministic Networking (DetNet)
              Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
              2021, <https://www.rfc-editor.org/info/rfc8964>.

6.2.  Informative References

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446,
              DOI 10.17487/RFC4446, April 2006,
              <https://www.rfc-editor.org/info/rfc4446>.

   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <https://www.rfc-editor.org/info/rfc4761>.

   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
              <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.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Kompella, et al.           Expires 8 June 2025                 [Page 15]
Internet-Draft                 1st nibble                  December 2024

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC9546]  Mirsky, G., Chen, M., and B. Varga, "Operations,
              Administration, and Maintenance (OAM) for Deterministic
              Networking (DetNet) with the MPLS Data Plane", RFC 9546,
              DOI 10.17487/RFC9546, February 2024,
              <https://www.rfc-editor.org/info/rfc9546>.

Authors' Addresses

   Kireeti Kompella
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, 94089
   United States of America
   Email: kireeti.ietf@gmail.com

   Stewart Bryant
   University of Surrey 5GIC
   Email: sb@stewartbryant.com

   Matthew Bocci
   Nokia
   Email: matthew.bocci@nokia.com

   Greg Mirsky (editor)
   Ericsson
   Email: gregimirsky@gmail.com

   Loa Andersson
   Huawei Technologies
   Email: loa@pi.nu

   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing, 100095
   China
   Email: jie.dong@huawei.com

Kompella, et al.           Expires 8 June 2025                 [Page 16]