doc: Add RFC documents

1 files changed, 333 insertions, 0 deletions

diff --git a/doc/rfc/rfc8736.txt b/doc/rfc/rfc8736.txt
new file mode 100644
index 0000000..0ea2897
--- /dev/null
+++ b/doc/rfc/rfc8736.txt
@@ -0,0 +1,333 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         S. Venaas
+Request for Comments: 8736                           Cisco Systems, Inc.
+Obsoletes: 6166                                                A. Retana
+Updates: 3973, 5015, 5059, 6754, 7761,      Futurewei Technologies, Inc.
+         8364                                              February 2020
+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
+   creates a registry containing the per-message-type usage.  This
+   document also extends the PIM type space by defining three new
+   message types.  For each of the new types, four of the previously
+   reserved bits are used to form an extended type range.
+
+   This document updates RFCs 7761 and 3973 by defining the use of the
+   currently 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 currently reserved bits for
+   each PIM message.
+
+   This document obsoletes RFC 6166.
+
+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/rfc8736.
+
+Copyright Notice
+
+   Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified 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 (PFM)
+     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 refers to the bits specified as "reserved" in the
+   common PIM header [RFC7761] as "PIM message type Flag Bits" or,
+   simply, "Flag Bits", and it specifies that they are to be separately
+   used on a per-message-type basis.  It creates a registry containing
+   the per-message-type usage.
+
+   This document updates [RFC7761] and [RFC3973] by defining the use of
+   the currently 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
+   currently reserved bits for each PIM message.
+
+   The currently defined PIM message types are in the range from 0 to
+   15.  That type space is almost exhausted.  Message type 15 was
+   reserved by [RFC6166] for type space extension.  In Section 5, this
+   document specifies the use of the Flag Bits for message types 13, 14,
+   and 15 in order to extend the PIM type space.  This document
+   obsoletes [RFC6166].
+
+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
+   that field as "PIM message type Flag Bits" or, simply, "Flag Bits".
+   The new 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: New 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
+   Reserved [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 reserved.
+
+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 reserved.
+
+4.3.  Flag Bits for Type 12 (PFM)
+
+   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 reserved.
+
+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 defines types 13, 14, and 15, such that each of these
+   types has 16 subtypes, providing a total of 48 subtypes available for
+   future PIM extensions.  This is achieved by defining a new Subtype
+   field (see Figure 3) using the four most significant flag bits (bits
+   4-7).  The notation type.subtype is used to reference these new
+   extended types.  The remaining four flag bits (bits 0-3) are reserved
+   to be used by each extended type (abbreviated as FB 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  |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.
+   The registry now references this document.  The registration policy
+   remains IETF Review [RFC8126].  Assignments into this registry MUST
+   define any non-default usage (see Section 4) of the flag bits in
+   addition to the type.
+
+   The updated "PIM Message Types" registry is shown below.
+
+    +------------+---------------+---------------+--------------------+
+    | Type       | Name          | Flag Bits     | Reference          |
+    +============+===============+===============+====================+
+    | 0          | Hello         | 0-7: Reserved | [RFC3973][RFC7761] |
+    +------------+---------------+---------------+--------------------+
+    | 1          | Register      | 0-7: Reserved | [RFC7761]          |
+    +------------+---------------+---------------+--------------------+
+    | 2          | Register Stop | 0-7: Reserved | [RFC7761]          |
+    +------------+---------------+---------------+--------------------+
+    | 3          | Join/Prune    | 0-7: Reserved | [RFC3973][RFC7761] |
+    +------------+---------------+---------------+--------------------+
+    | 4          | Bootstrap     | 0-6: Reserved | [RFC5059][RFC7761] |
+    |            |               +---------------+--------------------+
+    |            |               | 7: No-Forward | [RFC5059]          |
+    +------------+---------------+---------------+--------------------+
+    | 5          | Assert        | 0-7: Reserved | [RFC3973][RFC7761] |
+    +------------+---------------+---------------+--------------------+
+    | 6          | Graft         | 0-7: Reserved | [RFC3973]          |
+    +------------+---------------+---------------+--------------------+
+    | 7          | Graft-Ack     | 0-7: Reserved | [RFC3973]          |
+    +------------+---------------+---------------+--------------------+
+    | 8          | Candidate RP  | 0-7: Reserved | [RFC7761]          |
+    |            | Advertisement |               |                    |
+    +------------+---------------+---------------+--------------------+
+    | 9          | State Refresh | 0-7: Reserved | [RFC3973]          |
+    +------------+---------------+---------------+--------------------+
+    | 10         | DF Election   | 0-3: Reserved | [RFC5015]          |
+    |            |               +---------------+--------------------+
+    |            |               | 4-7: Subtype  | [RFC5015]          |
+    +------------+---------------+---------------+--------------------+
+    | 11         | ECMP Redirect | 0-7: Reserved | [RFC6754]          |
+    +------------+---------------+---------------+--------------------+
+    | 12         | PIM Flooding  | 0-6: Reserved | [RFC8364]          |
+    |            | Mechanism     +---------------+--------------------+
+    |            |               | 7: No-Forward | [RFC8364]          |
+    +------------+---------------+---------------+--------------------+
+    | 13.0-15.15 | Unassigned    | 0-3:          | RFC 8736           |
+    |            |               | Unassigned    |                    |
+    +------------+---------------+---------------+--------------------+
+
+                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>.
+
+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