[要約] RFC 8538は、BGP Graceful Restartのための通知メッセージのサポートに関する仕様です。このRFCの目的は、BGPルーターが再起動中にネットワークへの影響を最小限に抑えるための通知メカニズムを提供することです。
Internet Engineering Task Force (IETF) K. Patel
Request for Comments: 8538 Arrcus
Updates: 4724 R. Fernando
Category: Standards Track Cisco Systems
ISSN: 2070-1721 J. Scudder
J. Haas
Juniper Networks
March 2019
Notification Message Support for BGP Graceful Restart
BGPグレースフルリスタートの通知メッセージサポート
Abstract
概要
The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGP NOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode for BGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart.
RFC 4724で定義されているBGPグレースフルリスタートメカニズムは、BGPグレースフルリスタートの使用をBGP NOTIFICATIONメッセージ以外のBGPメッセージに制限します。このドキュメントでは、BGPスピーカーがBGP NOTIFICATIONメッセージを受信したとき、またはホールドタイムの期限が切れたときにグレースフルリスタート手順を実行できるようにする拡張機能を定義して、RFC 4724を更新します。このドキュメントでは、BGP停止通知メッセージの新しいサブコードも定義しています。この新しいサブコードは、グレースフルリスタートではなく、完全なセッションのリスタートを要求します。
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/rfc8538.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8538で入手できます。
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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Modifications to BGP Graceful Restart Capability . . . . . . 3
3. BGP Hard Reset Subcode . . . . . . . . . . . . . . . . . . . 4
3.1. Sending a Hard Reset . . . . . . . . . . . . . . . . . . 4
3.2. Receiving a Hard Reset . . . . . . . . . . . . . . . . . 4
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Rules for the Receiving Speaker . . . . . . . . . . . . . 6
5. Use of Hard Reset . . . . . . . . . . . . . . . . . . . . . . 7
5.1. When to Send a Hard Reset . . . . . . . . . . . . . . . . 7
5.2. Interaction with Other Specifications . . . . . . . . . . 7
6. Management Considerations . . . . . . . . . . . . . . . . . . 8
7. Operational Considerations . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
For many classes of errors, BGP must send a NOTIFICATION message and reset the peering session to handle the error condition. The BGP Graceful Restart mechanism defined in [RFC4724] requires that normal BGP procedures defined in [RFC4271] be followed when a NOTIFICATION message is sent or received. This document defines an extension to BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a NOTIFICATION message or the Hold Time expires. This permits the BGP speaker to avoid flapping reachability and continue forwarding while the BGP speaker restarts the session to handle errors detected in BGP.
エラーの多くのクラスでは、BGPはNOTIFICATIONメッセージを送信し、エラー状態を処理するためにピアリングセッションをリセットする必要があります。 [RFC4724]で定義されたBGPグレースフルリスタートメカニズムでは、[RFC4271]で定義された通常のBGP手順がNOTIFICATIONメッセージの送受信時に行われる必要があります。このドキュメントでは、BGPスピーカーがNOTIFICATIONメッセージを受信したとき、またはホールドタイムの期限が切れたときにグレースフルリスタート手順を実行できるようにするBGPグレースフルリスタートの拡張機能を定義します。これにより、BGPスピーカーがフラッピングの到達可能性を回避して転送を続行し、BGPスピーカーがBGPで検出されたエラーを処理するためにセッションを再開します。
At a high level, this document can be summed up as follows. When a BGP session is reset, both speakers operate as "Receiving Speakers" according to [RFC4724], meaning they retain each other's routes. This is also true for HOLDTIME expiration. The functionality can be defeated by sending a BGP Cease NOTIFICATION message with the Hard Reset subcode. If a Hard Reset is used, a full session reset is performed.
大まかに言うと、このドキュメントは次のように要約できます。 BGPセッションがリセットされると、両方のスピーカーが[RFC4724]に従って「受信スピーカー」として動作します。つまり、お互いのルートを保持します。これは、HOLDTIMEの有効期限にも当てはまります。ハードリセットサブコードを含むBGP Cease NOTIFICATIONメッセージを送信すると、機能を無効にすることができます。ハードリセットを使用すると、完全なセッションリセットが実行されます。
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]で説明されているように解釈されます。
The BGP Graceful Restart Capability is augmented to signal the Graceful Restart support for BGP NOTIFICATION messages. The Restart Flags field is augmented as follows (following the diagram in Section 3 of [RFC4724]).
BGPグレースフルリスタート機能は、BGP NOTIFICATIONメッセージのグレースフルリスタートサポートを通知するように拡張されています。 [再起動フラグ]フィールドは次のように拡張されています（[RFC4724]のセクション3の図に従います）。
Restart Flags:
再起動フラグ：
This field contains bit flags relating to restart.
このフィールドには、再起動に関連するビットフラグが含まれます。
0 1 2 3
+-+-+-+-+
|R|N| |
+-+-+-+-+
The most significant bit is defined in [RFC4724] as the Restart State ("R") bit.
最上位ビットは、[RFC4724]で再起動状態（ "R"）ビットとして定義されています。
The second most significant bit is defined in this document as the Graceful Notification ("N") bit. It is used to indicate Graceful Restart support for BGP NOTIFICATION messages. A BGP speaker indicates support for the procedures in this document by advertising a Graceful Restart Capability with its "N" bit set (value 1).
このドキュメントでは、2番目に重要なビットをグレースフル通知（ "N"）ビットと定義しています。これは、BGP NOTIFICATIONメッセージのグレースフルリスタートサポートを示すために使用されます。 BGPスピーカーは、「N」ビットセット（値1）でグレースフルリスタート機能をアドバタイズすることにより、このドキュメントの手順のサポートを示します。
If a BGP speaker that previously advertised a given set of Graceful Restart parameters opens a new session with a different set of parameters, these new parameters apply once the session has transitioned into ESTABLISHED state.
グレースフルリスタートパラメーターの特定のセットを以前にアドバタイズしたBGPスピーカーが別のパラメーターセットで新しいセッションを開く場合、セッションがESTABLISHED状態に移行すると、これらの新しいパラメーターが適用されます。
This document defines a new subcode for BGP Cease NOTIFICATION messages, called the Hard Reset subcode. The value of this subcode is discussed in Section 8. In this document, a BGP Cease NOTIFICATION message with the Hard Reset subcode is referred to as a "Hard Reset message" or simply as a "Hard Reset".
このドキュメントでは、ハードリセットサブコードと呼ばれる、BGP中止通知メッセージの新しいサブコードを定義します。このサブコードの値については、セクション8で説明します。このドキュメントでは、ハードリセットサブコードを含むBGP停止通知メッセージを「ハードリセットメッセージ」または単に「ハードリセット」と呼びます。
When the "N" bit has been exchanged by two peers, NOTIFICATION messages other than Hard Reset messages are referred to as "Graceful", since such messages invoke Graceful Restart semantics.
「N」ビットが2つのピアによって交換された場合、ハードリセットメッセージ以外のNOTIFICATIONメッセージは「グレースフル」と呼ばれます。これは、このようなメッセージがグレースフルリスタートセマンティクスを呼び出すためです。
When the "N" bit has been exchanged, a Hard Reset message is used to indicate to the peer that the session is to be fully terminated.
「N」ビットが交換されると、ハードリセットメッセージを使用して、セッションが完全に終了することをピアに示します。
When sending a Hard Reset, the data portion of the NOTIFICATION message is encoded as follows:
ハードリセットを送信する場合、NOTIFICATIONメッセージのデータ部分は次のようにエンコードされます。
+--------+--------+--------
| ErrCode| Subcode| Data
+--------+--------+--------
ErrCode is a BGP Error Code (as documented in the IANA "BGP Error (Notification) Codes" registry) that indicates the reason for the Hard Reset. Subcode is a BGP Error Subcode (as documented in the IANA "BGP Error Subcodes" registry) as appropriate for the ErrCode. Similarly, Data is as appropriate for the ErrCode and Subcode. In short, the Hard Reset encapsulates another NOTIFICATION message in its data portion.
ErrCodeは、ハードリセットの理由を示すBGPエラーコードです（IANAの「BGPエラー（通知）コード」レジストリに記載されています）。サブコードは、ErrCodeに適したBGPエラーサブコードです（IANAの「BGPエラーサブコード」レジストリに記載されています）。同様に、データはErrCodeとサブコードに適切です。つまり、ハードリセットは、データ部分に別のNOTIFICATIONメッセージをカプセル化します。
Whenever a BGP speaker receives a Hard Reset, the speaker MUST terminate the BGP session following the standard procedures in [RFC4271].
BGPスピーカーがハードリセットを受信するたびに、スピーカーは[RFC4271]の標準手順に従ってBGPセッションを終了する必要があります。
A BGP speaker that is willing to receive and send BGP NOTIFICATION messages according to the procedures of this document MUST advertise the "N" bit using the Graceful Restart Capability as defined in [RFC4724].
このドキュメントの手順に従ってBGP NOTIFICATIONメッセージを送受信するBGPスピーカーは、[RFC4724]で定義されているグレースフルリスタート機能を使用して「N」ビットをアドバタイズする必要があります。
When such a BGP speaker has received the "N" bit from its peer, and receives from that peer a BGP NOTIFICATION message other than a Hard Reset, it MUST follow the rules for the Receiving Speaker mentioned in Section 4.1. The BGP speaker generating the BGP NOTIFICATION message MUST also follow the rules for the Receiving Speaker.
そのようなBGPスピーカーがそのピアから「N」ビットを受信し、そのピアからハードリセット以外のBGP NOTIFICATIONメッセージを受信した場合、セクション4.1で説明した受信スピーカーのルールに従う必要があります。 BGP NOTIFICATIONメッセージを生成するBGPスピーカーも、受信スピーカーのルールに従う必要があります。
When a BGP speaker resets its session due to a HOLDTIME expiry, it should generate the relevant BGP NOTIFICATION message as mentioned in [RFC4271] but subsequently MUST follow the rules for the Receiving Speaker mentioned in Section 4.1.
BGPスピーカーがHOLDTIMEの期限切れのためにセッションをリセットすると、[RFC4271]で述べられているように、関連するBGP NOTIFICATIONメッセージを生成する必要がありますが、セクション4.1で述べられている受信スピーカーのルールに従う必要があります。
A BGP speaker SHOULD NOT send a Hard Reset to a peer from which it has not received the "N" bit. We note, however, that if it did so, the effect would be as desired in any case because, according to [RFC4271] and [RFC4724], any NOTIFICATION message, whether recognized or not, results in a session reset. Thus, the only negative effect to be expected from sending the Hard Reset to a peer that hasn't advertised compliance to this specification would be that the peer would be unable to properly log the associated information.
BGPスピーカーは、「N」ビットを受信していないピアにハードリセットを送信しないでください。ただし、そうした場合、[RFC4271]および[RFC4724]によると、NOTIFICATIONメッセージは認識されたかどうかに関係なくセッションがリセットされるため、どのような場合でも効果は期待どおりです。したがって、この仕様への準拠を通知していないピアにハードリセットを送信することで予想される唯一のマイナスの影響は、ピアが関連情報を適切に記録できないことです。
Once the session is re-established, both BGP speakers SHOULD set their Forwarding State bit to 1. If the Forwarding State bit is not set, then, according to the procedures in Section 4.2 of [RFC4724], the relevant routes will be flushed, defeating the goals of this specification.
セッションが再確立されると、両方のBGPスピーカーは転送状態ビットを1に設定する必要があります（SHOULD）。転送状態ビットが設定されていない場合、[RFC4724]のセクション4.2の手順に従って、関連するルートがフラッシュされます。この仕様の目標を打ち破る。
Section 4.2 of [RFC4724] defines rules for the Receiving Speaker. This document modifies those rules as follows:
[RFC4724]のセクション4.2は、受信スピーカーのルールを定義しています。このドキュメントでは、これらのルールを次のように変更します。
The sentence "To deal with possible consecutive restarts, a route (from the peer) previously marked as stale MUST be deleted" only applies when the "N" bit has not been exchanged with the peer:
「可能な連続した再起動に対処するには、以前に失効としてマークされた（ピアからの）ルートを削除する必要があります」という文は、「N」ビットがピアと交換されていない場合にのみ適用されます。
OLD: When the Receiving Speaker detects termination of the TCP session for a BGP session with a peer that has advertised the Graceful Restart Capability, it MUST retain the routes received from the peer for all the address families that were previously received in the Graceful Restart Capability and MUST mark them as stale routing information. To deal with possible consecutive restarts, a route (from the peer) previously marked as stale MUST be deleted. The router MUST NOT differentiate between stale and other routing information during forwarding.
OLD：受信スピーカーが、グレースフルリスタート機能をアドバタイズしたピアとのBGPセッションのTCPセッションの終了を検出すると、以前にグレースフルリスタート機能で受信されたすべてのアドレスファミリのピアから受信したルートを保持する必要がありますそしてそれらを古いルーティング情報としてマークしなければなりません。起こり得る連続した再起動に対処するには、以前に失効としてマークされた（ピアからの）ルートを削除する必要があります。ルーターは、転送中に古い情報と他のルーティング情報を区別してはなりません（MUST NOT）。
NEW: When the Receiving Speaker detects termination of the TCP session for a BGP session with a peer that has advertised the Graceful Restart Capability, it MUST retain the routes received from the peer for all the address families that were previously received in the Graceful Restart Capability and MUST mark them as stale routing information. The router MUST NOT differentiate between stale and other routing information during forwarding. If the "N" bit has not been exchanged with the peer, then to deal with possible consecutive restarts, a route (from the peer) previously marked as stale MUST be deleted.
新規：グレースフルリスタート機能をアドバタイズしたピアとのBGPセッションのTCPセッションの終了を受信スピーカーが検出すると、以前にグレースフルリスタート機能で受信したすべてのアドレスファミリのピアから受信したルートを保持する必要がありますそしてそれらを古いルーティング情報としてマークしなければなりません。ルーターは、転送中に古い情報と他のルーティング情報を区別してはなりません（MUST NOT）。 「N」ビットがピアと交換されていない場合、可能な連続した再起動に対処するために、以前に失効としてマークされた（ピアからの）ルートを削除する必要があります。
The stale timer is given a formal name and made mandatory:
古いタイマーには正式な名前が付けられ、必須になっています。
OLD: To put an upper bound on the amount of time a router retains the stale routes, an implementation MAY support a (configurable) timer that imposes this upper bound.
OLD：ルーターが古いルートを保持する時間に上限を設けるために、実装はこの上限を課す（構成可能な）タイマーをサポートしてもよい（MAY）。
NEW: To put an upper bound on the amount of time a router retains the stale routes, an implementation MUST support a (configurable) timer, called the "stale timer", that imposes this upper bound. A suggested default value for the stale timer is 180 seconds. An implementation MAY provide the option to disable the timer (i.e., to provide an infinite retention time) but MUST NOT do so by default.
新規：ルーターが古いルートを保持する時間に上限を設けるために、実装は、「古いタイマー」と呼ばれる（構成可能な）タイマーをサポートしなければならず、この上限を課します。古いタイマーの推奨デフォルト値は180秒です。実装は、タイマーを無効にするオプションを提供する場合があります（つまり、無期限の保持時間を提供する場合があります）が、デフォルトではこれを行わないでください。
Although when to send a Hard Reset is an implementation-specific decision, we offer some advice. Many Cease NOTIFICATION subcodes represent permanent or long-term, rather than transient, session termination. Because of this, it's appropriate to use Hard Reset with them. As of publication of this document, subcodes 1-9 have been defined for Cease. The following table lists each of these subcodes along with suggested behavior.
ハードリセットを送信するタイミングは実装固有の決定ですが、いくつかのアドバイスを提供します。多くの停止通知サブコードは、一時的ではなく永続的または長期的なセッション終了を表します。このため、ハードリセットを一緒に使用するのが適切です。このドキュメントの公開時点で、サブコード1〜9がCeaseに定義されています。次の表に、これらの各サブコードと推奨される動作を示します。
+-------+------------------------------------+----------------------+
| Value | Name | Suggested Behavior |
+-------+------------------------------------+----------------------+
| 1 | Maximum Number of Prefixes Reached | Hard Reset |
| 2 | Administrative Shutdown | Hard Reset |
| 3 | Peer De-configured | Hard Reset |
| 4 | Administrative Reset | Provide user control |
| 5 | Connection Rejected | Graceful Cease |
| 6 | Other Configuration Change | Graceful Cease |
| 7 | Connection Collision Resolution | Graceful Cease |
| 8 | Out of Resources | Graceful Cease |
| 9 | Hard Reset | Hard Reset |
+-------+------------------------------------+----------------------+
These suggestions are only that -- suggestions, not requirements. It's the nature of BGP implementations that the mapping of internal states to BGP NOTIFICATION codes and subcodes is not always perfect. The guiding principle for the implementor should be that if there is no realistic hope that forwarding can continue or that the session will be re-established within the deadline, Hard Reset should be used.
これらの提案はそれだけです-要件ではなく提案です。内部状態のBGP NOTIFICATIONコードおよびサブコードへのマッピングが常に完全であるとは限らないのは、BGP実装の性質です。実装者の指針となる原則は、転送を続行できるという現実的な希望がない場合、またはセッションが期限内に再確立される場合は、ハードリセットを使用することです。
For all NOTIFICATION codes other than Cease, use of Hard Reset does not appear to be indicated.
中止以外のすべての通知コードでは、ハードリセットの使用は示されません。
"BGP Administrative Shutdown Communication" [RFC8203] specifies use of the data portion of the Administrative Shutdown or Administrative Reset subcodes to convey a short message. When [RFC8203] is used in conjunction with Hard Reset, the subcode of the outermost Cease MUST be Hard Reset, with the Administrative Shutdown or Administrative Reset subcodes encapsulated within. The encapsulated message MUST subsequently be processed according to [RFC8203].
「BGP管理シャットダウン通信」[RFC8203]は、管理シャットダウンまたは管理リセットサブコードのデータ部分を使用してショートメッセージを伝えることを指定しています。 [RFC8203]をハードリセットと組み合わせて使用する場合、最も外側の停止のサブコードはハードリセットでなければならず、管理シャットダウンまたは管理リセットサブコードがカプセル化されている必要があります。カプセル化されたメッセージはその後[RFC8203]に従って処理されなければならない（MUST）。
When reporting a Hard Reset to network management, the error code and subcode reported MUST be Cease and Hard Reset, respectively. If the network management layer in use permits it, the information carried in the Data portion SHOULD be reported as well.
ハードリセットをネットワーク管理に報告する場合、報告されるエラーコードとサブコードはそれぞれ停止とハードリセットでなければなりません。使用中のネットワーク管理層で許可されている場合は、データ部分に含まれる情報も報告する必要があります（SHOULD）。
Note that long (or infinite) retention time may cause operational issues and should be enabled with care.
保持時間が長い（または無限である）と、操作上の問題が発生する可能性があるため、注意して有効にする必要があります。
IANA has assigned subcode 9 ("Hard Reset") in the "BGP Cease NOTIFICATION message subcodes" registry.
IANAは、「BGP中止通知メッセージサブコード」レジストリでサブコード9（「ハードリセット」）を割り当てました。
IANA has created a sub-registry called "BGP Graceful Restart Flags" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedure is Standards Action [RFC8126]; this document and [RFC4724] are listed as references. The initial values are as follows:
IANAは、「Border Gateway Protocol（BGP）Parameters」レジストリの下に「BGP Graceful Restart Flags」と呼ばれるサブレジストリを作成しました。登録手順は標準アクション[RFC8126]です。このドキュメントと[RFC4724]は参照としてリストされています。初期値は次のとおりです。
+--------------+---------------+------------+-----------+
| Bit Position | Name | Short Name | Reference |
+--------------+---------------+------------+-----------+
| 0 | Restart State | R | RFC 4724 |
| 1 | Notification | N | RFC 8538 |
| 2-3 | Unassigned | | |
+--------------+---------------+------------+-----------+
IANA has created a sub-registry called "BGP Graceful Restart Flags for Address Family" under the "Border Gateway Protocol (BGP) Parameters" registry. The registration procedure is Standards Action; this document and [RFC4724] are listed as references. The initial values are as follows:
IANAは、「Border Gateway Protocol（BGP）Parameters」レジストリの下に「BGP Graceful Restart Flags for Address Family」と呼ばれるサブレジストリを作成しました。登録手続きは標準アクションです。このドキュメントと[RFC4724]は参照としてリストされています。初期値は次のとおりです。
+--------------+------------------+------------+-----------+
| Bit Position | Name | Short Name | Reference |
+--------------+------------------+------------+-----------+
| 0 | Forwarding State | F | RFC 4724 |
| 1-7 | Unassigned | | |
+--------------+------------------+------------+-----------+
This specification doesn't change the basic security model inherent in [RFC4724], with the exception that the protection against repeated resets is relaxed. To mitigate the consequent risk that an attacker could use repeated session resets to prevent stale routes from ever being deleted, we make the stale timer mandatory (in practice, it is already ubiquitous). To the extent [RFC4724] might be said to help defend against denials of service by making the control plane more resilient, this extension may modestly increase that resilience; however, there are enough confounding and deployment-specific factors that no general claims can be made.
この仕様は、[RFC4724]に固有の基本的なセキュリティモデルを変更しませんが、繰り返しのリセットに対する保護が緩和されている点が異なります。攻撃者が繰り返しセッションリセットを使用して古いルートが削除されるのを防ぐことができるという結果的なリスクを軽減するために、古いタイマーを必須にします（実際には、すでに至る所にあります）。 [RFC4724]がコントロールプレーンの回復力を高めることにより、サービス拒否攻撃からの防御に役立つと言えるかもしれませんが、この拡張はその回復力を適度に高める可能性があります。ただし、一般的な主張を行うことができないほど、交絡および配置固有の要素が十分にあります。
[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>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <https://www.rfc-editor.org/info/rfc4724>.
[RFC4724] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPのグレースフルリスタートメカニズム」、RFC 4724、DOI 10.17487 / RFC4724、2007年1月、<https： //www.rfc-editor.org/info/rfc4724>。
[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>。
[RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP Administrative Shutdown Communication", RFC 8203, DOI 10.17487/RFC8203, July 2017, <https://www.rfc-editor.org/info/rfc8203>.
[RFC8203] Snijders、J.、Heitz、J。、およびJ. Scudder、「BGP管理シャットダウン通信」、RFC 8203、DOI 10.17487 / RFC8203、2017年7月、<https://www.rfc-editor.org/info / rfc8203>。
[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>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Acknowledgements
謝辞
The authors would like to thank Jim Uttaro for the suggestion. The authors would also like to thank Emmanuel Baccelli, Bruno Decraene, Chris Hall, Warren Kumari, Paul Mattes, Robert Raszuk, and Alvaro Retana for their reviews and comments.
著者は提案のためにジム・ウッタロに感謝したいと思います。著者は、レビューとコメントを提供してくれたEmmanuel Baccelli、Bruno Decraene、Chris Hall、Warren Kumari、Paul Mattes、Robert Raszuk、およびAlvaro Retanaにも感謝します。
Authors' Addresses
著者のアドレス
Keyur Patel Arrcus
キールパテルが再発
Email: keyur@arrcus.com
Rex Fernando Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States of America
Rex Fernando Cisco Systems 170 W. Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: rex@cisco.com
John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America
John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089アメリカ合衆国
Email: jgs@juniper.net
Jeff Haas Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America
Jeff Haas Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089アメリカ合衆国
Email: jhaas@juniper.net