diff options
Diffstat (limited to 'doc/rfc/rfc9436.txt')
| -rw-r--r-- | doc/rfc/rfc9436.txt | 348 |
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 |