[要約] RFC 9084は、OSPFプロトコルにおけるプレフィックス発信者の情報を拡張するためのものです。この拡張により、ルーティング情報のソースをより正確に識別し、ネットワークの効率性と安全性を向上させることが目的です。主に、大規模ネットワークや複雑なルーティング環境での利用が想定されています。
Internet Engineering Task Force (IETF) A. Wang
Request for Comments: 9084 China Telecom
Category: Standards Track A. Lindem
ISSN: 2070-1721 Cisco Systems, Inc.
J. Dong
Huawei Technologies
P. Psenak
K. Talaulikar, Ed.
Cisco Systems, Inc.
August 2021
OSPF Prefix Originator Extensions
OSPFプレフィックス発信元エクステンション
Abstract
概要
This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. These extensions do not change the core OSPF route computation functionality but provide useful information for network analysis, troubleshooting, and use cases like traffic engineering.
このドキュメントは、プレフィックス広告との接頭辞を発表したノードに関連付けられている情報を含めるためのOSPF拡張機能を定義しています。これらの拡張機能は、コアOSPFルート計算機能を変更しませんが、トラフィックエンジニアリングのようなネットワーク分析、トラブルシューティング、およびユースケースに役立つ情報を提供します。
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.
この文書は、インターネットエンジニアリングタスクフォース（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/rfc9084.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9084で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Protocol Extensions
2.1. Prefix Source OSPF Router-ID Sub-TLV
2.2. Prefix Source Router Address Sub-TLV
3. Elements of Procedure
4. Security Considerations
5. Operational Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgement
Authors' Addresses
Prefix attributes are advertised in OSPFv2 [RFC2328] using the Extended Prefix Opaque Link State Advertisement (LSA) [RFC7684] and in OSPFv3 [RFC5340] using the various Extended Prefix LSA types [RFC8362].
プレフィックス属性は、拡張プレフィックス不透明リンク状態広告（RFC7684]とOSPFv3 [RFC5340]を使用して、さまざまな拡張プレフィックスLSAタイプ[RFC8362]を使用して、OSPFv2 [RFC2328]でアドバタイズされています。
The procedures for identification of the originating router for a prefix in OSPF vary by the type of the prefix and, currently, it is not always possible to produce an accurate result. For intra-area prefixes, the originating router is identified by the Advertising Router field of the area-scoped LSA used for those prefix advertisements. However, for inter-area prefixes advertised by an Area Border Router (ABR), the Advertising Router field of their area-scoped LSAs is set to the ABR itself and the information about the router originating the prefix advertisement is lost in the process of prefix propagation across areas. For Autonomous System (AS) external prefixes, the originating router may be considered as the Autonomous System Border Router (ASBR) and is identified by the Advertising Router field of the AS-scoped LSA used. However, the actual originating router for the prefix may be a remote router outside the OSPF domain. Similarly, when an ABR performs translation of Not-So-Stubby Area (NSSA) [RFC3101] LSAs to AS-external LSAs, the information associated with the NSSA ASBR (or the router outside the OSPF domain) is not propagated across the OSPF domain.
OSPFのプレフィックスの発信ルータの識別の手順は、プレフィックスの種類によって異なりますが、現在正確な結果を生み出すことは必ずしも可能ではありません。領域内接頭辞の場合、発信ルータは、それらの接頭辞広告に使用されているエリアスコープLSAの広告ルータフィールドによって識別されます。ただし、エリアボーダールータ（ABR）によってアドバタイズされている領域間プレフィックスの場合、それらのエリアスコープLSAの広告ルータフィールドはABR自体に設定され、プレフィックス広告を発信するルータに関する情報はプレフィックスのプロセスで失われます。地域間の伝播。自律システム（AS）外部プレフィックスの場合、発信ルータは自律システム境界ルータ（ASBR）と見なされてもよく、使用されているASスコープLSAの広告ルータフィールドによって識別されます。ただし、プレフィックスの実際の発信ルータは、OSPFドメインの外部でのリモートルーターになる可能性があります。同様に、ABRがSO-STUBBY領域（NSSA）[RFC3101] LSAの翻訳をAS外部LSASに実行すると、NSSA ASBR（またはOSPFドメイン外のルータ）に関連付けられている情報がOSPFドメイン間で伝播されません。 。
While typically the originator of information in OSPF is identified by its OSPF Router ID, it does not necessarily represent a reachable address for the router since the OSPF Router ID is a 32-bit number that is unique in the OSPF domain. For OSPFv2, a common practice is to use one of the IPv4 addresses of the node (e.g., a loopback interface) as the OSPF Router ID. However, this cannot always be assumed and this approach does not apply to IPv6 addresses with OSPFv3. The IPv4/IPv6 Router Address, as respectively defined in [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3, provides an address to reach the advertising router.
通常、OSPF内の情報の発信元はそのOSPFルータIDによって識別されますが、OSPFルータIDはOSPFドメイン内で一意である32ビットの番号であるため、ルータの到達可能なアドレスを表すわけではありません。OSPFv2の場合、一般的な方法は、OSPFルータIDとしてノードのIPv4アドレス（たとえば、ループバックインターフェース）のいずれかを使用することです。ただし、これは常に想定できず、このアプローチはOSPFv3を持つIPv6アドレスには適用されません。OSPFv2とOSPFv3の[RFC3630]と[RFC5329]でそれぞれ定義されているIPv4 / IPv6ルータアドレスは、広告ルータに到達するためのアドレスを提供します。
The primary use case for the extensions proposed in this document is to be able to identify the originator of a prefix in the network. In cases where multiple prefixes are advertised by a given router, it is also useful to be able to associate all these prefixes with a single router even when prefixes are advertised outside of the area in which they originated. It also helps to determine when the same prefix is being originated by multiple routers across areas.
この文書で提案されている拡張機能の主なユースケースは、ネットワーク内のプレフィックスの発信者を識別できることです。複数のプレフィックスが特定のルータによってアドバタイズされている場合には、プレフィックスが発生した領域の外側であっても、これらすべてのプレフィックスを単一のルータと関連付けることができると便利です。また、同じ接頭辞が地域間の複数のルータによって発生しているかを判断するのにも役立ちます。
This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These extensions do not change the core OSPF route computation functionality. They provide useful information for topology analysis and traffic engineering, especially on a controller when this information is advertised as an attribute of the prefixes via mechanisms such as Border Gateway Protocol - Link State (BGP-LS) [RFC7752] [RFC9085].
この文書は、プレフィックス広告と共に接頭辞を発信するルータに関連する情報を含めるためのOSPFプロトコルへの拡張を提案します。これらの拡張機能は、コアOSPFルート計算機能を変更しません。これらは、境界ゲートウェイプロトコルリンク状態（BGP-LS）[RFC7752] [RFC9082] [RFC9085] [RFC9082] [RFC9082] [RFC9085] [RFC9085] [RFC9082] [RFC9082] [RFC9082] [RFC9085] [RFC9085] [RFC9085] [RFC9085] [RFC9085] [RFC9085] [RFC9085] [RFC9085] [RFC9085] [RFC9085]。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs. They are used, respectively, to include the Router ID of, and a reachable address of, the router that originates the prefix as a prefix attribute.
このドキュメントでは、プレフィックスソースのOSPF Router-IDとプレフィックスソースルータアドレスサブTLVを定義します。プレフィックス属性としてプレフィックスを発信するルータのルータID、および到達可能アドレスをそれぞれ含むように、それらはそれぞれ使用されます。
For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the Prefix Source OSPF Router-ID Sub-TLV is an optional sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix advertisement.
OSPFv2の場合、プレフィックスソースOSPF Router-IDサブTLVは、OSPFv2拡張プレフィックスTLV [RFC7684]のオプションのサブTLVです。OSPFv3の場合、プレフィックスソースOSPF Router-IDサブTLVは、IPv4 [RFC5838]のどちらかを発信する場合、Area-AreaプレフィックスTLV、Area-Prefix TLV、および外部プレフィックスTLV [RFC8362]のオプションのサブTLVです。]またはIPv6プレフィックス広告。
The Prefix Source OSPF Router-ID Sub-TLV has the following format:
接頭辞ソースOSPF Router-IDサブTLVは次の形式です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Prefix Source OSPF Router-ID Sub-TLV Format
図1：接頭辞ソースOSPF Router-IDサブTLVフォーマット
Where: Type: 4 for OSPFv2 and 27 for OSPFv3
ここで：タイプ：ospfv2の場合は4 27 for OSPFv3
Length: 4
長さ：4
OSPF Router ID: the OSPF Router ID of the OSPF router that originated the prefix advertisement in the OSPF domain
OSPFルーターID：OSPFドメインのプレフィックス広告を発信したOSPFルータのOSPFルータID
The parent TLV of a prefix advertisement MAY include more than one Prefix Source OSPF Router-ID Sub-TLV, one corresponding to each of the Equal-Cost Multipath (ECMP) nodes that originated the advertised prefix.
プレフィックス広告の親TLVには、広告付きプレフィックスを発信した等価コストマルチパス（ECMP）ノードのそれぞれに対応する1つが複数のプレフィックスソースOSPFルータIDサブTLVを含むことができる。
For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements.
エリア内接頭辞広告のために、Prefix Source OSPF Router-ID Sub-TLVは無効であると見なされ、OSPFルータIDフィールドがConthing LSAの広告ルータフィールドと同じであれば無視されます。同様の検証は、領域間および外部プレフィックス広告のために確実に実行することはできません。
A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be considered invalid and ignored. Additionally, reception of such sub-TLVs SHOULD be logged as an error (subject to rate limiting).
OSPFルータIDフィールドを0に設定した受信プレフィックスソースOSPF Router-IDサブTLVは無効で無視されなければなりません。さらに、このようなサブTLVの受信はエラーとして記録されます（レート制限の対象）。
For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the Prefix Source Router Address Sub-TLV is an optional sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix advertisement.
OSPFv2の場合、Prefix Source Router Address Sub-TLVはOSPFv2拡張プレフィックスTLV [RFC7684]のオプションのサブTLVです。OSPFv3の場合、Prefix Source Router Address Sub-TLVは、IPv4 [RFC5838]のいずれかを発信する場合、Area-Area-Prefix TLV、Area-Prefix TLV、および外部プレフィックスTLV [RFC8362]のオプションのサブTLVです。IPv6プレフィックス広告。
The Prefix Source Router Address Sub-TLV has the following format:
PrefixソースルータアドレスSUB-TLVは次の形式です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Prefix Source Router Address Sub-TLV Format
図2：プレフィックスソースルータアドレスサブTLVフォーマット
Where: Type: 5 for OSPFv2 and 28 for OSPFv3
ここで：type：ospfv2とospfv3の場合は5
Length: 4 or 16
長さ：4または16
Router Address: A reachable IPv4 or IPv6 router address for the router that originated the IPv4 or IPv6 prefix advertisement, respectively. Such an address would be semantically equivalent to what may be advertised in the OSPFv2 Router Address TLV [RFC3630] or in the OSPFv3 Router IPv6 Address TLV [RFC5329].
ルータアドレス：それぞれIPv4またはIPv6プレフィックス広告を発信したルータの到達可能なIPv4またはIPv6ルータアドレス。そのようなアドレスは、OSPFV2ルータアドレスTLV [RFC3630]またはOSPFv3ルータIPv6アドレスTLV [RFC5329]でアドバスされ得るものと意味的に等価であろう。
The parent TLV of a prefix advertisement MAY include more than one Prefix Source Router Address Sub-TLV, one corresponding to each of the Equal-Cost Multipath (ECMP) nodes that originated the advertised prefix.
接頭辞広告の親TLVは、広告付きプレフィックスを発信した等価コストマルチパス（ECMP）ノードのそれぞれに対応する1つが複数のプレフィックスソースルータアドレスサブTLVを含み得る。
A received Prefix Source Router Address Sub-TLV that has an invalid length (i.e., not consistent with the prefix's address family) MUST be considered invalid and ignored. Additionally, reception of such sub-TLVs SHOULD be logged as an error (subject to rate limiting).
無効な長さ（すなわち、プレフィックスのアドレスファミリと一致しない）を有する受信されたプレフィックスソースルータアドレスは無効で無視される必要があります。さらに、このようなサブTLVの受信はエラーとして記録されます（レート制限の対象）。
This section describes the procedure for the advertisement of the Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs along with the prefix advertisement.
このセクションでは、プレフィックス送信元OSPF Router-IDとプレフィックス送信元ルータアドレスサブTLVの広告の手順について説明します。
The OSPF Router ID of the Prefix Source OSPF Router-ID is set to the OSPF Router ID of the node originating the prefix in the OSPF domain.
接頭辞ソースOSPF Router-IDのOSPFルータIDは、OSPFドメイン内のプレフィックスを発信するノードのOSPFルータIDに設定されています。
If the originating node is advertising an OSPFv2 Router Address TLV [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the same address MUST be used in the Router Address field of the Prefix Source Router Address Sub-TLV. When the originating node is not advertising such an address, implementations can select a unique and reachable local address (for example, advertised with the N-Flag set [RFC7684] or N-bit set [RFC8362]) on the originating node to advertise in the Router Address field.
発信ノードがOSPFv2ルータアドレスTLV [RFC3630]またはOSPFV3ルータIPv6アドレスTLV [RFC5329]をアドバタイズしている場合は、同じアドレスをプレフィックスソースルータアドレスサブTLVのルータアドレスフィールドに使用する必要があります。発信元ノードがそのようなアドレスを広告していない場合、実装は、発信元ノード上の一意の到達可能なローカルアドレスを選択することができます（たとえば、Originatingノードでは、RFC7684のNビットSET [RFC8362]）をアドバタイズすることができます。ルータアドレスフィールド。
When an ABR generates inter-area prefix advertisements into its non-backbone areas corresponding to an inter-area prefix advertisement from the backbone area, the only way to determine the originating node information is based on the Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs present in the inter-area prefix advertisement originated into the backbone area by an ABR from another non-backbone area. The ABR performs its prefix calculation to determine the set of nodes that contribute to ECMP paths for the prefix. It MUST only use the prefix originator information from this set of nodes. The ABR MUST NOT include the Prefix Source OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it is unable to determine the information for the originating nodes contributing ECMP paths.
ABRがバックボーン領域からの領域間プレフィックス広告に対応する非バックボーン領域にABRを生成すると、発信元ノード情報を判断する唯一の方法は、プレフィックス元OSPFルータIDとプレフィックス元に基づいています。領域間プレフィックス広告に存在するルータアドレスサブTLVは、別の非バックボーン領域からのABRによってバックボーン領域に発信されました。ABRは、接頭辞計算を実行して、プレフィックスのECMPパスに寄与するノードのセットを決定します。このノードのセットからプレフィックス発信者情報のみを使用する必要があります。ABRは、ECMPパスに寄与する発信ノードの情報を決定できない場合、Prefix Source OSPFルータIDまたはプレフィックスソースルータアドレスサブTLVを含めてはなりません。
Implementations may support the propagation of the originating node information along with a redistributed prefix into the OSPF domain from another routing domain. The details of such mechanisms are outside the scope of this document. Such implementations may also provide control on whether the Router Address in the Prefix Source Router Address Sub-TLV is set as the ASBR node address or as the address of the actual node outside the OSPF domain that owns the prefix.
実装は、他のルーティングドメインからOSPFドメインへの再配布されたプレフィックスと共に発信元ノード情報の伝播をサポートすることができる。そのようなメカニズムの詳細はこの文書の範囲外です。そのような実装はまた、プレフィックスソースルータアドレスサブTLV内のルータアドレスがASBRノードアドレスとして設定されているか、または接頭辞を所有するOSPFドメインの外側の実際のノードのアドレスとして制御を制御することができる。
When translating NSSA prefix advertisements [RFC3101] to AS external prefix advertisements, the NSSA ABR follows the same procedures as an ABR generating inter-area prefix advertisements for the propagation of the originating node information.
NSSAプレフィックス広告[RFC3101]を外部プレフィックス広告として翻訳するとき、NSSA ABRは、発信元ノード情報の伝播のためのABR生成領域プレフィックス広告と同じ手順に従います。
Since this document extends the OSPFv2 Extended Prefix LSA, the security considerations for [RFC7684] are applicable. Similarly, since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and E-NSSA-LSA, the security considerations for [RFC8362] are applicable. The new sub-TLVs introduced in this document are optional and do not affect the OSPF route computation and therefore do not affect the security aspects of OSPF protocol operations.
このドキュメントはOSPFV2拡張プレフィックスLSAを拡張しているため、[RFC7684]のセキュリティ上の考慮事項が適用されます。同様に、このドキュメントはOSPFV3 e-intera-area-prefix-lsa、e-area-prefix-lsa、e-as-as-as-as-estab-lsa、およびe-nssa-lsaを拡張するため、[RFC8362]のセキュリティ上の考慮事項適用されます。この文書で導入された新しいサブTLVはオプションであり、OSPFルート計算には影響しないため、OSPFプロトコル操作のセキュリティ側面には影響しません。
A rogue node that can inject prefix advertisements may use the extensions introduced in this document to advertise bogus prefix source information.
プレフィックス広告を注入できる不正ノードは、この文書で導入された拡張機能を使用して、Bogusプレフィックスのソース情報をアドバタイズすることができます。
Consideration should be given to the operational impact of the increase in the size of the OSPF Link-State Database as a result of the protocol extensions in this document. Based on deployment design and requirements, a subset of prefixes may be identified for which originating node information is required to be included in prefix advertisements.
このドキュメントのプロトコル拡張の結果として、OSPFリンク状態データベースのサイズの増加の運用上の影響を考慮する必要があります。展開設計および要件に基づいて、受信ノード情報がプレフィックス広告に含まれる必要があるかについての接頭辞のサブセットを識別することができる。
The propagation of prefix source node information for prefix advertisements advertised across an OSPF area or domain boundaries will expose information outside of an area or domain where it would normally be hidden or abstracted by the base OSPF protocol. Based on deployment design and requirements, the propagation of node information across area or domain boundaries may be limited to a subset of prefixes in the ABRs or ASBRs, respectively.
OSPFエリアまたはドメイン境界に広告されているプレフィックスアドバタイズメントのプレフィックスソースノード情報の伝播は、通常、基本OSPFプロトコルによって通常非表示または抽象化される領域またはドメインの外部での情報を公開します。展開設計および要件に基づいて、エリアまたはドメイン境界にわたるノード情報の伝播は、それぞれABSまたはASBR内のプレフィックスのサブセットに制限されてもよい。
The identification of the node that is originating a specific prefix in the network may aid in the debugging of issues related to prefix reachability within an OSPF network.
ネットワーク内の特定のプレフィックスを発信しているノードの識別は、OSPFネットワーク内のプレフィックス到達可能性に関連する問題のデバッグを支援することができる。
Per this document, IANA has allocated the following codepoints from the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open Shortest Path First v2 (OSPFv2) Parameters" registry.
このドキュメントごとに、IANAは、「OSPFV2拡張プレフィックスTLVサブTLVS」レジストリから、「Open Shortest Path First V2（OSPFv2）パラメータ」レジストリから次のコードポイントを割り当てました。
+=======+==============================+===========+
| Value | Description | Reference |
+=======+==============================+===========+
| 4 | Prefix Source OSPF Router-ID | RFC 9084 |
+-------+------------------------------+-----------+
| 5 | Prefix Source Router Address | RFC 9084 |
+-------+------------------------------+-----------+
Table 1: Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs
表1：OSPFv2拡張プレフィックスTLVサブTLVのCEDEPOINTS
Per this document, IANA has allocated the following codepoints from the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "Open Shortest Path First v3 (OSPFv3) Parameters" registry.
このドキュメントごとに、IANAは、「OSPFV3 Extended-LSAサブTLVS」レジストリから「Open Shortest Path First V3（OSPFv3）パラメータ」レジストリから割り当てました。
+=======+==============================+===========+
| Value | Description | Reference |
+=======+==============================+===========+
| 27 | Prefix Source OSPF Router-ID | RFC 9084 |
+-------+------------------------------+-----------+
| 28 | Prefix Source Router Address | RFC 9084 |
+-------+------------------------------+-----------+
Table 2: Codepoints in OSPFv3 Extended-LSA Sub-TLVs
表2：OSPFv3拡張LSAサブTLVのCEDEPOINTS
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J.、 "OSPFバージョン2"、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「OSPFバージョン2へのトラフィックエンジニアリング（TE）拡張機能」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc-editor.org/info/rfc3630>。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A.、A. Lindem、Ed。、「OSPFバージョン3へのトラフィックエンジニアリング拡張」、RFC 5329、DOI 10.17487 / RFC5329、2008年9月、<https：//www.rfc-editor.org/info/rfc5329>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J.、およびA. Lindem、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：///www.rfc-編集者.org / info / rfc5340>。
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7684] Psenak、P.、Gredler、H.、Shakir、R.、Henderickx、W.、Tantsura、J.、およびA. Lindem、 "OSPFv2プレフィックス/リンク属性広告"、RFC 7684、DOI 10.17487 / RFC7684、2015年11月、<https：//www.rfc-editor.org/info/rfc7684>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8362]リンデム、A.、Roy、A.、Goethals、D.、Reddy Vallem、V.、F. Baker、 "OSPFv3リンク州広告（LSA）拡張性"、RFC 8362、DOI 10.17487 / RFC8362、2018年4月<https://www.rfc-editor.org/info/rfc8362>。
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, <https://www.rfc-editor.org/info/rfc3101>.
[RFC3101] Murphy、P.、「OSPFではない」オプション "、RFC 3101、DOI 10.17487 / RFC3101、2003年1月、<https://www.rfc-editor.org/info/rfc3101>。
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, <https://www.rfc-editor.org/info/rfc5838>.
[RFC5838]リンデム、A.、ED。、Mirtorabi、S.、Roy、A.、Barnes、M.、およびR. Aggarwal、「OSPFv3の住所家族のサポート」、RFC 5838、DOI 10.17487 / RFC5838、2010年4月<https：//www.rfc-editor.org/info/rfc5838>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、およびS. Ray、「BGPを使用したリンク状態およびトラフィックエンジニアリングの北部分布」、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https：//www.rfc-editor.org/info/rfc7752>。
[RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, August 2021, <https://www.rfc-editor.org/info/rfc9085>.
[RFC9085] Previdi、S.、Talaulikar、K。、ED。、Filsfils、C.、Gredler、H.、およびM.Chen、「境界ゲートウェイプロトコル - セグメントルーティング用のBGP-LS拡張」、RFC9085、DOI 10.17487 / RFC9085、2021年8月、<https://www.rfc-editor.org/info/rfc9085>。
Acknowledgement
謝辞
Many thanks to Les Ginsberg for his suggestions on this document. Also, thanks to Jeff Tantsura, Rob Shakir, Gunter Van de Velde, Goethals Dirk, Smita Selot, Shaofu Peng, John E. Drake, and Baalajee S. for their review and valuable comments. The authors would also like to thank Alvaro Retana for his detailed review and suggestions for the improvement of this document.
この文書に関する彼の提案のためにLes Ginsbergに感謝します。また、Jeff Tantsura、Rob Shakir、Gunter Van de Velde、Goethals Dirk、Smita Selot、Shaofu Peng、John E. Drake、Baalajee S.レビューや貴重なコメントのおかげで。著者らはまた、この文書の改善のために彼の詳細なレビューと提案についてAlvaro Retanaに感謝します。
Authors' Addresses
著者の住所
Aijun Wang China Telecom Beiqijia Town Changping District Beijing 102209 China
Aijun Wang China Telecom Beiqijia Town Changing District Beijing 102209中国
Email: wangaj3@chinatelecom.cn
Acee Lindem Cisco Systems, Inc. 301 Midenhall Way Cary, NC 27513 United States of America
Acee Lindem Cisco Systems、Inc。301 Midenhall Way Cary、NC 27513アメリカ合衆国
Email: acee@cisco.com
Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China
Jie Dong Huawei Technologies Huawei Campus、156北部RD。北京100095中国
Email: jie.dong@huawei.com
Peter Psenak Cisco Systems, Inc. Eurovea Centre, Central 3 Pribinova Street 10 81109 Bratislava Slovakia
Peter Psenak Cisco Systems、Inc。Eurovea Center、中央3 Pribinova Street 10 81109 Bratislava Slovakia
Email: ppsenak@cisco.com
Ketan Talaulikar (editor) Cisco Systems, Inc. India
Ketan Talaulikar（編集）Cisco Systems、Inc。インド
Email: ketant@cisco.com