[要約] RFC 8510は、OSPF Link-Local Signaling（LLS）拡張機能に関する仕様であり、ローカルインターフェースIDの広告に関するものです。このRFCの目的は、OSPFプロトコルでのローカルインターフェースIDの効果的な広告と使用を可能にすることです。
Internet Engineering Task Force (IETF) P. Psenak, Ed.
Request for Comments: 8510 K. Talaulikar
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 W. Henderickx
Nokia
P. Pillay-Esnault
Huawei USA
January 2019
OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement
ローカルインターフェイスIDアドバタイズメントのOSPF Link-Local Signaling（LLS）拡張
Abstract
概要
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID).
すべてのOSPFインターフェイスには、ルータ上のインターフェイスを一意に識別するインターフェイスIDが割り当てられています。場合によっては、隣接のリモート側に割り当てられているインターフェイスID（リモートインターフェイスID）を知っておくと便利です。
This document describes the extensions to OSPF link-local signaling (LLS) to advertise the Local Interface ID.
このドキュメントでは、ローカルインターフェイスIDをアドバタイズするためのOSPFリンクローカルシグナリング（LLS）の拡張機能について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8510.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8510で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Interface ID Exchange Using Link Local TE Opaque LSA .......4
1.2. Requirements Language ......................................4
2. Interface ID Exchange Using OSPF LLS ............................4
2.1. Local Interface ID TLV .....................................5
3. Backward Compatibility with RFC 4203 ............................5
4. IANA Considerations .............................................6
5. Security Considerations .........................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. [RFC2328] uses this Interface ID in the Router Link State Advertisement (Router-LSA) Link Data for unnumbered links and uses the value of the MIB-II ifIndex [RFC2863]. [RFC4203] refers to these Interface IDs as the Link Local/Remote Identifiers and defines a way to advertise and use them for GMPLS purposes. [RFC8379] defines a way to advertise Local/ Remote Interface IDs in the OSPFv2 Extended Link Opaque LSA.
すべてのOSPFインターフェイスには、ルータ上のインターフェイスを一意に識別するインターフェイスIDが割り当てられています。 [RFC2328]は、番号なしリンクのルーターリンクステートアドバタイズメント（Router-LSA）リンクデータでこのインターフェイスIDを使用し、MIB-II ifIndex [RFC2863]の値を使用します。 [RFC4203]はこれらのインターフェイスIDをリンクローカル/リモート識別子と呼び、GMPLSの目的でそれらをアドバタイズして使用する方法を定義します。 [RFC8379]は、OSPFv2 Extended Link Opaque LSAでローカル/リモートインターフェイスIDをアドバタイズする方法を定義しています。
There is a known OSPFv2 protocol problem in verifying the bidirectional connectivity with parallel unnumbered links. If there are two parallel unnumbered links between a pair of routers and each link is only advertised from a single direction, such two unidirectional parallel links could be considered as a valid single bidirectional link during the OSPF route computation on some other router. If each link is advertised with both its Local and Remote Interface IDs, the advertisement of each link from both sides of adjacency can be verified by cross-checking the Local and Remote Interface IDs of both advertisements.
パラレルアンナンバードリンクとの双方向接続を確認する際に、既知のOSPFv2プロトコルの問題があります。ルーターのペアの間に2つのパラレル番号なしリンクがあり、各リンクが単一方向からのみアドバタイズされる場合、そのような2つの単方向パラレルリンクは、他のルーターでのOSPFルートの計算中に有効な単一双方向リンクと見なすことができます。各リンクがローカルおよびリモートインターフェイスIDの両方でアドバタイズされる場合、隣接の両側からの各リンクのアドバタイズは、両方のアドバタイズのローカルおよびリモートインターフェイスIDをクロスチェックすることで確認できます。
From the perspective of the advertising router, the Local Interface ID is a known value. However, the Remote Interface ID needs to be learned before it can be advertised. [RFC4203] suggests using the TE Link Local LSA [RFC3630] to communicate the Local Interface ID to neighbors on the link. Though such a mechanism works, it has some drawbacks.
アドバタイズルータの観点からは、ローカルインターフェイスIDは既知の値です。ただし、アドバタイズする前に、リモートインターフェイスIDを学習する必要があります。 [RFC4203]は、TEリンクローカルLSA [RFC3630]を使用して、ローカルインターフェイスIDをリンク上のネイバーに通信することを提案しています。このようなメカニズムは機能しますが、いくつかの欠点があります。
This document proposes an extension to OSPF link-local signaling (LLS) [RFC5613] to advertise the Local Interface ID.
このドキュメントは、ローカルインターフェイスIDをアドバタイズするためのOSPFリンクローカルシグナリング（LLS）[RFC5613]への拡張を提案します。
Usage of the Link Local TE Opaque LSA to propagate the Local Interface ID to the neighbors on the link is described in [RFC4203]. This mechanism has the following problems:
リンクローカルTE Opaque LSAを使用して、ローカルインターフェイスIDをリンク上のネイバーに伝播することについては、[RFC4203]で説明されています。このメカニズムには次の問題があります。
o LSAs can only be flooded over an existing adjacency that is in Exchange state or greater. The adjacency state machine progresses independently on each side of the adjacency and, as such, may reach the Full state on one side before the Link Local TE Opaque LSA arrives. The consequence of this is that the link can be initially advertised without the Remote Interface ID. Later, when the Link Local TE Opaque LSA arrives, the link must be advertised again but this time with the valid Remote Interface ID. Implementations may choose to wait before advertising the link, but there is no guarantee that the neighbor will ever advertise the Link Local TE Opaque LSA with the Interface ID. In summary, the existing mechanism does not guarantee that the Remote Interface ID is known at the time the link is advertised.
o LSAは、Exchange状態以上の既存の隣接にのみフラッディングできます。隣接状態マシンは、隣接の両側で独立して進行するため、リンクローカルTE不透明LSAが到着する前に、片側で完全状態に到達する可能性があります。この結果、リンクはリモートインターフェイスIDなしで最初にアドバタイズできます。その後、リンクローカルTE Opaque LSAが到着すると、リンクを再度アドバタイズする必要がありますが、今回は有効なリモートインターフェイスIDを使用してアドバタイズします。実装はリンクをアドバタイズする前に待機することを選択できますが、ネイバーがインターフェイスIDを使用してリンクローカルTE Opaque LSAをアドバタイズするという保証はありません。要約すると、既存のメカニズムは、リンクがアドバタイズされたときにリモートインターフェイスIDがわかっていることを保証しません。
o The Link Local TE Opaque LSA is defined for MPLS Traffic Engineering, but the knowledge of the Remote Interface ID is useful also for cases where MPLS TE is not used. One example is the mentioned lack of a valid 2-way connectivity check for parallel point-to-point links between OSPF routers.
o リンクローカルTE Opaque LSAはMPLSトラフィックエンジニアリング用に定義されていますが、リモートインターフェイスIDの知識は、MPLS TEを使用しない場合にも役立ちます。 1つの例は、OSPFルーター間の並列ポイントツーポイントリンクに対する有効な双方向接続チェックがないことです。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
To address the problems described earlier and to allow the Interface ID exchange to be part of the neighbor discovery process, we propose to extend OSPF link-local signaling to advertise the Local Interface ID in OSPF Hello and Database Description (DD) packets.
前述の問題に対処し、インターフェイスID交換をネイバー探索プロセスの一部にするために、OSPFリンクローカルシグナリングを拡張して、OSPF Helloおよびデータベース記述（DD）パケットでローカルインターフェイスIDをアドバタイズすることを提案します。
The Local Interface ID TLV is an LLS TLV. It has the following format:
ローカルインターフェイスID TLVはLLS 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 18
タイプ：18
Length: 4 octets
長さ：4オクテット
Local Interface ID: The value of the Local Interface ID.
ローカルインターフェースID：ローカルインターフェースIDの値。
Local Interface ID TLV signaling using LLS is applicable to all OSPF interface types other than virtual links.
LLSを使用したローカルインターフェイスID TLVシグナリングは、仮想リンク以外のすべてのOSPFインターフェイスタイプに適用できます。
If the Local Interface ID signaling via the Link Local TE Opaque LSA is supported in addition to the new LLS mechanism, implementations that support Local Interface ID signaling using LLS MUST prefer the Local Interface ID value received through LLS over the value received through the Link Local TE Opaque LSA if both are received from the same OSPF router.
リンクローカルTE Opaque LSAを介したローカルインターフェイスIDシグナリングが新しいLLSメカニズムに加えてサポートされている場合、LLSを使用してローカルインターフェイスIDシグナリングをサポートする実装は、リンクローカルを介して受信した値よりもLLSを介して受信したローカルインターフェイスID値を優先する必要があります。両方が同じOSPFルーターから受信された場合、TE Opaque LSA。
Implementations that support Local Interface ID signaling via the Link Local TE Opaque LSA MAY continue to do so to ensure backward compatibility. If they also support Local Interface ID signaling using LLS as described in the document, they MUST signal the same Local Interface ID via both mechanisms.
リンクローカルTE Opaque LSAを介してローカルインターフェイスIDシグナリングをサポートする実装は、下位互換性を確保するために引き続きそうすることができます。ドキュメントで説明されているように、LLSを使用してローカルインターフェイスIDシグナリングもサポートする場合、両方のメカニズムを介して同じローカルインターフェイスIDをシグナリングする必要があります。
During the rare conditions in which the Local Interface ID changes, a timing interval may exist where the received values of the Local Interface ID advertised through LLS and the Link Local TE Opaque LSA may differ. Such a situation is temporary, and received values via both mechanisms should become equal as soon as the next Hello and/or Link Local TE Opaque LSA is regenerated by the originator.
ローカルインターフェイスIDが変化するまれな状況の間に、LLSとリンクローカルTE Opaque LSAを通じてアドバタイズされたローカルインターフェイスIDの受信値が異なる場合があるタイミング間隔が存在する可能性があります。このような状況は一時的なものであり、次のHelloやリンクローカルTE Opaque LSAが発信者によって再生成されるとすぐに、両方のメカニズムを介して受信した値は等しくなるはずです。
IANA has allocated the following code point in the "Link Local Signalling TLV Identifiers (LLS Types)" subregistry of the "Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/ Value Identifiers (TLV)" registry.
IANAは、「Open Shortest Path First（OSPF）Link Local Signaling（LLS）-Type / Length / Value Identifiers（TLV）」レジストリの「Link Local Signaling TLV Identifiers（LLS Types）」サブレジストリに次のコードポイントを割り当てました。
18 - Local Interface ID TLV
18-ローカルインターフェイスID TLV
The security considerations for "OSPF Link-Local Signaling" [RFC5613] also apply to the Local Interface ID TLV described in this document. The current usage of a neighbor's Local Interface ID is to disambiguate parallel links between OSPF routers. Hence, modification of the advertised Local Interface ID TLV may result in the wrong neighbor Interface ID being advertised in the OSPFv2 Extended Link Opaque LSA [RFC7684] and could prevent the link from being used. If authentication is being used in the OSPF routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV [RFC5613] SHOULD also be used to protect the contents of the LLS block.
「OSPFリンクローカルシグナリング」[RFC5613]のセキュリティに関する考慮事項は、このドキュメントで説明されているローカルインターフェイスID TLVにも適用されます。ネイバーのローカルインターフェイスIDの現在の使用法は、OSPFルーター間の並列リンクを明確にすることです。したがって、アドバタイズされたローカルインターフェイスID TLVを変更すると、OSPFv2拡張リンク不透明LSA [RFC7684]でアドバタイズされる誤ったネイバーインターフェイスIDが発生し、リンクが使用されなくなる可能性があります。 OSPFルーティングドメイン[RFC5709] [RFC7474]で認証が使用されている場合、暗号化認証TLV [RFC5613]もLLSブロックの内容を保護するために使用する必要があります。
Receiving a malformed LLS Local Interface ID TLV MUST NOT result in a hard router or OSPF process failure. The reception of malformed LLS TLVs or sub-TLVs SHOULD be logged, but such logging MUST be rate-limited to prevent denial-of-service (DoS) attacks.
不正なLLSローカルインターフェイスID TLVを受信しても、ハードルーターまたはOSPFプロセスで障害が発生してはなりません。不正なLLS TLVまたはサブTLVの受信はログに記録する必要があります（SHOULD）が、そのようなログはサービス拒否（DoS）攻撃を防ぐためにレート制限する必要があります。
The Interface ID is assigned by the advertising OSPF router as a locally unique identifier and need not be unique in any broader context; it is not expected to contain any information about the device owner or traffic transiting the device, so there are no privacy concerns associated with its advertisement.
インターフェイスIDは、アドバタイズOSPFルーターによってローカルで一意の識別子として割り当てられ、より広いコンテキストで一意である必要はありません。デバイスの所有者やデバイスを通過するトラフィックに関する情報が含まれることは想定されていないため、その広告に関連するプライバシーの問題はありません。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、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、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<https://www.rfc-editor.org/info / rfc4203>。
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI 10.17487/RFC5613, August 2009, <https://www.rfc-editor.org/info/rfc5613>.
[RFC5613] Zinin、A.、Roy、A.、Nguyen、L.、Friedman、B。、およびD. Yeung、「OSPF Link-Local Signaling」、RFC 5613、DOI 10.17487 / RFC5613、2009年8月、<https： //www.rfc-editor.org/info/rfc5613>。
[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 Prefix / Link Attribute Advertisement」、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>。
[RFC8379] Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and L. Jalil, "OSPF Graceful Link Shutdown", RFC 8379, DOI 10.17487/RFC8379, May 2018, <https://www.rfc-editor.org/info/rfc8379>.
[RFC8379] Hegde、S.、Sarkar、P.、Gredler、H.、Nanduri、M。、およびL. Jalil、「OSPF Graceful Link Shutdown」、RFC 8379、DOI 10.17487 / RFC8379、2018年5月、<https：/ /www.rfc-editor.org/info/rfc8379>。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, <https://www.rfc-editor.org/info/rfc2863>.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、DOI 10.17487 / RFC2863、2000年6月、<https://www.rfc-editor.org/info/rfc2863>。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 DOI 10.17487 / RFC5709、2009年10月、<https://www.rfc-editor.org/info/rfc5709>。
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.
[RFC7474] Bhatia、M.、Hartman、S.、Zhang、D。、およびA. Lindem、編、「手動キー管理を使用する場合のOSPFv2のセキュリティ拡張」、RFC 7474、DOI 10.17487 / RFC7474、2015年4月、< https://www.rfc-editor.org/info/rfc7474>。
Acknowledgments
謝辞
Thanks to Tony Przygienda for his extensive review and useful comments.
Tony Przygiendaの広範なレビューと有益なコメントに感謝します。
Authors' Addresses
著者のアドレス
Peter Psenak (editor) Cisco Systems, Inc. Apollo Business Center Mlynske nivy 43 Bratislava 821 09 Slovakia
Peter Psenak（編集者）Cisco Systems、Inc. Apollo Business Center Mlynske nivy 43ブラチスラバ821 09スロバキア
Email: ppsenak@cisco.com
Ketan Talaulikar Cisco Systems, Inc. S.No. 154/6, Phase I, Hinjawadi Pune, Maharashtra 411 057 India
Ketan Talaulikar Cisco Systems、Inc. S.No. 154/6、Phase I、Hinjawadi Pune、Maharashtra 411 057インド
Email: ketant@cisco.com
Wim Henderickx Nokia Copernicuslaan 50 Antwerp 2018 Belgium
Wim Henderickx Nokia Copernicuslaan 50アントワープ2018ベルギー
Email: wim.henderickx@nokia.com
Padma Pillay-Esnault Huawei USA 2330 Central Expressway Santa Clara, CA 95050 United States of America
Padma Pillay-Esnault Huawei USA 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
Email: padma@huawei.com