[要約] RFC 5613は、OSPFリンクローカルシグナリングの仕様を定義しており、リンク上の隣接ルータ間での情報交換を改善することを目的としています。この仕様により、OSPFプロトコルの効率性と信頼性が向上し、ネットワークのパフォーマンスが向上します。
Network Working Group A. Zinin
Request for Comments: 5613 Alcatel-Lucent
Obsoletes: 4813 A. Roy
Category: Standards Track L. Nguyen
Cisco Systems
B. Friedman
Google, Inc.
D. Yeung
Cisco Systems
August 2009
OSPF Link-Local Signaling
OSPFリンクローカルシグナル伝達
Abstract
概要
OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.
OSPFは、リンク状態内領域内ルーティングプロトコルです。OSPFルーターは、明確に定義された固定形式に従うパケットを使用して、リンク上の情報を交換します。この形式は、任意のデータを交換する必要がある新しい機能を有効にするほど柔軟ではありません。このドキュメントでは、リンクローカルシグナル伝達を実行するための後方互換の手法、つまりリンク上の任意のデータを交換することについて説明します。このドキュメントでは、RFC 4813に掲載された実験仕様に置き換えて、標準のトラックにもたらします。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
2.1. L-Bit in Options Field . . . . . . . . . . . . . . . . . . 4
2.2. LLS Data Block . . . . . . . . . . . . . . . . . . . . . . 4
2.3. LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Extended Options and Flags TLV . . . . . . . . . . . . . . 5
2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 6
2.6. Private TLVs . . . . . . . . . . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. Changes from RFC 4813 . . . . . . . . . . . . . . . . 11
This document describes an extension to OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3] allowing additional information to be exchanged between routers on the same link. OSPFv2 and OSPFv3 packet formats are fixed and do not allow for extension. This document proposes appending an optional data block composed of Type/Length/Value (TLV) triplets to existing OSPFv2 and OSPFv3 packets to carry this additional information. Throughout this document, OSPF will be used when the specification is applicable to both OSPFv2 and OSPFv3. Similarly, OSPFv2 or OSPFv3 will be used when the text is protocol specific.
このドキュメントでは、OSPFV2 [OSPFV2]およびOSPFV3 [OSPFV3]の拡張について説明し、同じリンクのルーター間で追加情報を交換できるようにします。OSPFV2およびOSPFV3パケット形式は固定されており、拡張を許可しません。このドキュメントは、この追加情報を伝えるために、既存のOSPFV2およびOSPFV3パケットにタイプ/長さ/値（TLV）トリプレットで構成されるオプションのデータブロックを追加することを提案しています。このドキュメント全体を通して、仕様がOSPFV2とOSPFV3の両方に適用できる場合、OSPFが使用されます。同様に、テキストがプロトコル固有の場合、OSPFV2またはOSPFV3が使用されます。
One potential way of solving this task could be introducing a new packet type. However, that would mean introducing extra packets on the network that may not be desirable and may cause backward compatibility issues. This document describes how to exchange data using standard OSPF packet types.
このタスクを解決する潜在的な方法の1つは、新しいパケットタイプを導入することです。ただし、それは、ネットワーク上に余分なパケットを導入することを意味し、望ましくない可能性があり、後方互換性の問題を引き起こす可能性があります。このドキュメントでは、標準のOSPFパケットタイプを使用してデータを交換する方法について説明します。
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 [KEY].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[key]で説明されているように解釈されます。
To perform link-local signaling (LLS), OSPF routers add a special data block to the end of OSPF packets or right after the authentication data block when cryptographic authentication is used. The length of the LLS block is not included into the length of the OSPF packet, but is included in the IPv4/IPv6 packet length. Figure 1 illustrates how the LLS data block is attached.
Link-Local Signaling（LLS）を実行するために、OSPFルーターは、暗号化認証が使用されるときに、OSPFパケットの最後に、または認証データブロックの直後に特別なデータブロックを追加します。LLSブロックの長さはOSPFパケットの長さに含まれていませんが、IPv4/IPv6パケットの長さに含まれています。図1は、LLSデータブロックの添付方法を示しています。
+---------------------+ -- -- +---------------------+
| IP Header | ^ ^ | IPv6 Header |
| Length = HL+X+Y+Z | | Header Length | | Length = HL+X+Y |
| | v v | |
+---------------------+ -- -- +---------------------+
| OSPF Header | ^ ^ | OSPFv3 Header |
| Length = X | | | | Length = X |
|.....................| | X | X |.....................|
| | | | | |
| OSPFv2 Data | | | | OSPFv3 Data |
| | v v | |
+---------------------+ -- -- +---------------------+
| | ^ ^ | |
| Authentication Data | | Y | Y | LLS Data |
| | v v | |
+---------------------+ -- -- +---------------------+
| | ^
| LLS Data | | Z
| | v
+---------------------+ --
Figure 1: LLS Data Block in OSPFv2 and OSPFv3
図1：OSPFV2およびOSPFV3のLLSデータブロック
The LLS block MAY be attached to OSPF Hello and Database Description (DD) packets. The LLS block MUST NOT be attached to any other OSPF packet types on generation and MUST be ignored on reception.
LLSブロックは、OSPF HelloおよびDatabase説明（DD）パケットに添付される場合があります。LLSブロックは、生成時に他のOSPFパケットタイプに接続してはなりません。受信時に無視する必要があります。
The data included in the LLS block attached to a Hello packet MAY be used for dynamic signaling since Hello packets may be sent at any time. However, delivery of LLS data in Hello packets is not guaranteed. The data sent with DD packets is guaranteed to be delivered as part of the adjacency forming process.
ハローパケットに接続されたLLSブロックに含まれるデータは、ハローパケットがいつでも送信される可能性があるため、動的信号に使用できます。ただし、ハローパケットでのLLSデータの配信は保証されていません。DDパケットで送信されたデータは、隣接する形成プロセスの一部として配信されることが保証されています。
This document does not specify how the data transmitted by the LLS mechanism should be interpreted by OSPF routers. As routers that do not understand LLS may receive these packets, changes made due to LLS block TLV's do not affect the basic routing when interacting with non-LLS routers.
このドキュメントでは、LLSメカニズムによって送信されるデータをOSPFルーターによって解釈する方法を指定していません。LLSを理解していないルーターはこれらのパケットを受け取る可能性があるため、LLSブロックTLVのために行われた変更は、非LLSルーターと対話する際に基本的なルーティングに影響しません。
A new L-bit (L stands for LLS) is introduced into the OSPF Options field (see Figures 2a and 2b). Routers set the L-bit in Hello and DD packets to indicate that the packet contains an LLS data block. In other words, the LLS data block is only examined if the L-bit is set.
新しいLビット（LSの略）がOSPFオプションフィールドに導入されます（図2aおよび2bを参照）。ルーターは、LITをHelloおよびDDパケットに設定して、パケットにLLSデータブロックが含まれていることを示します。つまり、LLSデータブロックは、Lビットが設定されている場合にのみ調べられます。
+---+---+---+---+---+---+---+---+
| * | O | DC| L |N/P| MC| E | * |
+---+---+---+---+---+---+---+-+-+
Figure 2a: OSPFv2 Options Field
図2a：OSPFV2オプションフィールド
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+
| | | | | | | | | | | | | | |L|AF|*|*|DC| R| N|MC| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+
Figure 2b: OSPFv3 Options Field
図2B：OSPFV3オプションフィールド
The L-bit MUST NOT be set except in Hello and DD packets that contain an LLS block.
LLSブロックを含むHelloおよびDDパケットを除いて、L-BITを設定してはなりません。
The data block used for link-local signaling is formatted as described below (see Figure 3 for illustration).
Link-Localシグナル伝達に使用されるデータブロックは、以下に説明するようにフォーマットされています（図については図3を参照）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | LLS Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LLS TLVs |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of LLS Data Block
図3：LLSデータブロックの形式
The Checksum field contains the standard IP checksum for the entire contents of the LLS block. Before computing the checksum, the checksum field is set to 0. If the checksum is incorrect, the OSPF packet MUST be processed, but the LLS block MUST be discarded.
チェックサムフィールドには、LLSブロックの内容全体の標準のIPチェックサムが含まれています。チェックサムを計算する前に、チェックサムフィールドは0に設定されます。チェックサムが正しくない場合、OSPFパケットを処理する必要がありますが、LLSブロックを破棄する必要があります。
The 16-bit LLS Data Length field contains the length (in 32-bit words) of the LLS block including the header and payload.
16ビットLLSデータ長さフィールドには、ヘッダーとペイロードを含むLLSブロックの長さ（32ビット語）が含まれています。
Note that if the OSPF packet is cryptographically authenticated, the LLS data block MUST also be cryptographically authenticated. In this case, the regular LLS checksum is not calculated, but is instead set to 0.
OSPFパケットが暗号化された認証されている場合、LLSデータブロックも暗号化された認証されている必要があることに注意してください。この場合、通常のLLSチェックサムは計算されませんが、代わりに0に設定されます。
The rest of the block contains a set of Type/Length/Value (TLV) triplets as described in Section 2.3. All TLVs MUST be 32-bit aligned (with padding if necessary).
ブロックの残りの部分には、セクション2.3で説明されているように、タイプ/長さ/値（TLV）トリプレットのセットが含まれています。すべてのTLVは、32ビットアラインドしている必要があります（必要に応じてパディングを使用）。
The contents of an LLS data block are constructed using TLVs. See Figure 4 for the TLV format.
LLSデータブロックの内容は、TLVを使用して構築されます。TLV形式については、図4を参照してください。
The Type field contains the TLV ID, which is unique for each type of TLV. The Length field contains the length of the Value field (in bytes). The Value field is variable and contains arbitrary data.
タイプフィールドには、TLV 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of LLS TLVs
図4：LLS TLVの形式
Note that TLVs are always padded to a 32-bit boundary, but padding bytes are not included in the TLV Length field (though they are included in the LLS Data Length field in the LLS block header). Unrecognized TLV types are ignored.
TLVは常に32ビットの境界にパッドにされていますが、パディングバイトはTLV長いフィールドに含まれていません（ただし、LLSブロックヘッダーのLLSデータ長フィールドに含まれています）。認識されていないTLVタイプは無視されます。
This subsection describes a TLV called the Extended Options and Flags (EOF) TLV. The format of the EOF-TLV is shown in Figure 5.
このサブセクションでは、拡張オプションとフラグ（EOF）TLVと呼ばれるTLVについて説明しています。EOF-TLVの形式を図5に示します。
Bits in the Value field do not have any semantics from the point of view of the LLS mechanism. Bits MAY be allocated to announce OSPF link-local capabilities. Bits MAY also be allocated to perform boolean link-local signaling.
値フィールドのビットには、LLSメカニズムの観点からセマンティクスがありません。OSPF Link-Local機能を発表するためにBITSが割り当てられる場合があります。BITSは、ブールリンクローカルシグナル伝達を実行するために割り当てられる場合があります。
The length of the Value field in the EOF-TLV is 4 bytes.
EOF-TLVの値フィールドの長さは4バイトです。
The value of the Type field in the EOF-TLV is 1. The EOF-TLV MUST only appear once in the LLS data block.
EOF-TLVのタイプフィールドの値は1です。EOF-TLVは、LLSデータブロックに1回のみ表示する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Options and Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of the EOF-TLV
図5：EOF-TLVの形式
Currently, [OOB] and [RESTART] use bits in the Extended Options field of the EOF-TLV.
現在、[OOB]および[再起動]は、EOF-TLVの拡張オプションフィールドでビットを使用しています。
The Extended Options and Flags bits are defined in Section 3.
拡張オプションとフラグビットは、セクション3で定義されています。
This document defines a special TLV that is used for cryptographic authentication (CA-TLV) of the LLS data block. This TLV MUST only be included in the LLS block when cryptographic authentication is enabled on the corresponding interface. The message digest of the LLS block MUST be calculated using the same key and authentication algorithm as used for the OSPFv2 packet. The cryptographic sequence number is included in the TLV and MUST be the same as the one in the OSPFv2 authentication data for the LLS block to be considered authentic.
このドキュメントでは、LLSデータブロックの暗号化認証（CA-TLV）に使用される特別なTLVを定義します。このTLVは、対応するインターフェイスで暗号化認証が有効になっている場合にのみLLSブロックに含める必要があります。LLSブロックのメッセージダイジェストは、OSPFv2パケットに使用されるのと同じキーと認証アルゴリズムを使用して計算する必要があります。暗号化シーケンス番号はTLVに含まれており、LLSブロックのOSPFV2認証データのものと同じである必要があります。
The TLV is constructed as shown in Figure 6.
TLVは、図6に示すように構築されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | AuthLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. AuthData .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of Cryptographic Authentication TLV
図6：暗号化認証TLVの形式
The value of the Type field for the CA-TLV is 2.
CA-TLVのタイプフィールドの値は2です。
The Length field in the header contains the length of the data portion of the TLV including 4 bytes for Sequence Number and the length of the message digest block for the whole LLS block in bytes.
ヘッダーの長さフィールドには、シーケンス番号の4バイトと、LLSブロック全体のメッセージダイジェストブロックの長さを含むTLVのデータ部分の長さが含まれています。
The Sequence Number field contains the cryptographic sequence number that is used to prevent simple replay attacks. For the LLS block to be considered authentic, the Sequence Number in the CA-TLV MUST match the Sequence Number in the OSPFv2 packet header Authentication field (which MUST be present). In the event of Sequence Number mismatch or Authentication failure, the whole LLS block MUST be ignored.
シーケンス番号フィールドには、単純なリプレイ攻撃を防ぐために使用される暗号化シーケンス番号が含まれています。LLSブロックを本物と見なすには、CA-TLVのシーケンス番号は、OSPFV2パケットヘッダー認証フィールドのシーケンス番号と一致する必要があります（存在する必要があります）。シーケンス番号の不一致または認証障害が発生した場合、LLSブロック全体を無視する必要があります。
The CA-TLV MUST NOT appear more than once in the LLS block. Also, when present, this TLV MUST be the last TLV in the LLS block. If it appears more than once, only the first occurrence is processed and any others MUST be ignored.
CA-TLVは、LLSブロックに1回以上表示されてはなりません。また、存在する場合、このTLVはLLSブロックの最後のTLVでなければなりません。複数回見える場合は、最初の発生のみが処理され、他の発生を無視する必要があります。
The AuthData field contains the message digest calculated for the LLS data block up to the CA-TLV AuthData field (i.e., excludes the CA-TLV AuthData).
AuthDataフィールドには、LLSデータブロックに対してCA-TLV AuthDataフィールドまで計算されたメッセージが含まれています（つまり、CA-TLV AuthDataを除外）。
The CA-TLV is not applicable to OSPFv3 and it MUST NOT be added to any OSPFv3 packet. If found on reception, this TLV MUST be ignored.
CA-TLVはOSPFV3には適用されず、OSPFV3パケットに追加してはなりません。受信で見つかった場合、このTLVは無視する必要があります。
LLS type values in the range of 32768-65536 are reserved for private use. The first four octets of the Value field MUST be the private enterprise code [ENTNUM]. This allows multiple vendor private extensions to coexist in a network.
32768-65536の範囲のLLSタイプの値は、私的使用のために予約されています。値フィールドの最初の4オクテットは、プライベートエンタープライズコード[entnum]でなければなりません。これにより、複数のベンダープライベートエクステンションがネットワークに共存できます。
This document uses the registry that was originally created in [RFC4813]. IANA updated the following registry to point to this document instead:
このドキュメントでは、もともと[RFC4813]で作成されたレジストリを使用しています。IANAは次のレジストリを更新して、代わりにこのドキュメントを指します。
o "Open Shortest Path First (OSPF) Link-Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)"
o 「Openestestest Path First（OSPF）Link -Local Signaling（LLS） - タイプ/長さ/値識別子（TLV）」」
IANA allocated L-bit in the "OSPFv2 Options Registry" and "OSPFv3 Options Registry" as per Section 2.1.
IANAは、セクション2.1に従って、「OSPFV2オプションレジストリ」および「OSPFV3オプションレジストリ」にL-BITを割り当てました。
LLS TLV types are maintained by the IANA. Extensions to OSPF that require a new LLS TLV type MUST be reviewed by a Designated Expert from the routing area.
LLS TLVタイプはIANAによって維持されます。新しいLLS TLVタイプを必要とするOSPFへの拡張は、ルーティングエリアの指定された専門家によってレビューする必要があります。
The criteria for allocating LLS TLVs are:
LLS TLVを割り当てるための基準は次のとおりです。
o LLS should not be used for information that would be better suited to be advertised in a link-local link state advertisement (LSA).
o LLSは、Link-Local Link State Advertisement（LSA）で宣伝されるのに適した情報に使用されるべきではありません。
o LLS should be confined to signaling between direct neighbors.
o LLSは、直接の隣人間のシグナル伝達に限定される必要があります。
o Discretion should be used in the volume of information signaled using LLS due to the obvious MTU and performance implications.
o 明らかなMTUとパフォーマンスへの影響により、LLSを使用して合図された情報の量で裁量を使用する必要があります。
Following the policies outlined in [IANA], LLS type values in the range of 0-32767 are allocated through an IETF Review and LLS type values in the range of 32768-65535 are reserved for private use.
[IANA]で概説されているポリシーに続いて、0-32767の範囲のLLSタイプの値は、32768-65535の範囲のIETFレビューとLLSタイプの値を通じて割り当てられます。
This document assigns the following LLS TLV types in OSPFv2/OSPFv3.
このドキュメントは、OSPFv2/OSPFV3に次のLLS TLVタイプを割り当てます。
TLV Type Name Reference
0 Reserved
1 Extended Options and Flags [RFC5613]
2 Cryptographic Authentication+ [RFC5613]
3-32767 Reserved for assignment by the IANA
32768-65535 Private Use
+ Cryptographic Authentication TLV is only defined for OSPFv2
+ 暗号化認証TLVは、OSPFv2に対してのみ定義されます
IANA renamed the sub-registry from "LLS Type 1 Extended Options" to "LLS Type 1 Extended Options and Flags".
IANAは、「LLSタイプ1拡張オプション」から「LLSタイプ1拡張オプションとフラグ」にサブレジストリを変更しました。
This document also assigns the following bits in the EOF-TLV outlined in Section 2.5:
このドキュメントは、セクション2.5で概説されているEOF-TLVに次のビットを割り当てます。
Bit Name Reference
0x00000001 LSDB Resynchronization (LR) [RFC4811]
0x00000002 Restart Signal (RS-bit) [RFC4812]
Future allocation of Extended Options and Flags bits MUST be reviewed by a Designated Expert from the routing area.
拡張オプションとフラグのビットの将来の割り当ては、ルーティングエリアの指定された専門家によってレビューする必要があります。
The modifications to OSPF packet formats are compatible with standard OSPF since OSPF routers not supporting LLS will ignore the LLS data block after the OSPF packet or cryptographic message digest. As of this writing, there are implementations deployed with [RFC4813]- compliant software. Routers not implementing [RFC4813] ignore the LLS data at the end of the OSPF packet.
OSPFパケット形式の変更は、LLSをサポートしていないOSPFルーターがOSPFパケットまたは暗号化メッセージダイジェストの後にLLSデータブロックを無視するため、標準のOSPFと互換性があります。この執筆時点では、[RFC4813]に準拠したソフトウェアで展開された実装があります。[RFC4813]を実装していないルーターは、OSPFパケットの最後にLLSデータを無視します。
Careful consideration should be given to carrying additional LLS data, as it may affect the OSPF adjacency bring-up time due to additional propagation delay and/or processing time.
追加の伝播遅延および/または処理時間のためにOSPFの隣接する潜在時間に影響を与える可能性があるため、追加のLLSデータを運ぶことに慎重に検討する必要があります。
Security considerations inherited from OSPFv2 are described in [OSPFV2]. This technique provides the same level of security as the basic OSPFv2 protocol by allowing LLS data to be authenticated using the same cryptographic authentication that OSPFv2 uses (see Section 2.5 for more details).
OSPFV2から継承されたセキュリティ上の考慮事項は、[OSOSPFV2]で説明されています。この手法は、OSPFV2が使用するのと同じ暗号認証を使用してLLSデータを認証できるようにすることにより、基本的なOSPFV2プロトコルと同じレベルのセキュリティを提供します（詳細についてはセクション2.5を参照）。
Security considerations inherited from OSPFv3 are described in [OSPFV3] and [OSPFV3AUTH]. OSPFv3 utilizes IPsec for authentication and encryption. With IPsec, the AH (Authentication Header), ESP (Encapsulating Security Payload), or both are applied to the entire OSPFv3 payload including the LLS block.
OSPFV3から継承されたセキュリティ上の考慮事項は、[OSOSPFV3]および[OSPFV3AUTH]で説明されています。OSPFV3は、認証と暗号化にIPSECを使用します。IPSEC、AH（認証ヘッダー）、ESP（セキュリティペイロードのカプセル化）、または両方がLLSブロックを含むOSPFV3ペイロード全体に適用されます。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Key] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2] Moy、J。、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[OSPFV3] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[OSPFV3AUTH] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3AUTH] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
[ENTNUM] IANA, "PRIVATE ENTERPRISE NUMBERS", http://www.iana.org.
[entnum] iana、「プライベートエンタープライズ番号」、http：//www.iana.org。
[OOB] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link State Database (LSDB) Resynchronization", RFC 4811, March 2007.
[OOB] Nguyen、L.、Roy、A。、およびA. Zinin、「OSPF Out-Band Link State Database（LSDB）再同期」、RFC 4811、2007年3月。
[RESTART] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, March 2007.
[再起動] Nguyen、L.、Roy、A。、およびA. Zinin、「OSPF Restart Signaling」、RFC 4812、2007年3月。
[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
[RFC4813] Friedman、B.、Nguyen、L.、Roy、A.、Yeung、D。、およびA. Zinin、「OSPF Link-Local Signaling」、RFC 4813、2007年3月。
The authors would like to acknowledge Russ White, Acee Lindem, and Manral Vishwas for their review of this document.
著者は、この文書をレビューするために、ラス・ホワイト、エイジー・リンデム、マンラル・ヴィシュワスを認めたいと考えています。
This section describes the substantive change from [RFC4813].
このセクションでは、[RFC4813]からの実質的な変更について説明します。
o Added OSPFv3 support
o OSPFV3サポートを追加しました
o Private TLVs MUST use private enterprise code
o プライベートTLVは、プライベートエンタープライズコードを使用する必要があります
o Clarified requirement levels at several places
o いくつかの場所での要件レベルを明確にしました
o Changed from Experimental to Standards Track
o 実験的なトラックから標準への変更を変更しました
Authors' Addresses
著者のアドレス
Alex Zinin Alcatel-Lucent Singapore
アレックス・ジニン・アルカテル・ルーセント・シンガポール
EMail: alex.zinin@alcatel-lucent.com
Abhay Roy Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Abhay Roy Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
EMail: akr@cisco.com
Liem Nguyen Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Liem Nguyen Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
EMail: lhnguyen@cisco.com
Barry Friedman Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Barry Friedman Google、Inc。1600 Amphitheater Parkway Mountain View、CA 94043 USA
EMail: barryf@google.com
Derek Yeung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Derek Yeung Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
EMail: myeung@cisco.com