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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
リンクローカルシグナリング（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およびデータベース記述（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.
Helloパケットをいつでも送信することができるので、Helloパケットに取り付けLLSブロックに含まれるデータは、動的なシグナリングのために使用されるかもしれません。しかし、Helloパケット内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ルータと対話するとき、原因LLSブロックTLVのに加えられた変更は、基本的なルーティングに影響を与えません。
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ビット（Lは、LLSを表す）（図2Aおよび図2Bを参照）OSPFオプションフィールド内に導入されます。ルータは、パケットがLLSデータブロックが含まれていることを示すためにこんにちは、DDパケットにLビットを設定します。 Lビットがセットされている言い換えれば、LLSデータブロックのみが検査されます。
+---+---+---+---+---+---+---+---+
| * | 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.
LビットはLLSブロックが含まれているこんにちは、DDパケットを除いて設定してはいけません。
The data block used for link-local signaling is formatted as described below (see Figure 3 for illustration).
（例示については図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.
Typeフィールドは、TLVの種類ごとに一意であるTLV IDが含まれています。長さフィールドは、（バイト）値フィールドの長さを含みます。 Valueフィールドは可変であり、任意のデータが含まれています。
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.
（それらはLLSブロックヘッダ内のLLSデータ長フィールドに含まれているが）のTLVは、TLVの長さフィールドには常に32ビット境界に埋め込まれているが、パディングバイトが含まれていないことに留意されたいです。認識できない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.
ここでは、TLVは、拡張オプションとフラグ（EOF）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.
ValueフィールドのビットはLLSメカニズムの観点から、いずれかの意味を持っていません。ビットは、OSPFリンクローカル機能を発表するために割り当てることができます。ビットもブールリンクローカルシグナリングを実行するために割り当てられてもよいです。
The length of the Value field in the EOF-TLV is 4 bytes.
EOF-TLVにおけるValueフィールドの長さは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でのTypeフィールドの値が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]及び[RESTART] 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.
図6に示すように、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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のためのTypeフィールドの値が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.
ヘッダの長さフィールドは、シーケンス番号とメッセージの長さをバイト単位で全体LLSブロックのブロックを消化するための4つのバイトを含む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ブロックで複数回出現することはできません。また、存在する場合、この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 "OSPF（Open Shortest Path First）のリンクローカルシグナリング（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ビットを割り当て。
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は、リンクローカルリンクステートアドバタイズメント（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
TLVタイプ名リファレンス0予約1つの拡張オプションとフラグ[RFC5613] 2暗号認証+ [RFC5613] IANAによって割り当てのために3から32767予約済み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]
ビット名参照0x00000001のLSDB再同期（LR）[RFC4811] 0x00000002再起動信号（RSビット）[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ルータがOSPFパケットまたは暗号化メッセージダイジェスト後LLSデータブロックを無視するLLSをサポートしていないので、OSPFパケットフォーマットの変更は、標準的な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のから継承されたセキュリティ上の考慮事項は、[OSPFv2の]で説明されています。この技術は、LLSデータのOSPFv2が使用するのと同じ暗号化認証（詳細はセクション2.5を参照）を使用して認証することができるようにすることで、基本的なOSPFv2のプロトコルと同じレベルのセキュリティを提供します。
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のから継承されたセキュリティ上の考慮事項は、[OSPFv3の]と[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
【のOSPFv2]モイ、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.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[OSPFV3AUTH] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3AUTH]グプタ、M.およびN.メラム、 "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]グエン、L.、ロイ、A.、およびA.ジニン、 "OSPFアウトオブバンドリンクステートデータベース（LSDB）再同期"、RFC 4811、2007年3月。
[RESTART] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, March 2007.
[RESTART]グエン、L.、ロイ、A.、およびA.ジニン、 "OSPFの再起動シグナリング"、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]フリードマン、B.、グエン、L.、ロイ、A.、ヨン、D.、およびA.ジニン、 "OSPFリンクローカルシグナリング"、RFC 4813、2007年3月。
Appendix A. Acknowledgements
付録A.謝辞
The authors would like to acknowledge Russ White, Acee Lindem, and Manral Vishwas for their review of this document.
作者はこのドキュメントの彼らのレビューのためにラスホワイト、ACEE Lindem、およびManral Vishwasを確認したいと思います。
Appendix B. Changes from
付録B.変更から
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
メールアドレス：alex.zinin@alcatel-lucent.com
Abhay Roy Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
アブヘイロイシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: akr@cisco.com
メールアドレス：akr@cisco.com
Liem Nguyen Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Liem Nguyenのシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: lhnguyen@cisco.com
メールアドレス：lhnguyen@cisco.com
Barry Friedman Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
バリー・フリードマングーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043 USA
EMail: barryf@google.com
メールアドレス：barryf@google.com
Derek Yeung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
デレク・ヨンシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: myeung@cisco.com
メールアドレス：myeung@cisco.com