[要約] RFC 4781は、BGPとMPLSのための優雅な再起動メカニズムに関する仕様です。このRFCの目的は、ネットワークの再起動時にBGPとMPLSのセッションを維持し、サービスの中断を最小限に抑えることです。
Network Working Group Y. Rekhter
Request for Comments: 4781 R. Aggarwal
Category: Standards Track Juniper Networks
January 2007
Graceful Restart Mechanism for BGP with MPLS
MPLSを使用したBGPの優雅な再起動メカニズム
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2007).
Copyright（c）The Internet Society（2007）。
Abstract
概要
A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.
BGPの再起動によって引き起こされるルーティングへの負の影響を最小限に抑えるのに役立つBGPのメカニズムはすでに開発されており、別のドキュメント（「BGPの優雅な再起動メカニズム」）で説明されています。このドキュメントは、このメカニズムを拡張して、ラベルスイッチングルーター（LSRの）コントロールプレーンの再起動によって引き起こされるMPLS転送への負の影響を最小限に抑え、特にBGPがMPLSラベルを運ぶために使用され、LSRがLSRを保持する場合のBGPコンポーネントの再起動によって特に最小限に抑えることができます。再起動全体でMPLS転送状態。
The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.).
このドキュメントに記載されているメカニズムは、BGPネットワーク層の到達可能性情報（NLRI）フィールドにあるアドレスのタイプに関して不可知論者です。そのため、BGP（例：IPv4、IPv6など）で運ばれる可能性のあるアドレスファミリのいずれかと組み合わせて機能します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. General Requirements ............................................3
3. Capability Advertisement ........................................4
4. Procedures for the Restarting LSR ...............................4
4.1. Case 1 .....................................................4
4.2. Case 2 .....................................................5
4.3. Case 3 .....................................................5
5. Alternative Procedures for the Restarting LSR ...................6
6. Procedures for a Neighbor of a Restarting LSR ...................6
7. Comparison between Alternative Procedures for the
Restarting LSR ..................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
In the case where a Label Switching Router (LSR) could preserve its MPLS forwarding state across restart of its control plane, and specifically its BGP component, and BGP is used to carry MPLS labels (e.g., as specified in [RFC3107]), it may be desirable not to perturb the LSPs going through that LSR (and specifically, the LSPs established by BGP) after failure or restart of the BGP component of the control plane. In this document, we describe a mechanism that allows this goal to be accomplished. The mechanism described in this document works in conjunction with the mechanism specified in [RFC4724]. The mechanism described in this document places no restrictions on the types of addresses (address families) that it can support.
ラベルスイッチングルーター（LSR）がコントロールプレーン、特にBGPコンポーネントの再起動全体にMPLS転送状態を保持できる場合、BGPはMPLSラベルを運ぶために使用されます（[RFC3107]で指定されているように）、コントロールプレーンのBGPコンポーネントを故障または再起動した後、LSP（および具体的にはBGPによって確立されたLSP）を通過するLSPを摂動しないことが望ましい場合があります。このドキュメントでは、この目標を達成できるメカニズムについて説明します。このドキュメントで説明されているメカニズムは、[RFC4724]で指定されたメカニズムと組み合わせて機能します。このドキュメントで説明されているメカニズムは、サポートできるアドレス（アドレスファミリ）の種類に制限を設けません。
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during BGP restart and those without it (although the latter need to implement only a subset of this mechanism). Supporting a subset of the mechanism described here by the LSRs that cannot preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart. However, the impact would be minimized if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane, and if they implement the mechanism described here. The subset includes all the procedures described in this document, except the procedures in Sections 4.1, 4.2, 4.3, and 5.
このドキュメントで説明されているメカニズムは、すべてのLSRに適用されます。両方とも、BGP再起動中に転送状態を保存する能力を持つものと、それなしのもの（後者はこのメカニズムのサブセットのみを実装する必要があります）。再起動全体でMPLS転送状態を保存できないLSRによってここで説明されているメカニズムのサブセットをサポートしても、コントロールプレーンの再起動によって引き起こされるMPLSトラフィックへのマイナスの影響は減りません。ただし、隣人がコントロールプレーンの再起動全体で転送状態を保存できる場合、およびここで説明するメカニズムを実装する場合、影響は最小限に抑えられます。サブセットには、セクション4.1、4.2、4.3、および5の手順を除き、このドキュメントで説明されているすべての手順が含まれています。
For the sake of brevity, by "MPLS forwarding state" we mean one of
the following mappings:
<incoming label -> (outgoing label, next hop)>
<Forwarding Equivalence Class (FEC) -> (outgoing label, next hop)>
<incoming label -> label pop, next hop>
<incoming label, label pop>
In the context of this document, the forwarding state that is referred to in [RFC4724] means MPLS forwarding state, as defined above. The term "next hop" refers to the next hop as advertised in BGP.
このドキュメントのコンテキストでは、[RFC4724]で言及されている転送状態は、上記で定義されているように、MPLS転送状態を意味します。「次のホップ」という用語は、BGPで宣伝されている次のホップを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
First of all, an LSR MUST implement the Graceful Restart Mechanism for BGP, as specified in [RFC4724]. Second, the LSR SHOULD be capable of preserving its MPLS forwarding state across the restart of its control plane (including the restart of BGP). Third, for the <Forwarding Equivalence Class (FEC) -> label> bindings distributed via BGP, the LSR SHOULD be able either (a) to reconstruct the same bindings as the LSR had prior to the restart (see Section 4), or (b) to create new <FEC -> label> bindings after restart, while temporarily maintaining MPLS forwarding state corresponding to both the bindings prior to the restart, as well as to the newly created bindings (see Section 5). Fourth, as long as the LSR retains the MPLS forwarding state that the LSR preserved across the restart, the labels from that state cannot be used to create new local label bindings (but could be used to reconstruct the existing bindings, as per procedures in Section 4). Finally, for each next hop, if the next hop is reachable via a Label Switched Path (LSP), then the restarting LSR MUST be able to preserve the MPLS forwarding state associated with that LSP across the restart.
まず、[RFC4724]で指定されているように、LSRはBGPの優雅な再起動メカニズムを実装する必要があります。第二に、LSRは、コントロールプレーンの再起動（BGPの再起動を含む）全体でMPLS転送状態を保存できる必要があります。第三に、<転送等価クラス（FEC） - >ラベル> BGPを介して配布されたバインディングの場合、LSRは（a）再起動前にLSRが持っていたのと同じバインディングを再構築することができるはずです（セクション4を参照）、または（b）再起動後に新しい<fec-> label>バインディングを作成し、再起動前の両方のバインディングと新しく作成されたバインディングに対応するMPLS転送状態を一時的に維持します（セクション5を参照）。第4に、LSRが再起動全体に保存されているLSRがMPLS転送状態を保持する限り、その状態からのラベルを使用して新しいローカルラベルバインディングを作成することはできません（ただし、セクションの手順に従って、既存のバインディングを再構築するために使用できます。4）。最後に、次のホップごとに、次のホップがラベルスイッチ付きパス（LSP）を介して到達可能な場合、再起動LSRは、再起動全体でそのLSPに関連付けられたMPLS転送状態を保持できる必要があります。
In the scenario where label binding on an LSR is created/maintained not only by the BGP component of the control plane, but also by other protocol components (e.g., LDP, RSVP-TE), and where the LSR supports restart of the individual components of the control plane that create/maintain label binding (e.g., restart of BGP, but no restart of LDP), the LSR MUST be able to preserve across the restart the information about which protocol has assigned which labels.
LSRでのラベル結合が制御プレーンのBGPコンポーネントだけでなく、他のプロトコルコンポーネント（LDP、RSVP-TEなど）によっても作成/維持されるシナリオでは、LSRが個々のコンポーネントの再起動をサポートする場合ラベルバインディング（たとえば、BGPの再起動がLDPの再起動はない）を作成/維持するコントロールプレーンの場合、LSRは、どのプロトコルがどのラベルを割り当てたかについての情報を再起動して保存できる必要があります。
After the LSR restarts, it MUST follow the procedures as specified in [RFC4724]. In addition, if the LSR is able to preserve its MPLS forwarding state across the restart, the LSR SHOULD advertise this to its neighbors by appropriately setting the Flag for Address Family field in the Graceful Restart Capability for all applicable AFI/SAFI pairs.
LSRが再起動した後、[RFC4724]で指定されている手順に従う必要があります。さらに、LSRが再起動全体でMPLS転送状態を保持できる場合、LSRは、適用されるすべてのAFI/SAFIペアの優雅な再起動機能に住所ファミリーフィールドのフラグを適切に設定することにより、近隣にこれを宣伝する必要があります。
An LSR that supports the mechanism described in this document advertises this to its peer by using the Graceful Restart Capability, as specified in [RFC4724]. The Subsequent Address Family Identifier (SAFI) in the advertised capability MUST indicate that the Network Layer Reachability Information (NLRI) field carries not only addressing Information, but also labels (see [RFC3107] for an example of where NLRI carries labels).
このドキュメントで説明されているメカニズムをサポートするLSRは、[RFC4724]で指定されているように、優雅な再起動機能を使用して、これをピアに宣伝します。宣伝された機能の後続のアドレスファミリ識別子（SAFI）は、ネットワークレイヤーリーチ可能性情報（NLRI）フィールドが情報に対処するだけでなく、ラベルも搭載していることを示している必要があります（NLRIがラベルを持っている場所の例については[RFC3107]を参照）。
Procedures in this section apply when a restarting LSR is able to reconstruct the same <FEC -> label> bindings as the LSR had prior to the restart.
このセクションの手順は、再起動LSRが再起動前と同じ<FEC->ラベル>バインディングを再構築できる場合に適用されます。
The procedures described in this section are conceptual and do not have to be implemented precisely as described, as long as the implementations support the described functionality and their externally visible behavior is the same.
このセクションで説明されている手順は概念的であり、説明されているように正確に実装する必要はありません。実装が説明されている機能をサポートし、外部から表示される動作が同じである限り。
Once the LSR completes its route selection (as specified in Section 4.1, "Procedures for the Restarting Speaker", of [RFC4724]), then in addition to the those procedures, the LSR performs one of the following:
LSRがルートの選択を完了すると（セクション4.1で指定されているように、[RFC4724]の「スピーカーの再起動手順」）、これらの手順に加えて、LSRは次のいずれかを実行します。
The following applies when (a) the best route selected by the LSR was received with a label, (b) that label is not an Implicit NULL, and (c) the LSR advertises this route with itself as the next hop.
（a）LSRによって選択された最良のルートがラベルで受信された場合、（b）そのラベルは暗黙のヌルではなく、（c）LSRは次のホップとしてこのルートを宣伝している場合に適用されます。
In this case, the LSR searches its MPLS forwarding state (the one preserved across the restart) for an entry with <outgoing label, next hop> equal to the one in the received route. If such an entry is found, the LSR no longer marks the entry as stale. In addition, if the entry is of type <incoming label, (outgoing label, next hop)> rather than <Forwarding Equivalence Class (FEC), (outgoing label, next hop)>, the LSR uses the incoming label from the entry when advertising the route to its neighbors. If the found entry has no incoming label, or if no such entry is found, the LSR allocates a new label when advertising the route to its neighbors (assuming that there are neighbors to which the LSR has to advertise the route with a label).
この場合、LSRは、MPLS転送状態（再起動全体に保存されているもの）を検索します。そのようなエントリが見つかった場合、LSRはもはやエントリを古くマークしません。さらに、エントリがタイプ<受信ラベル（発信ラベル、次のホップ）> <<転送等価クラス（FEC）、（発信ラベル、次のホップ）>ではなく、LSRがエントリの着信ラベルを使用します。隣人へのルートを宣伝します。発見されたエントリに着信ラベルがない場合、またはそのようなエントリが見つからない場合、LSRは近隣へのルートを宣伝するときに新しいラベルを割り当てます（LSRがラベルでルートを宣伝しなければならない近隣があると仮定します）。
The following applies when (a) the best route selected by the LSR was received either without a label, with an Implicit NULL label, or the route is originated by the LSR; (b) the LSR advertises this route with itself as the next hop; and (c) the LSR has to generate a (non-Implicit NULL) label for the route.
（a）LSRによって選択された最良のルートが、暗黙のヌルラベルを使用してラベルなしで受信されたか、ルートがLSRによって発信される場合に適用されます。（b）LSRは、次のホップとして自分自身でこのルートを宣伝しています。（c）LSRは、ルートの（非インプリティヌル）ラベルを生成する必要があります。
In this case, the LSR searches its MPLS forwarding state for an entry that indicates that the LSR has to perform label pop, and the next hop equal to the next hop of the route in consideration. If such an entry is found, then the LSR uses the incoming label from the entry when advertising the route to its neighbors. If no such entry is found, the LSR allocates a new label when advertising the route to its neighbors.
この場合、LSRはMPLS転送状態を検索して、LSRがラベルPOPを実行する必要があることを示すエントリを検索し、次のホップは検討中のルートの次のホップに等しくなります。そのようなエントリが見つかった場合、LSRは近隣へのルートを宣伝するときにエントリから着信ラベルを使用します。そのようなエントリが見つからない場合、LSRは隣人へのルートを宣伝するときに新しいラベルを割り当てます。
The description in the above paragraph assumes that the LSR generates the same label for all the routes with the same next hop. If this is not the case and the LSR generates a unique label per each such route, then the LSR needs to preserve across the restart not only <incoming label, (outgoing label, next hop)> mapping, but also the Forwarding Equivalence Class (FEC) associated with this mapping. In such a case the LSR would search its MPLS forwarding state for an entry that (a) indicates label pop (means no outgoing label), (b) indicates that the next hop equal to the next hop of the route, and (c) has the same FEC as the route. If such an entry is found, then the LSR uses the incoming label from the entry when advertising the route to its neighbors. If no such entry is found, the LSR allocates a new label when advertising the route to its neighbors.
上記の段落の説明は、LSRが同じ次のホップですべてのルートに対して同じラベルを生成すると仮定しています。これが当てはまらない場合、LSRがそのようなルートごとに一意のラベルを生成する場合、LSRは<受信ラベルだけでなく（発信ラベル、次のホップ）>マッピングだけでなく、転送等価クラス（等価クラス）を再起動するだけでなく、再起動を維持する必要があります。FEC）このマッピングに関連付けられています。そのような場合、LSRは、（a）ラベルPOP（発信ラベルがないことを意味する）を示すエントリをMPLS転送状態を検索します（b）次のホップがルートの次のホップに等しいことを示し、（c）ルートと同じFECがあります。そのようなエントリが見つかった場合、LSRは近隣へのルートを宣伝するときにエントリから着信ラベルを使用します。そのようなエントリが見つからない場合、LSRは隣人へのルートを宣伝するときに新しいラベルを割り当てます。
The following applies when the LSR does not set BGP next hop to self.
LSRがBGPを次に自己に設定しない場合、以下が適用されます。
In this case, the LSR, when advertising its best route for a particular NLRI, just uses the label that was received with that route. And if the route was received with no label, the LSR advertises the route with no label as well. Either way, the LSR does not allocate a label for that route.
この場合、LSRは、特定のNLRIに最適なルートを宣伝するとき、そのルートで受信されたラベルを使用します。また、ルートがラベルなしで受信された場合、LSRはラベルのないルートを宣伝します。いずれにせよ、LSRはそのルートのラベルを割り当てません。
In this section, we describe an alternative to the procedures described in Section "Procedures for the restarting LSR".
このセクションでは、セクション「LSRの再起動手順」で説明されている手順に代わるものについて説明します。
Procedures in this section apply when a restarting LSR does not reconstruct the same <FEC -> label> bindings as the LSR had prior to the restart, but instead creates new <FEC -> label> bindings after restart, while temporarily maintaining MPLS forwarding state corresponding to both the bindings prior to the restart, as well as to the newly created bindings.
このセクションの手順は、LSRの再起動が再起動前と同じ<fec-> label>バインディングを再構築しない場合に適用され、代わりにMPLS転送状態を一時的に維持しながら、再起動後に新しい<fec->ラベル>バインディングを作成します。再起動前の両方のバインディングと、新しく作成されたバインディングに対応します。
The procedures described in this section require that for the use by BGP graceful restart, the LSR SHOULD have (at least) as many unallocated labels as labels allocated for the <FEC -> label> bindings distributed by BGP. The latter forms the MPLS forwarding state that the LSR managed to preserve across the restart. The former is used for allocating labels after the restart.
このセクションで説明した手順では、BGPの優雅な再起動による使用のために、LSRには、BGPが分布する<FEC->ラベル>バインディングに割り当てられたラベルと同じくらい多くの未割り当てラベルが必要です。後者は、LSRが再起動全体に保存したというMPLS転送状態を形成します。前者は、再起動後のラベルの割り当てに使用されます。
To create (new) local label bindings after the restart, the LSR uses unallocated labels (this is pretty much the normal procedure).
（新しい）ローカルラベルバインディングを再起動後に作成するには、LSRは未成年のラベルを使用します（これはほぼ通常の手順です）。
The LSR SHOULD retain the MPLS forwarding state that the LSR preserved across the restart at least until the LSR sends an End-of-RIB marker to all of its neighbors (by that time the LSR already completed its route selection process, and also advertised its Adj-RIB-Out to its neighbors). The LSR MAY retain the forwarding state even a bit longer (the amount of extra time MAY be controlled by configuration on the LSR), so as to allow the neighbors to receive and process the routes that have been advertised by the LSR. After that, the LSR SHOULD delete the MPLS forwarding state that it preserved across the restart.
LSRは、少なくともLSRがすべての近隣にRIBの終了マーカーを送信するまで、LSRが少なくとも再起動全体に保存されているというMPLS転送状態を保持する必要があります（その時までに、LSRはすでにルート選択プロセスを完了し、その宣伝も宣伝しました隣人へのadj-rib-out）。LSRは、近隣がLSRによって宣伝されているルートを受け取り、処理できるように、フォワード状態をもう少し長く保持する場合があります（LSRの構成によって制御される可能性があります）。その後、LSRは、再起動全体に保存されているMPLS転送状態を削除する必要があります。
Note that while an LSR is in the process of restarting, the LSR may have not one, but two local label bindings for a given BGP route -- one that was retained from prior to restart, and another that was created after the restart. Once the LSR completes its restart, the former will be deleted. However, both of these bindings would have the same outgoing label (and the same next hop).
LSRが再起動の過程にある間、LSRには1つではなく、特定のBGPルートの2つのローカルラベルバインディングがある可能性があります。LSRが再起動を完了すると、前者は削除されます。ただし、これらのバインディングの両方に同じ発信ラベル（および同じ次のホップ）があります。
The neighbor of a restarting LSR (the receiving router terminology used in [RFC4724]) follows the procedures specified in [RFC4724]. In addition, the neighbor treats the MPLS labels received from the restarting LSR the same way that it treats the routes received from the restarting LSR (both prior and after the restart).
再起動LSRの隣人（[RFC4724]で使用される受信ルーター用語）は、[RFC4724]で指定された手順に従います。さらに、近隣は、再起動LSRから受信したMPLSラベルを、再起動LSRから受け取ったルートを処理するのと同じ方法で処理します（再起動前と再起動後）。
Replacing the stale routes by the routing updates received from the restarting LSR involves replacing/updating the appropriate MPLS labels.
LSRの再起動から受信したルーティングの更新で古いルートを置き換えるには、適切なMPLSラベルの交換/更新が含まれます。
In addition, if the Flags in the Graceful Restart Capability received from the restarting LSR indicate that the LSR wasn't able to retain its MPLS state across the restart, the neighbor SHOULD immediately remove all the NLRI and the associated MPLS labels that it previously acquired via BGP from the restarting LSR.
さらに、再起動LSRから受け取った優雅な再起動機能のフラグが、LSRが再起動全体でMPLS状態を保持できなかったことを示している場合、隣人はすべてのNLRIをすべて削除し、以前に取得した関連するMPLSラベルを削除する必要があります。再起動LSRからBGPを介して。
An LSR, once it creates a binding between a label and a Forwarding Equivalence Class (FEC), SHOULD keep the value of the label in this binding for as long as the LSR has a route to the FEC in the binding. If the route to the FEC disappears and then re-appears again later, then this may result in using a different label value, as when the route re-appears, the LSR would create a new <label, FEC> binding.
LSRは、ラベルと転送等価クラス（FEC）の間にバインディングを作成すると、LSRがバインディングにFECへのルートを持っている限り、このバインディングのラベルの値を維持する必要があります。FECへのルートが消えてから再び再び表示されると、ルートが再表示されると、LSRが新しい<ラベル、FEC>バインディングを作成するように、異なるラベル値を使用する可能性があります。
To minimize the potential misrouting caused by the label change, when creating a new <label, FEC> binding, the LSR SHOULD pick up the least recently used label. Once an LSR releases a label, the LSR SHALL NOT re-use this label for advertising a <label, FEC> binding to a neighbor that supports graceful restart for at least the Restart Time, as advertised by the neighbor to the LSR. This rule SHALL apply to any label release at any time.
ラベルの変更によって引き起こされる潜在的な誤った誤ったルーティングを最小限に抑えるために、新しい<ラベルFec>バインディングを作成するとき、LSRは最近使用されていないラベルをピックアップする必要があります。LSRがラベルをリリースすると、LSRは、LSRの隣人によって宣伝されているように、少なくとも再起動時に優雅な再起動をサポートする隣人にバインディングする<ラベル、FEC>のバインディングのためにこのラベルを再利用してはなりません。このルールは、いつでもラベルリリースに適用されます。
Procedures described in Section 4 involve more computational overhead on the restarting router than do the procedures described in Section 5.
セクション4で説明されている手順には、セクション5で説明されている手順よりも、再起動ルーターの計算オーバーヘッドが多く含まれています。
Procedures described in Section 5 require twice as many labels as those described in Section 4.
セクション5で説明されている手順には、セクション4で説明されているラベルの2倍のラベルが必要です。
Procedures described in Section 4 cause fewer changes to the MPLS forwarding state in the neighbors of the restarting router than the procedures described in Section 5.
セクション4で説明されている手順により、セクション5で説明されている手順よりも、再起動ルーターの近隣のMPLS転送状態の変化が少なくなります。
In principle, it is possible for an LSR to use procedures described in Section 4 for some AFI/SAFI(s) and procedures described in Section 5 for other AFI/SAFI(s).
原則として、LSRは、セクション4で説明されているAFI/SAFI（S）に記載されている手順と、セクション5で説明されている手順を使用して、他のAFI/SAFIを使用できます。
The security considerations pertaining to the BGP protocol [RFC4271] remain relevant.
BGPプロトコル[RFC4271]に関連するセキュリティ上の考慮事項は引き続き関連しています。
In addition, the mechanism described here renders LSRs that implement it vulnerable to additional denial-of-service attacks as follows:
さらに、ここで説明するメカニズムは、次のように追加のサービス拒否攻撃に対して脆弱なLSRを実装するものにします。
An intruder may impersonate a BGP peer in order to force a failure and reconnection of the TCP connection, where the intruder sets the Forwarding State (F) bit (as defined in [RFC4724]) to 0 on reconnection. This forces all labels received from the peer to be released.
侵入者は、侵入者が転送状態（f）ビット（[RFC4724]で定義）を再接続時に0に設定するTCP接続の障害と再接続を強制するためにBGPピアになりすまします。これにより、ピアから受け取ったすべてのラベルがリリースされます。
An intruder could intercept the traffic between BGP peers and override the setting of the Forwarding State (F) bit to be set to 0. This forces all labels received from the peer to be released.
侵入者は、BGPピア間のトラフィックを傍受し、転送状態（f）ビットの設定を0に上書きすることができます。
All of these attacks may be countered by use of an authentication scheme between BGP peers, such as the scheme outlined in [RFC2385].
これらの攻撃はすべて、[RFC2385]で概説されているスキームなど、BGPピア間の認証スキームを使用することにより対抗できます。
As with BGP carrying labels, a security issue may exist if a BGP implementation continues to use labels after expiration of the BGP session that first caused them to be used. This may arise if the upstream LSR detects the session failure after the downstream LSR has released and re-used the label. The problem is most obvious with the platform-wide label space and could result in misrouting of data to destinations other than those intended; and it is conceivable that these behaviors may be deliberately exploited, either to obtain services without authorization or to deny services to others.
BGPの運搬ラベルと同様に、BGPの実装が最初に使用されたBGPセッションの有効期限が切れた後もラベルを使用し続ける場合、セキュリティの問題が存在する可能性があります。下流のLSRがラベルをリリースして再利用した後、上流のLSRがセッションの障害を検出すると、これが発生する可能性があります。この問題は、プラットフォーム全体のラベル空間で最も明白であり、意図したもの以外の目的地にデータを誤って誤解する可能性があります。そして、これらの行動は、許可なしにサービスを取得するか、他の人へのサービスを拒否するために、意図的に悪用される可能性があると考えられます。
In this document, the validity of the BGP session may be extended by the Restart Time, and the session may be re-established in this period. After the expiry of the Restart Time, the session must be considered to have failed, and the same security issue applies as described above.
このドキュメントでは、BGPセッションの有効性は再起動時間によって延長される場合があり、この期間にセッションが再確立される場合があります。再起動時間の有効期限が切れた後、セッションは失敗したと見なされる必要があり、同じセキュリティの問題が上記のように適用されます。
However, the downstream LSR may declare the session as failed before the expiration of its Restart Time. This increases the period during which the downstream LSR might reallocate the label while the upstream LSR continues to transmit data using the old usage of the label. To reduce this issue, this document requires that labels are not re-used until at least the Restart Time.
ただし、下流のLSRは、再起動時間の満了前にセッションが失敗したと宣言する場合があります。これにより、下流のLSRがラベルを再配分する期間が増加し、上流のLSRがラベルの古い使用法を使用してデータを送信し続けます。この問題を減らすために、このドキュメントでは、少なくとも再起動時にラベルが再利用されないことが必要です。
We would like to thank Chaitanya Kodeboyina and Loa Andersson for their review and comments. The approach described in Section 5 is based on the idea suggested by Manoj Leelanivas.
レビューとコメントをしてくれたChaitanya KodeboyinaとLoa Anderssonに感謝します。セクション5で説明されているアプローチは、Manoj Leelanivasが提案したアイデアに基づいています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPの優雅な再起動メカニズム」、RFC 4724、2007年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y。およびE. Rosen、「BGP-4でのラベル情報の運搬」、RFC 3107、2001年5月。
Authors' Addresses
著者のアドレス
Yakov Rekhter Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks 1194 N.Mathilda Ave Sunnyvale、CA 94089
EMail: yakov@juniper.net
Rahul Aggarwal Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089
Rahul Aggarwal Juniper Networks 1194 N.Mathilda Ave Sunnyvale、CA 94089
EMail: rahul@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。