RFC4813 日本語訳
4813 OSPF Link-Local Signaling. B. Friedman, L. Nguyen, A. Roy, D.Yeung, A. Zinin. March 2007. (Format: TXT=19687 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Friedman
Request for Comments: 4813 L. Nguyen
Category: Experimental A. Roy
D. Yeung
Cisco Systems
A. Zinin
Alcatel
February 2007
コメントを求めるワーキンググループB.フリードマン要求をネットワークでつないでください: 4813年のL.Nguyenカテゴリ: 実験的なA.のYeungシスコシステムズA.ジニンアルカテルロイD.2007年2月
OSPF Link-Local Signaling
OSPFのリンク地方のシグナリング
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.
OSPFはIPネットワークに使用されるリンク州のイントラドメインルーティング・プロトコルです。 OSPFルータは、リンクで明確な形式に続くパケットを使用することで情報交換します。 OSPFパケットの形式はアプリケーションが、ある状況で必要であるかもしれない任意のデータを交換するのを可能にするくらいにはフレキシブルではありません。 このメモはリンク地方のシグナリングを実行するためにベンダー特有の、そして、後方コンパチブルテクニックについて説明して、すなわち、交換はリンクに関する任意のデータです。
Friedman, et al. Experimental [Page 1] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[1ページ]RFC4813OSPF
Table of Contents
目次
1. Introduction ....................................................2
2. Proposed Solution ...............................................2
2.1. Options Field ..............................................3
2.2. LLS Data Block .............................................4
2.3. LLS TLVs ...................................................5
2.4. Predefined TLV .............................................5
2.4.1. Extended Options TLV ................................5
2.4.2. Cryptographic Authentication TLV ....................6
3. Backward Compatibility ..........................................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Acknowledgements ......................................9
1. 序論…2 2. ソリューションを提案します…2 2.1. オプション分野…3 2.2. LLSデータ・ブロック…4 2.3. LLS TLVs…5 2.4. TLVを事前に定義します…5 2.4.1. オプションTLVを広げています…5 2.4.2. 暗号の認証TLV…6 3. 後方の互換性…7 4. セキュリティ問題…7 5. IANA問題…7 6. 参照…8 6.1. 標準の参照…8 6.2. 有益な参照…8 付録A.承認…9
1. Introduction
1. 序論
Formats of OSPF [RFC2328] packets are not very flexible to provide an acceptable mechanism for opaque data transfer. However, this appears to be very useful to allow OSPF routers to do so. An example where such a technique could be used is exchanging some capabilities on a link (standard OSPF utilizes the Options field in Hello and Exchange packets, but there are not so many bits left in it).
OSPF[RFC2328]パケットの形式は許容できるメカニズムを不明瞭なデータ転送に提供するのにおいてそれほどフレキシブルではありません。 しかしながら、これはOSPFルータがそうするのを許容するために非常に役に立つように見えます。 そのようなテクニックを使用できた例はリンクの上のいくつかの能力を交換しています(標準のOSPFがHelloとExchangeパケットのOptions分野を利用しますが、数ビットしかそれに残っていません)。
One potential way of solving this task could be introducing a new packet type. However, that would mean introducing extra packets on the network, which may not be desirable, so this document describes how to exchange data using existing, standard OSPF packet types.
このタスクを解決する1つの潜在的方法は新しいパケットタイプを導入することであるかもしれません。 しかしながら、それは、望ましくないかもしれないネットワークで付加的なパケットを導入することを意味するでしょう、したがって、このドキュメントが存在(標準のOSPFパケットタイプ)を使用するデータを交換する方法を説明します。
2. Proposed Solution
2. 提案されたソリューション
To perform link-local signaling (LLS), OSPF routers add a special data block at the end of OSPF packets or right after the authentication data block when cryptographic authentication is used. Like with OSPF cryptographic authentication, the length of the LLS- block is not included into the length of OSPF packet, but is included in the IP packet length. Figure 1 illustrates how the LLS data block is attached.
暗号の認証が特別なデータ・ブロックにOSPFパケットの端において認証データブロック直後使用されているのに、(LLS)に合図しながらリンク地方で働くために、OSPFルータは加えます。 OSPFの暗号の認証などのように、LLSブロックの長さは、OSPFパケットの長さに含められていませんが、IPパケット長に含まれています。 図1はLLSデータ・ブロックがどう添付しているかを例証します。
Friedman, et al. Experimental [Page 2] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[2ページ]RFC4813OSPF
+---------------------+ --
| IP Header | ^
| Length = HL+X+Y+Z | | Header Length
| | v
+---------------------+ --
| OSPF Header | ^
| Length = X | |
|.....................| | X
| | |
| OSPF Data | |
| | v
+---------------------+ --
| | ^
| Authentication Data | | Y
| | v
+---------------------+ --
| | ^
| LLS Data | | Z
| | v
+---------------------+ --
+---------------------+ -- | IPヘッダー| ^ | 長さはhl+X+Y+Zと等しいです。| | ヘッダ長| | +に対して---------------------+ -- | OSPFヘッダー| ^ | 長さはXと等しいです。| | |.....................| | X| | | | OSPFデータ| | | | +に対して---------------------+ -- | | ^ | 認証データ| | Y| | +に対して---------------------+ -- | | ^ | LLSデータ| | Z| | +に対して---------------------+ --
Figure 1: Attaching LLS Data Block
図1: 付けLLSデータ・ブロック
The LLS data block may be attached to OSPF packets of two types -- type 1 (OSPF Hello), and type 2 (OSPF DBD). 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 moment in time. However, delivery of LLS data in Hello packets is not guaranteed. The data sent with Database Description (DBD) packets is guaranteed to be delivered as part of the adjacency forming process.
LLSデータ・ブロックは2つのタイプのOSPFパケットに添付されるかもしれません--1(OSPF Hello)をタイプしてください、そして、2(OSPF DBD)をタイプしてください。 Helloパケットに添付されたLLSブロックにデータを含んでいるのはダイナミックなシグナリングに使用されるかもしれません、時間内にいつ何時Helloパケットを送るかもしれないので。 しかしながら、HelloパケットでのLLSデータの配送は保証されません。 Database記述(DBD)パケットと共に送られたデータは、隣接番組形成プロセスの一部として提供されるために保証されます。
This memo does not specify how the data transmitted by the LLS mechanism should be interpreted by OSPF routers. The interface between the OSPF LLS component and its clients is implementation- specific.
このメモはLLSメカニズムによって送られたデータがOSPFルータによってどう解釈されるべきであるかを指定しません。 OSPF LLSの部品とそのクライアントとのインタフェースは実装特有です。
2.1. Options Field
2.1. オプション分野
A new bit, called L (L stands for LLS), is introduced to the OSPF Options field (see Figure 2). The value of the bit is 0x10. Routers set the L-bit in Hello and DBD packets to indicate that the packet contains the LLS data block.
L(LはLLSを表す)と呼ばれる新しいビットはOSPF Options分野に取り入れられます(図2を見てください)。 ビットの価値は0×10です。 ルータは、HelloとDBDパケットのL-ビットにパケットがLLSデータ・ブロックを含むのを示すように設定します。
Friedman, et al. Experimental [Page 3] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[3ページ]RFC4813OSPF
+---+---+---+---+---+---+---+---+
| * | O | DC| L |N/P| MC| E | * |
+---+---+---+---+---+---+---+-+-+
+---+---+---+---+---+---+---+---+ | * | O| DC| L|N/P| M.C.| E| * | +---+---+---+---+---+---+---+-+-+
Figure 2: The Options Field
図2: オプション分野
L-bit
L-ビット
This bit is set only in Hello and DBD packets. It is not set in
OSPF Link State Advertisements (LSAs) and may be used in them for
different purposes.
このビットはHelloとDBDパケットだけに設定されます。 それは、OSPF Link州Advertisements(LSAs)に設定されないで、異なる役割に彼らで使用されるかもしれません。
2.2. LLS Data Block
2.2. LLSデータ・ブロック
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 |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| LLSデータの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LLS TLVs| . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the LLS Data Block
図3: LLSデータ・ブロックの形式
Checksum
チェックサム
The Checksum field contains the standard IP checksum of the entire
contents of the LLS block.
Checksum分野はLLSブロックの全体のコンテンツの標準のIPチェックサムを含んでいます。
LLS Length
LLSの長さ
The 16-bit LLS Data Length field contains the length (in 32-bit
words) of the LLS block including the header and payload.
Implementations should not use the Length field in the IP packet
header to determine the length of the LLS data block.
16ビットのLLS Data Length分野はヘッダーとペイロードを含むLLSブロックの長さ(32ビットの単語による)を含んでいます。 実装は、LLSデータ・ブロックの長さを測定するのにIPパケットのヘッダーのLength分野を使用するべきではありません。
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 and the LLS block will contain a cryptographic authentication TLV (see Section 2.4.2).
また、OSPFパケットが暗号で認証されるなら、暗号でLLSデータ・ブロックを認証しなければならないことに注意してください。 この場合、通常のLLSチェックサムは計算されません、そして、LLSブロックは暗号の認証TLVを含むでしょう(セクション2.4.2を見てください)。
Friedman, et al. Experimental [Page 4] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[4ページ]RFC4813OSPF
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で説明されるように1セットのType/長さ/値(TLV)の三つ子を含みます。 並べられた状態で(必要なら、そっと歩く)、すべてのTLVsが32ビットでなければなりません。
2.3. LLS TLVs
2.3. LLS TLVs
The contents of the LLS data block is constructed using TLVs. See Figure 4 for the TLV format.
LLSデータ・ブロックのコンテンツは、TLVsを使用することで構成されます。 TLV形式に関して図4を見てください。
The Type field contains the TLV ID that is unique for each type of TLVs. The Length field contains the length of the Value field (in bytes) that is variable and contains arbitrary data.
Type分野はTLVsの各タイプに、ユニークなTLV IDを含んでいます。 Length分野は、可変である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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 値の…+++++++++++++++++++++++++++++++++
Figure 4: Format of LLS TLVs
図4: LLS TLVsの形式
Note that TLVs are always padded to 32-bit boundary, but padding bytes are not included in the TLV Length field (though it is included in the LLS Data Length field of the LLS block header).
TLVsがいつも32ビットの境界に水増しされますが、詰め物バイトがTLV Length分野に含まれていないことに注意してください(それはLLSブロックヘッダーのLLS Data Length分野に含まれていますが)。
2.4. Predefined TLV
2.4. 事前に定義されたTLV
2.4.1. Extended Options TLV
2.4.1. 拡張オプションTLV
This subsection describes a TLV called Extended Options (EO) TLV. The format of EO-TLV is shown in Figure 5.
この小区分はExtended Options(EO)TLVと呼ばれるTLVについて説明します。 EO-TLVの書式は図5に示されます。
Bits in the Value field do not have any semantics from the point of view of the LLS mechanism. This field may be used to announce some OSPF capabilities that are link-specific. Also, other OSPF extensions may allocate bits in the bit vector to perform boolean link-local signaling.
Value分野のビットには、LLSメカニズムの観点からの少しの意味論もありません。 この分野は、いくつかのリンク特有のOSPF能力を発表するのに使用されるかもしれません。 また、他のOSPF拡張子は、論理演算子のリンク地方のシグナリングを実行するために噛み付いているベクトルでビットを割り当てるかもしれません。
The length of the Value field in EO-TLV is 4 bytes.
EO-TLVのValue分野の長さは4バイトです。
The value of the Type field in EO-TLV is 1.
EO-TLVのType分野の値は1です。
EO-TLV should only appear once in the LLS data block.
EO-TLVはLLSデータ・ブロックに一度現れるだけであるはずです。
Friedman, et al. Experimental [Page 5] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[5ページ]RFC4813OSPF
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of EO-TLV
図5: EO-TLVの形式
Currently, [RFC4811] and [RFC4812] use bits in the Extended Options field of the EO-TLV. The Extended Options bits are also defined in Section 5.
現在、[RFC4811]と[RFC4812]はEO-TLVのExtended Options分野でビットを使用します。 また、Extended Optionsビットはセクション5で定義されます。
2.4.2. Cryptographic Authentication TLV
2.4.2. 暗号の認証TLV
This document defines a special TLV that is used for cryptographic authentication (CA-TLV) of the LLS data block. This TLV should be included in the LLS block when the cryptographic (MD5) authentication is enabled on the corresponding interface. The message digest of the LLS block should be calculated using the same key as that used for the main OSPF packet. The cryptographic sequence number is included in the TLV and must be the same as the one in the main OSPF packet for the LLS block to be considered authentic.
このドキュメントはLLSデータ・ブロックの暗号の認証(カリフォルニア-TLV)に使用される特別なTLVを定義します。 暗号の(MD5)認証が対応するインタフェースで可能にされるとき、このTLVはLLSブロックに含まれるべきです。 LLSブロックのメッセージダイジェストは、主なOSPFパケットに使用されるそれと同じキーを使用することで計算されるべきです。 暗号の一連番号は、TLVで含められていて、LLSブロックが正統であると考えられるために主なOSPFパケットでものと同じでなければなりません。
The TLV is constructed as shown 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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . AuthData…+++++++++++++++++++++++++++++++++
Figure 6: Format of Cryptographic Authentication TLV
図6: 暗号の認証TLVの形式
The value of the Type field for CA-TLV is 2.
カリフォルニア-TLVのためのType分野の値は2です。
The Length field in the header contains the length of the data portion of the TLV that includes 4 bytes for the sequence number and the length of the message digest (MD5) block for the whole LLS block
ヘッダーのLength分野は一連番号のための4バイトを含んでいるTLVのデータ部の長さと全体のLLSブロックでメッセージダイジェスト(MD5)ブロックの長さを含んでいます。
Friedman, et al. Experimental [Page 6] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[6ページ]RFC4813OSPF
in bytes (this will always be 16 bytes for MD5). So the AuthLen field will have value of 20.
バイト(これはMD5のためにいつも16バイトになる)で。 それで、AuthLen分野には、20の値があるでしょう。
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 OSPF packet.
Sequence Number分野は簡単な反射攻撃を防ぐのに使用される暗号の一連番号を含んでいます。 LLSブロックが正統であると考えられるために、カリフォルニア-TLVの一連番号はOSPFパケットで一連番号に合わなければなりません。
The AuthData field contains the message digest calculated for the LLS data block.
AuthData分野はLLSデータ・ブロックに計算されたメッセージダイジェストを含んでいます。
The CA-TLV may appear in the LLS block only once. Also, when present, this TLV should be the last in the LLS block.
カリフォルニア-TLVはLLSブロックに一度だけ現れるかもしれません。 また、存在しているとき、このTLVはLLSブロックの最終であるべきです。
3. Backward Compatibility
3. 後方の互換性
The modifications to OSPF packet formats are compatible with standard OSPF because LLS-incapable routers will not consider the extra data after the packet; i.e., the LLS data block will be ignored by routers that do not support the LLS extension.
LLS不可能なルータがパケットの後に付加的なデータを考えないので、OSPFパケット・フォーマットへの変更は標準のOSPFと互換性があります。 すなわち、LLSデータ・ブロックはLLSが拡大であるとサポートしないルータによって無視されるでしょう。
4. Security Considerations
4. セキュリティ問題
The function described in this document does not create any new security issues for the OSPF protocol. The described technique provides the same level of security as the OSPF protocol by allowing LLS data to be authenticated (see Section 2.4.2 for more details).
本書では説明された機能はOSPFプロトコルのために少しの新しい安全保障問題も作成しません。 LLSデータが認証されるのを許容することによってOSPFが議定書を作るとき(その他の詳細に関してセクション2.4.2を見てください)、説明されたテクニックは同じレベルのセキュリティを提供します。
5. IANA Considerations
5. IANA問題
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への拡大を見直さなければなりません。
Following the policies outlined in [RFC2434], LLS type values in the range of 0-32767 are allocated through an IETF consensus action, and LLS type values in the range of 32768-65536 are reserved for private and experimental use.
[RFC2434]に概説された方針に従って、IETFコンセンサス動作で0-32767の範囲のLLSタイプ値を割り当てます、そして、個人的で実験的な使用のために32768-65536の範囲のLLSタイプ値を予約します。
This document assigns LLS types 1 and 2, as follows:
このドキュメントは以下の通りLLSタイプ1と2を選任します:
LLS Type Name Reference
0 Reserved
1 Extended Options [RFC4813]
2 Cryptographic Authentication [RFC4813]
3-32767 Reserved for assignment by the IANA
32768-65535 Private Use
IANA32768-65535兵士のUseによる課題のためにLLS Type Name Reference0Reserved1Extended Options[RFC4813]2Cryptographic Authentication[RFC4813]3-32767Reserved
Friedman, et al. Experimental [Page 7] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[7ページ]RFC4813OSPF
This document also assigns the following bits for the Extended Options bits field in the EO-TLV outlined in Section 2.4.1:
また、このドキュメントはビットがセクション2.4.1に概説されたEO-TLVでさばくExtended Optionsのために以下のビットを割り当てます:
Extended Options Bit Name Reference
0x00000001 LSDB Resynchronization (LR) [RFC4811]
0x00000002 Restart Signal (RS-bit) [RFC4812]
拡張オプションは名前参照0x00000001LSDB Resynchronization(LR)[RFC4811]0x00000002再開信号(RSによって噛み付かれた)に噛み付きました。[RFC4812]
Other Extended Options bits will be allocated through an IETF consensus action.
IETFコンセンサス動作で他のExtended Optionsビットを割り当てるでしょう。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
6.2. Informative References
6.2. 有益な参照
[RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link
State Database (LSDB) Resynchronization", RFC 4811,
February 2007.
[RFC4811] Nguyen、L.、ロイ、A.、およびA.ジニン、「バンドで出ているOSPFは州のデータベース(LSDB)Resynchronizationをリンクする」RFC4811、2007年2月。
[RFC4812] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart
Signaling", RFC 4812, February 2007.
[RFC4812] NguyenとL.とロイ、A.とA.ジニン、「OSPF再開シグナリング」、RFC4812、2007年2月。
Friedman, et al. Experimental [Page 8] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[8ページ]RFC4813OSPF
Appendix A. Acknowledgments
付録A.承認
The authors would like to acknowledge Russ White for his review of this document.
作者は彼のこのドキュメントのレビューのためにラス・ホワイトを承認したがっています。
Authors' Addresses
作者のアドレス
Barry Friedman Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: friedman@cisco.com
西タスマン・Driveバリーフリードマンシスコシステムズ225カリフォルニア95134サンノゼ(米国)はメールされます: friedman@cisco.com
Liem Nguyen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: lhnguyen@cisco.com
西タスマン・DriveリームNguyenシスコシステムズ225カリフォルニア95134サンノゼ(米国)はメールされます: lhnguyen@cisco.com
Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: akr@cisco.com
西タスマン・Drive Abhayロイシスコシステムズ225カリフォルニア95134サンノゼ(米国)はメールされます: akr@cisco.com
Derek Yeung Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: myeung@cisco.com
西タスマン・DriveデリックYeungシスコシステムズ225カリフォルニア95134サンノゼ(米国)はメールされます: myeung@cisco.com
Alex Zinin Alcatel Sunnyvale, CA USA EMail: zinin@psg.com
アレックス・ジニン・アルカテルカリフォルニアサニーベル(米国)はメールされます: zinin@psg.com
Friedman, et al. Experimental [Page 9] RFC 4813 OSPF Link-Local Signaling February 2007
フリードマン、他 シグナリング2007年2月のリンク地方の実験的な[9ページ]RFC4813OSPF
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Friedman, et al. Experimental [Page 10]
フリードマン、他 実験的[10ページ]
一覧
スポンサーリンク
