doc: Add RFC documents

1 files changed, 348 insertions, 0 deletions

diff --git a/doc/rfc/rfc9436.txt b/doc/rfc/rfc9436.txt
new file mode 100644
index 0000000..674849a
--- /dev/null
+++ b/doc/rfc/rfc9436.txt
@@ -0,0 +1,348 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         S. Venaas
+Request for Comments: 9436                           Cisco Systems, Inc.
+Obsoletes: 8736                                                A. Retana
+Updates: 3973, 5015, 5059, 6754, 7761,      Futurewei Technologies, Inc.
+         8364                                                August 2023
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+           PIM Message Type Space Extension and Reserved Bits
+
+Abstract
+
+   The PIM version 2 messages share a common message header format.  The
+   common header definition contains eight reserved bits.  This document
+   specifies how these bits may be used by individual message types and
+   extends the PIM type space.
+
+   This document updates RFCs 7761 and 3973 by defining the use of the
+   Reserved field in the PIM common header.  This document further
+   updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and
+   8364, by specifying the use of the bits for each PIM message.
+
+   This document obsoletes RFC 8736.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9436.
+
+Copyright Notice
+
+   Copyright (c) 2023 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.  Conventions Used in This Document
+   3.  PIM Header Common Format
+   4.  Flag Bit Definitions
+     4.1.  Flag Bits for Type 4 (Bootstrap)
+     4.2.  Flag Bits for Type 10 (DF Election)
+     4.3.  Flag Bits for Type 12 (PIM Flooding Mechanism)
+     4.4.  Flag Bits for Types 13, 14, and 15 (Type Space Extension)
+   5.  PIM Type Space Extension
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Authors' Addresses
+
+1.  Introduction
+
+   The PIM version 2 messages share a common message header format
+   defined in the PIM Sparse Mode specification [RFC7761].  The common
+   header definition contains eight reserved bits.  While all message
+   types use this common header, there is no document formally
+   specifying that these bits are to be used per message type.
+
+   This document updates the definition of the Reserved field and refers
+   to it as the "Flag Bits field".  It specifies that the flag bits are
+   to be separately used on a per-message-type basis.  It updates the
+   "PIM Message Types" registry to indicate the per-message-type usage.
+
+   This document updates [RFC7761] and [RFC3973] by defining the use of
+   the Reserved field in the PIM common header.  This document further
+   updates [RFC7761] and [RFC3973], along with [RFC5015], [RFC5059],
+   [RFC6754], and [RFC8364], by specifying the use of the bits for each
+   PIM message.
+
+   The originally defined PIM message types were in the range from 0 to
+   15.  Message type 15 had been reserved by [RFC6166] for type space
+   extension.  In Section 5, this document specifies the use of the Flag
+   Bits field for message types 13, 14, and 15 in order to extend the
+   PIM type space.  The type space extension in [RFC6166] was made
+   obsolete by [RFC8736].  This document obsoletes [RFC8736].
+
+2.  Conventions Used in This Document
+
+   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.
+
+3.  PIM Header Common Format
+
+   The common PIM header is defined in Section 4.9 of [RFC7761].  This
+   document updates the definition of the Reserved field and refers to
+   it as the "Flag Bits field".  The updated common header format is as
+   below.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |PIM Ver| Type  |   Flag Bits   |           Checksum            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 1: Updated Common Header
+
+   The Flag Bits field is defined in Section 4.  All other fields remain
+   unchanged.
+
+4.  Flag Bit Definitions
+
+   Unless otherwise specified, all the flag bits for each PIM type are
+   Unassigned [RFC8126].  They MUST be set to zero on transmission, and
+   they MUST be ignored upon receipt.  The specification of a new PIM
+   type MUST indicate whether the bits should be treated differently.
+
+   When defining flag bits, it is helpful to have a well-defined way of
+   referring to a particular bit.  The most significant of the flag
+   bits, the bit immediately following the Type field, is referred to as
+   bit 7.  The least significant, the bit right in front of the Checksum
+   field, is referred to as bit 0.  This is shown in the diagram below.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |PIM Ver| Type  |7 6 5 4 3 2 1 0|           Checksum            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                            Figure 2: Flag Bits
+
+4.1.  Flag Bits for Type 4 (Bootstrap)
+
+   PIM message type 4 (Bootstrap) [RFC5059] defines flag bit 7 as No-
+   Forward.  The usage of the bit is defined in that document.  The
+   remaining flag bits are unassigned.
+
+4.2.  Flag Bits for Type 10 (DF Election)
+
+   PIM message type 10 (DF Election) [RFC5015] specifies that the four
+   most significant flag bits (bits 4-7) are to be used as a subtype.
+   The usage of those bits is defined in that document.  The remaining
+   flag bits are unassigned.
+
+4.3.  Flag Bits for Type 12 (PIM Flooding Mechanism)
+
+   PIM message type 12 (PIM Flooding Mechanism) [RFC8364] defines flag
+   bit 7 as No-Forward.  The usage of the bit is defined in that
+   document.  The remaining flag bits are unassigned.
+
+4.4.  Flag Bits for Types 13, 14, and 15 (Type Space Extension)
+
+   These types and the corresponding flag bits are defined in Section 5.
+
+5.  PIM Type Space Extension
+
+   This document extends types 13, 14, and 15 such that each becomes 16
+   new types, resulting in 48 types available for future PIM extensions.
+   This extension is achieved by defining a Subtype field (see Figure 3)
+   using the four most significant flag bits (bits 4-7).  The notation
+   type.subtype is used to reference the new extended types.  The
+   remaining four flag bits (bits 0-3, abbreviated as FB below) are to
+   be defined by each extended type.
+
+   Each of the extended types is represented by the eight bits resulting
+   from the concatenation of the Type and Subtype fields.  No
+   relationship is expected or implied between extended type messages
+   with a common Type 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |PIM Ver| Type  |Subtype|  FB   |           Checksum            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                             Figure 3: Subtypes
+
+6.  Security Considerations
+
+   This document clarifies the use of the flag bits in the common PIM
+   header, and it extends the PIM type space.  As such, there is no
+   impact on security or changes to the considerations in [RFC7761] and
+   [RFC3973].
+
+7.  IANA Considerations
+
+   This document updates the "PIM Message Types" registry to indicate
+   which flag bits are defined for use by each of the PIM message types
+   and changes their registration status to Unassigned except where the
+   bits have already been specified, as shown in Table 1.  The
+   registration policy remains IETF Review [RFC8126].  Assignments to
+   this registry MUST define any non-default usage (see Section 4) of
+   the flag bits in addition to the type.
+
+   Extended type 15.15 is Reserved [RFC8126] for future extensions.
+
+   Because this document obsoletes [RFC8736], IANA has changed the
+   references to [RFC8736] in the registry to point to this document
+   instead.
+
+   The updated "PIM Message Types" registry is shown below.
+
+       +============+===============+=================+===========+
+       | Type       | Name          | Flag Bits       | Reference |
+       +============+===============+=================+===========+
+       | 0          | Hello         | 0-7: Unassigned | [RFC3973] |
+       |            |               |                 | [RFC7761] |
+       +------------+---------------+-----------------+-----------+
+       | 1          | Register      | 0-7: Unassigned | [RFC7761] |
+       +------------+---------------+-----------------+-----------+
+       | 2          | Register Stop | 0-7: Unassigned | [RFC7761] |
+       +------------+---------------+-----------------+-----------+
+       | 3          | Join/Prune    | 0-7: Unassigned | [RFC3973] |
+       |            |               |                 | [RFC7761] |
+       +------------+---------------+-----------------+-----------+
+       | 4          | Bootstrap     | 0-6: Unassigned | [RFC5059] |
+       |            |               |                 | [RFC7761] |
+       |            |               +-----------------+-----------+
+       |            |               | 7: No-Forward   | [RFC5059] |
+       +------------+---------------+-----------------+-----------+
+       | 5          | Assert        | 0-7: Unassigned | [RFC3973] |
+       |            |               |                 | [RFC7761] |
+       +------------+---------------+-----------------+-----------+
+       | 6          | Graft         | 0-7: Unassigned | [RFC3973] |
+       +------------+---------------+-----------------+-----------+
+       | 7          | Graft-Ack     | 0-7: Unassigned | [RFC3973] |
+       +------------+---------------+-----------------+-----------+
+       | 8          | Candidate RP  | 0-7: Unassigned | [RFC7761] |
+       |            | Advertisement |                 |           |
+       +------------+---------------+-----------------+-----------+
+       | 9          | State Refresh | 0-7: Unassigned | [RFC3973] |
+       +------------+---------------+-----------------+-----------+
+       | 10         | DF Election   | 0-3: Unassigned | [RFC5015] |
+       |            |               +-----------------+-----------+
+       |            |               | 4-7: Subtype    | [RFC5015] |
+       +------------+---------------+-----------------+-----------+
+       | 11         | ECMP Redirect | 0-7: Unassigned | [RFC6754] |
+       +------------+---------------+-----------------+-----------+
+       | 12         | PIM Flooding  | 0-6: Unassigned | [RFC8364] |
+       |            | Mechanism     +-----------------+-----------+
+       |            |               | 7: No-Forward   | [RFC8364] |
+       +------------+---------------+-----------------+-----------+
+       | 13.0-15.14 | Unassigned    | 0-3: Unassigned |           |
+       +------------+---------------+-----------------+-----------+
+       | 15.15      | Reserved      | 0-3: Reserved   | RFC 9436  |
+       +------------+---------------+-----------------+-----------+
+
+               Table 1: Updated PIM Message Types Registry
+
+   The unassigned types above, as explained in Section 5, use the
+   extended type notation of type.subtype.  Each extended type only has
+   4 flag bits available.  New extended message types should be assigned
+   consecutively, starting with 13.0, then 13.1, etc.
+
+8.  References
+
+8.1.  Normative References
+
+   [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>.
+
+   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
+              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
+              Multicast - Sparse Mode (PIM-SM): Protocol Specification
+              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
+              2016, <https://www.rfc-editor.org/info/rfc7761>.
+
+   [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>.
+
+   [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>.
+
+8.2.  Informative References
+
+   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
+              Independent Multicast - Dense Mode (PIM-DM): Protocol
+              Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973,
+              January 2005, <https://www.rfc-editor.org/info/rfc3973>.
+
+   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
+              "Bidirectional Protocol Independent Multicast (BIDIR-
+              PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
+              <https://www.rfc-editor.org/info/rfc5015>.
+
+   [RFC5059]  Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
+              "Bootstrap Router (BSR) Mechanism for Protocol Independent
+              Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
+              2008, <https://www.rfc-editor.org/info/rfc5059>.
+
+   [RFC6166]  Venaas, S., "A Registry for PIM Message Types", RFC 6166,
+              DOI 10.17487/RFC6166, April 2011,
+              <https://www.rfc-editor.org/info/rfc6166>.
+
+   [RFC6754]  Cai, Y., Wei, L., Ou, H., Arya, V., and S. Jethwani,
+              "Protocol Independent Multicast Equal-Cost Multipath
+              (ECMP) Redirect", RFC 6754, DOI 10.17487/RFC6754, October
+              2012, <https://www.rfc-editor.org/info/rfc6754>.
+
+   [RFC8364]  Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM
+              Flooding Mechanism (PFM) and Source Discovery (SD)",
+              RFC 8364, DOI 10.17487/RFC8364, March 2018,
+              <https://www.rfc-editor.org/info/rfc8364>.
+
+   [RFC8736]  Venaas, S. and A. Retana, "PIM Message Type Space
+              Extension and Reserved Bits", RFC 8736,
+              DOI 10.17487/RFC8736, February 2020,
+              <https://www.rfc-editor.org/info/rfc8736>.
+
+Authors' Addresses
+
+   Stig Venaas
+   Cisco Systems, Inc.
+   Tasman Drive
+   San Jose, CA 95134
+   United States of America
+   Email: stig@cisco.com
+
+
+   Alvaro Retana
+   Futurewei Technologies, Inc.
+   2330 Central Expressway
+   Santa Clara, CA 95050
+   United States of America
+   Email: alvaro.retana@futurewei.com