[要約] RFC 9436 は、PIMメッセージタイプの拡張と予約ビットに関する規定を提供し、PIM共通ヘッダーの予約フィールドの使用方法を定義します。
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
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.
PIMバージョン2メッセージは、共通のメッセージヘッダー形式を共有します。一般的なヘッダー定義には、8つの予約済みビットが含まれています。このドキュメントは、これらのビットを個々のメッセージタイプで使用する方法を指定し、PIMタイプの空間を拡張します。
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.
このドキュメントは、PIM共通ヘッダーで予約済みフィールドの使用を定義することにより、RFCS 7761および3973を更新します。このドキュメントは、各PIMメッセージのビットの使用を指定することにより、RFCS 5015、5059、6754、および8364とともに、RFCS 7761および3973をさらに更新します。
This document obsoletes RFC 8736.
このドキュメントは、RFC 8736を廃止します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9436で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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
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.
PIMバージョン2メッセージは、PIMスパースモード仕様[RFC7761]で定義されている共通のメッセージヘッダー形式を共有します。一般的なヘッダー定義には、8つの予約済みビットが含まれています。すべてのメッセージタイプはこの共通ヘッダーを使用していますが、これらのビットをメッセージタイプごとに使用することを正式に指定するドキュメントはありません。
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.
このドキュメントは、予約済みフィールドの定義を更新し、「フラグビットフィールド」と呼んでいます。これは、フラグビットを、視覚ごとに個別に使用することを指定しています。「PIMメッセージタイプ」レジストリを更新して、視覚ごとの使用法を示します。
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.
このドキュメントは、PIM共通ヘッダーで予約済みフィールドの使用を定義することにより、[RFC7761]および[RFC3973]を更新します。この文書は、各PIMメッセージのBITの使用を指定することにより、[RFC7761]および[RFC3973]と[RFC5015]、[RFC5059]、[RFC6754]、および[RFC8364]とともにさらに更新します。
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].
当初定義されていたPIMメッセージタイプは0〜15の範囲でした。メッセージタイプ15は、型スペース拡張のために[RFC6166]によって予約されていました。セクション5では、このドキュメントでは、PIMタイプスペースを拡張するために、メッセージタイプ13、14、および15のフラグビットフィールドの使用を指定しています。[RFC6166]のタイプスペース拡張は、[RFC8736]によって時代遅れになりました。この文書は廃止[RFC8736]。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
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.
一般的なPIMヘッダーは、[RFC7761]のセクション4.9で定義されています。このドキュメントは、予約済みフィールドの定義を更新し、「フラグビットフィールド」と呼んでいます。更新された共通ヘッダー形式は以下のとおりです。
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
図1：更新された共通ヘッダー
The Flag Bits field is defined in Section 4. All other fields remain unchanged.
フラグビットフィールドはセクション4で定義されています。他のすべてのフィールドは変更されていません。
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.
特に指定されていない限り、各PIMタイプのすべてのフラグビットは割り当てられていません[RFC8126]。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。新しいPIMタイプの仕様は、ビットを異なる方法で処理する必要があるかどうかを示す必要があります。
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.
フラグビットを定義する場合、特定のビットを参照する明確な方法を持つことが役立ちます。フラグビットの中で最も重要なビット、タイプフィールドの直後のビットはビット7と呼ばれます。最も重要ではない、チェックサムフィールドの前のビットはビット0と呼ばれます。これは図に示されています。下に。
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
図2：フラグビット
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.
PIMメッセージタイプ4（Bootstrap）[RFC5059]は、フラグビット7を非適合と定義しています。ビットの使用法は、そのドキュメントで定義されています。残りのフラグビットは割り当てられていません。
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.
PIMメッセージタイプ10（DF選挙）[RFC5015]は、4つの最も重要なフラグビット（ビット4-7）がサブタイプとして使用されることを指定しています。これらのビットの使用は、そのドキュメントで定義されています。残りのフラグビットは割り当てられていません。
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.
PIMメッセージタイプ12（PIMフラッディングメカニズム）[RFC8364]は、フラグビット7を非適合と定義しています。ビットの使用法は、そのドキュメントで定義されています。残りのフラグビットは割り当てられていません。
These types and the corresponding flag bits are defined in Section 5.
これらのタイプと対応するフラグビットは、セクション5で定義されています。
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.
このドキュメントは、タイプ13、14、および15を拡張して、それぞれが16の新しいタイプになるようになり、将来のPIM拡張機能で48種類が利用可能になります。この拡張機能は、4つの最も重要なフラグビット（ビット4-7）を使用してサブタイプフィールド（図3を参照）を定義することによって達成されます。Notation Type.SubTypeは、新しい拡張型を参照するために使用されます。残りの4つのフラグビット（ビット0〜3、以下のFBと略されます）は、各拡張タイプで定義されます。
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.
拡張された各タイプは、タイプフィールドとサブタイプフィールドの連結に起因する8つのビットで表されます。共通のタイプフィールドを持つ拡張タイプメッセージ間に関係は予想されません。
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
図3：サブタイプ
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].
このドキュメントは、一般的なPIMヘッダーのフラグビットの使用を明確にし、PIMタイプの空間を拡張します。そのため、[RFC7761]および[RFC3973]の考慮事項にセキュリティや変更に影響はありません。
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.
このドキュメントでは、「PIMメッセージタイプ」レジストリを更新して、各PIMメッセージタイプで使用するために定義されるフラグビットを示し、表1に示すようにビットが既に指定されている場合を除き、登録ステータスを未割り当てに変更します。ポリシーはIETFレビューのままです[RFC8126]。このレジストリへの割り当ては、タイプに加えて、フラグビットの非デフォルト使用（セクション4を参照）を定義する必要があります。
Extended type 15.15 is Reserved [RFC8126] for future extensions.
拡張タイプ15.15は、将来の拡張のために予約されています[RFC8126]。
Because this document obsoletes [RFC8736], IANA has changed the references to [RFC8736] in the registry to point to this document instead.
このドキュメントが廃止され[RFC8736]、IANAはレジストリの[RFC8736]への参照を変更して、代わりにこのドキュメントを指しています。
The updated "PIM Message Types" registry is shown below.
更新された「PIMメッセージタイプ」レジストリを以下に示します。
+============+===============+=================+===========+
| 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
表1：更新されたPIMメッセージタイプレジストリ
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.
セクション5で説明されているように、上記の未割り当てのタイプは、型の拡張型型表記を使用します。subtype。各拡張タイプには、4つのフラグビットのみが利用可能です。新しい拡張メッセージタイプは、13.0、次に13.1などから、連続して割り当てられる必要があります。
[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>.
[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>.
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