Network Working Group K. Kompella
Request for Comments: 4940 Juniper Networks
BCP: 130 B. Fenner
Category: Best Current Practice AT&T Labs--Research
June 2007
IANA Considerations for OSPF
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries.
このメモはOSPFレジストリの数を作成し、これらのレジストリ内のコードポイントの割り当てのためのIANAにガイダンスを提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. OSPF Registries .................................................4
2.1. OSPFv2 Options .............................................4
2.2. OSPFv3 Options .............................................4
2.3. OSPF Packet Type (Both v2 and v3) ..........................4
2.3.1. OSPF Authentication Type ............................5
2.4. OSPFv2 Link State (LS) Type ................................5
2.4.1. OSPFv2 Router LSA Link Type .........................5
2.4.2. OSPFv2 Router Properties ............................6
2.5. OSPFv3 LSA Function Code ...................................6
2.5.1. OSPFv3 Prefix Options ...............................6
2.5.2. OSPFv3 Router LSA Link Type .........................6
2.6. OSPFv2 Opaque LSA Type .....................................7
2.6.1. OSPFv2 Grace LSA Top Level TLVs .....................7
3. Acknowledgments .................................................8
4. Security Considerations .........................................8
5. IANA Considerations .............................................8
5.1. OSPFv2 Options Registry ....................................8
5.2. OSPFv3 Options Registry ....................................8
5.3. OSPF Packet Type Registry ..................................9
5.4. OSPF Authentication Type Registry ..........................9
5.5. OSPFv2 Link State Type Registry ............................9
5.6. OSPFv2 Router LSA Link Type Registry ......................10
5.7. OSPFv2 Router Properties Registry .........................10
5.8. OSPFv3 LSA Function Code Registry .........................11
5.9. OSPFv3 Prefix Options Registry ............................12
5.10. OSPFv3 Router LSA Link Type Registry .....................12
5.11. OSPFv2 Opaque LSA Type Registry ..........................13
5.12. OSPFv2 Grace LSA Top Level TLV Registry ..................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................14
This memo defines various OSPF registries for IANA to set up and maintain for OSPF code points. In some cases, this memo defines ranges of code point values within these registries; each such range has a different assignment policy.
IANAは、セットアップおよびOSPFコードポイントを維持するために、このメモは、様々なOSPFレジストリを定義します。いくつかのケースでは、このメモは、これらのレジストリ内のコードポイント値の範囲を定義します。このような各範囲は、異なる割り当てポリシーを有します。
The terms used in describing the assignment policies are as follows:
次のように割り当てポリシーを記述するのに使用される用語は、次のとおりです。
o Standards Action
標準アクションO
o Experimentation
お えｘぺりめんたちおん
o Vendor Private Use
ベンダーのプライベート使用O
o Reserved
O予約
Standards Action means that assignments in that range MUST only be made for Standards Track RFCs (as defined in [RFC2434]).
標準アクションは、その範囲内の割り当てのみ標準化過程のRFC（[RFC2434]で定義されるように）のために作られなければならないことを意味します。
Some of the registries defined below reserve a range of values for Experimentation. For guidelines regarding the use of such values see [RFC3692]. Values from this range MUST NOT be assigned by IANA. Further guidance on the use of the Experimentation range may be found in paragraphs 4, 5, and 6 of [RFC3692]. An implementation MAY choose to not support values from the Experimentation range. In such a case, the protocol data structure with a code point from the Experimentation range is ignored, unless other protocol machinery says how to deal with it. "Ignored" in this context means that the associated data structure is removed from the received packet before further processing, including flooding.
予備実験の値の範囲を下回って定義されたレジストリの一部。そのような値の使用に関するガイドラインについては、[RFC3692]を参照してください。この範囲の値は、IANAによって割り当てられてはなりません。さらなる実験の範囲の使用に関するガイダンス項4に見ることができる、5、及び[RFC3692]の6。実装は、実験の範囲から値をサポートしないことを選ぶかもしれません。他のプロトコル機械がそれに対処する方法を述べていない限り、このような場合には、実験の範囲からコードポイントとプロトコルデータ構造は、無視されます。この文脈において、「無視された」を、関連するデータ構造は、フラッディングを含む更なる処理の前に受信したパケットから取り出されていることを意味します。
Values set aside as Vendor Private Use MUST NOT be assigned by IANA. A protocol data structure whose code point falls in this range MUST have a disambiguating field identifying the Vendor. This identifier consists of four octets of the Vendor's SMI (Structure of Management Information) enterprise code (see [ENTERPRISE-NUMBERS]) in network byte order; the location of this code must be well-defined per data structure. An implementation that encounters a Vendor Private code point SHOULD check whether the enterprise code is one that it recognizes; if so, the implementation MAY choose to interpret the code point and data structure. Otherwise, it SHOULD ignore the code point, unless the protocol machinery says how to deal with the data structure (as defined in the previous paragraph). This allows multiple vendor private extensions to coexist in a network.
ベンダーのプライベート利用とは別に設定された値は、IANAによって割り当てられてはなりません。そのコードポイントがこの範囲に入るプロトコルデータ構造は、ベンダを識別曖昧さ除去フィールドを持たなければなりません。この識別子は、ネットワークバイト順で（[ENTERPRISE-NUMBERS]を参照）ベンダーのSMI（管理情報の構造）企業コードの4つのオクテットで構成されています。このコードの場所は、データ構造ごとに明確に定義されなければなりません。ベンダープライベートコードポイントに遭遇する実装は、企業コードは、それが認識するものであるかどうかをチェックする必要があります。そうならば、実装はコードポイントとデータ構造を解釈するために選ぶかもしれません。プロトコル機械は、（前の段落で定義されている）のデータ構造をどのように扱うかと言う場合を除きそれ以外の場合は、コード・ポイントを無視します。これは、複数のベンダーのプライベート拡張は、ネットワーク内で共存させることができます。
Values in the Reserved range MUST NOT be assigned until a Standards Track or Best Common Practices RFC is published defining the assignment policy for that range. This RFC MUST be the product of the OSPF Working Group; if the OSPF WG is terminated, then it MUST be reviewed by an Expert Reviewer designated by the IESG.
標準化過程やベストプラクティス一般的なRFCは、その範囲の割り当てポリシーを定義し、公開されるまでは予約済み範囲の値を割り当てないでください。このRFCはOSPF作業部会の製品でなければなりません。 OSPF WGが終了した場合、それはIESGによって指定された専門家のレビューで検討されなければなりません。
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]に記載されているように解釈されます。
This section lists the various registries for OSPF protocol code points. Note that some of these are for OSPF, and some are specific to a particular version of OSPF; also, some registries predate this memo.
このセクションでは、OSPFプロトコルのコードポイントのための様々なレジストリを示しています。これらのいくつかはOSPFのためであり、そしていくつかはOSPFの特定のバージョンに固有であることに注意してください。また、いくつかのレジストリはこのメモをさかのぼります。
Registries that are specific to one version of OSPF reflect the version number in the registry name (e.g., OSPFv2 Options). A registry whose name does not mention a version number applies to both OSPFv2 and OSPFv3 (e.g., OSPF Packet Type).
OSPFのバージョンに固有のレジストリは、レジストリ名にバージョン番号を反映する（例えば、OSPFv2のオプション）。名前がレジストリには、バージョン番号が（例えば、OSPFパケットタイプ）のOSPFv2およびOSPFv3の両方に適用されます言及していません。
(Defined in Section A.2 of [RFC2328], updated in Section A.1 of [RFC2370]. See also [RFC3101].)
（[RFC2370]のセクションA.1に更新され、[RFC2328]のセクションA.2に定義されます。また、[RFC3101]を参照してください。）
Assignment policy: Standards Action.
割り当てポリシー：標準アクション。
(Defined in Section A.2 of [RFC2740])
（[RFC2740]のセクションA.2に定義されます）
Assignment policy: Standards Action.
割り当てポリシー：標準アクション。
(Defined in Section A.3.1 of [RFC2328])
（[RFC2328]のセクションA.3.1で定義）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-5 | Already assigned |
| 6-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
(Defined in Section A.3.1 of [RFC2328])
（[RFC2328]のセクションA.3.1で定義）
(Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.)
（注：このレジストリは、IANAによって「OSPF認証コード」と呼ばれています。）
+-------------+-------------------+
| Range | Assignment Policy |
+-------------+-------------------+
| 0-2 | Already assigned |
| 3-247 | Standards Action |
| 248-65519 | Reserved |
| 65520-65535 | Experimentation |
+-------------+-------------------+
(Defined in Section A.4.1 of [RFC2328])
（[RFC2328]のセクションA.4.1で定義）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-11 | Already assigned |
| 12-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
If a new LS Type is documented, the documentation MUST say how the Link State ID is to be filled in, what the flooding scope of the LSA (Link State Advertisement) is, and how backward compatibility is maintained.
新しいLSタイプが文書化されている場合、ドキュメントはリンクステートIDは、LSA（リンクステートアドバタイズメント）の氾濫範囲が何であるか、に充填することで、どのように、下位互換性を維持する方法を言わなければなりません。
(Defined in Section A.4.2 of [RFC2328])
（[RFC2328]のセクションA.4.2で定義）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor.
ベンダーを識別するために、企業コードのためのスペースがないとベンダーのプライベート利用のための範囲は、ありません。
No Experimental range is defined, due to possible backwards compatibility issues.
実験的範囲は、可能な後方互換性の問題のために定義されていません。
If a new Router LSA Link Type is documented, the documentation SHOULD say how the Link State ID, Link ID, and Link Data fields are to be filled in, and how backward compatibility is maintained.
新しいルータLSAリンクタイプが文書化されている場合は、ドキュメントが言うべきかリンクステートID、リンクID、およびリンクデータフィールドが記入されると、どのように下位互換性が維持されています。
(Defined in Section A.4.2 of [RFC2328], updated in [RFC3101])
（[RFC3101]に更新され、[RFC2328]のセクションA.4.2で定義）
This 8-bit field in the Router LSA is unnamed; it is the field immediately following the Router LSA length.
ルータLSAにこの8ビットのフィールドは名前です。それは、ルータLSAの長さの直後のフィールドです。
Assignment policy: Standards Action.
割り当てポリシー：標準アクション。
This registry is created by [OSPF-CAP]. This document provides the values to be populated for values defined in Section A.4.2.1 of [RFC2740].
このレジストリは、[OSPF-CAP]によって作成されます。この文書では、値は[RFC2740]のセクションA.4.2.1で定義された値のために移入することが提供されます。
(Defined in Section A.4.1.1 of [RFC2740])
（[RFC2740]のセクションA.4.1.1で定義）
Assignment policy: Standards Action.
割り当てポリシー：標準アクション。
(Defined in Section A.4.3 of [RFC2740])
（[RFC2740]のセクションA.4.3で定義）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor.
ベンダーを識別するために、企業コードのためのスペースがないとベンダーのプライベート利用のための範囲は、ありません。
No Experimental range is defined, due to possible backwards compatibility issues.
実験的範囲は、可能な後方互換性の問題のために定義されていません。
(Defined in Section A.2 of [RFC2370])
（[RFC2370]のセクションA.2に定義されます）
(Note: this registry is called "OSPF Opaque LSA Option" by IANA. See also [RFC3630].)
（注：このレジストリは、IANAによる "OSPF Opaque LSAオプション" と呼ばれても、[RFC3630]を参照してください。）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-127 | Standards Action |
| 128-247 | Reserved |
| 248-251 | Experimentation |
| 252-255 | Vendor Private Use |
+---------+--------------------+
In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private Use range, the first four octets of Opaque Information MUST be the Vendor enterprise code.
ベンダープライベート使用範囲内不透明LSAタイプとOSPFv2の不透明LSAでは、不透明情報の最初の4つのオクテットは、ベンダーのエンタープライズコードでなければなりません。
A document defining a new Standards Track Opaque LSA with TLVs and sub-TLVs MUST describe ranges and assignment policies for these TLVs.
TLVのサブTLVを持つ新しい標準化過程の不透明LSAを定義するドキュメントでは、これらのTLVのための範囲と割り当てポリシーを説明しなければなりません。
(Defined in Appendix A of [RFC3623])
（[RFC3623]の付録Aで定義されます）
+-------------+--------------------+
| Range | Assignment Policy |
+-------------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-255 | Standards Action |
| 256-65519 | Reserved |
| 65520-65527 | Experimentation |
| 65528-65535 | Vendor Private Use |
+-------------+--------------------+
In a Grace LSA, if a top-level TLV has a Type from the Vendor Private Use range, the Length MUST be at least four, and the first four octets of the Value field MUST be the Vendor enterprise code.
最上位のTLVベンダープライベート使用範囲から型を有する場合にグレースLSAにおいては、長さが少なくとも4でなければなりません、及び値フィールドの最初の4つのオクテットは、ベンダ企業コードでなければなりません。
Many thanks to Adrian Farrel and Acee Lindem for their review and comments.
彼らのレビューとコメントのためのエードリアンファレルとACEE Lindemに感謝します。
The lack of adequate IANA guidelines may be viewed as an avenue for Denial of Service attacks on IETF protocols (in this case, OSPFv2 and OSPFv3), and on the IETF Standards Process in general. This memo attempts to close this loophole for OSPFv2 and OSPFv3.
十分なIANAガイドラインの欠如は、IETFプロトコルのサービス拒否攻撃（この場合は、OSPFv2のおよびOSPFv3の）のための道として、そして一般的にはIETF標準化過程の上に見ることができます。このメモは、OSPFv2のとOSPFv3のため、この抜け穴を閉じよう。
Authors contemplating extensions to OSPF SHOULD examine such extensions carefully, and consider whether new registries are needed, and if so, allocation policies within each registry.
OSPFへの拡張を検討して著者は、慎重にそのような拡張を検討し、新しいレジストリが必要かどうかを検討し、各レジストリ内のそうであれば、割り当てポリシーべきです。
This document specifies assignment policy for several existing IANA registries and creates several more.
この文書では、いくつかの既存のIANAレジストリの割り当てポリシーを指定し、いくつかのより多くを作成します。
Section 2.1 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 6 are already assigned. The initial registry contents are given below.
2.1節では、「標準化アクション」として、このレジストリからのビットの割り当てのポリシーを定義します。そこだけ8ビットは、この分野であり、そして6がすでに割り当てられています。最初のレジストリの内容は以下の通りです。
OSPFv2 Options Registry (Section 2.1)
OSPFv2のオプションレジストリ（2.1節）
Value Description Reference
----- ----------- ---------
0x02 E-bit [RFC2328]
0x04 MC-bit [RFC1584]
0x08 N/P-bit [RFC3101]
0x10 Reserved
0x20 DC-bit [RFC1793]
0x40 O-bit [RFC2370]
Section 2.2 defines the policy for allocation of bits from this registry as "Standards Action". There are 24 bits in this field, and 6 are assigned. The initial registry contents are given below.
2.2節では、「標準化アクション」として、このレジストリからのビットの割り当てのポリシーを定義します。そこの24ビットは、この分野であり、そして6が割り当てられています。最初のレジストリの内容は以下の通りです。
OSPFv3 Options Registry (Section 2.2)
OSPFv3のオプションレジストリ（2.2節）
Value Description Reference
-------- ----------- ---------
0x000001 V6-bit [RFC2740]
0x000002 E-bit [RFC2328]
0x000004 MC-bit [RFC1584]
0x000008 N-bit [RFC3101]
0x000010 R-Bit [RFC2740]
0x000020 DC-bit [RFC1793]
Section 2.3 defines the policy for allocation of values from this registry for different ranges. The initial registry contents are given below.
2.3節では、異なる範囲のために、このレジストリから値の割り当てのポリシーを定義します。最初のレジストリの内容は以下の通りです。
OSPF Packet Type (Section 2.3)
OSPFパケットタイプ（2.3節）
Value Description Reference
----- -------------------- ---------
1 Hello [RFC2328]
2 Database Description [RFC2328]
3 Link State Request [RFC2328]
4 Link State Update [RFC2328]
5 Link State Ack [RFC2328]
This registry already exists at IANA, called "ospf-authentication-codes". Section 2.3.1 defines the policy for allocation from this registry for different ranges.
このレジストリは、すでに「OSPF-認証コード」と呼ばれ、IANAに存在します。 2.3.1項では、異なる範囲のために、このレジストリから割り当てのポリシーを定義します。
Section 2.4 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
2.4節では、異なる範囲のために、このレジストリから割り当てのポリシーを定義します。最初のレジストリの内容は以下の通りです。
OSPFv2 Link State (LS) Type (Section 2.4)
OSPFv2のリンクステート（LS）タイプ（2.4節）
Value Description Reference
----- ------------------------ ---------
1 Router-LSA [RFC2328]
2 Network-LSA [RFC2328]
3 Summary-LSA (IP network) [RFC2328]
4 Summary-LSA (ASBR) [RFC2328]
5 AS-external-LSA [RFC2328]
6 Group-membership-LSA [RFC1584]
7 NSSA AS-external LSA [RFC3101]
8 Reserved
9 Link-local Opaque LSA [RFC2370]
10 Area-local Opaque LSA [RFC2370]
11 Opaque LSA [RFC2370]
Section 2.4.1 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
2.4.1項では、異なる範囲のために、このレジストリから割り当てのポリシーを定義します。最初のレジストリの内容は以下の通りです。
OSPFv2 Router LSA Link Type (Section 2.4.1)
OSPFv2のルータLSAのリンクタイプ（2.4.1項）
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2328]
2 Transit Network [RFC2328]
3 Stub Network [RFC2328]
4 Virtual Link [RFC2328]
Section 2.4.2 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 5 are already assigned. The initial registry contents are given below.
2.4.2項では、「標準化アクション」として、このレジストリからのビットの割り当てのポリシーを定義します。そこだけ8ビットは、この分野であり、そして5がすでに割り当てられています。最初のレジストリの内容は以下の通りです。
OSPFv2 Options Registry (Section 2.1)
OSPFv2のオプションレジストリ（2.1節）
Value Description Reference
----- ----------- ---------
0x01 B-bit [RFC2328]
0x02 W-bit [RFC2328]
0x04 V-bit [RFC2328]
0x08 W-bit [RFC1584]
0x10 Nt-bit [RFC3101]
This registry is created by [OSPF-CAP], which also defines the registration policy. This section contains values that belong in this registry that were defined by [RFC2740].
このレジストリはまた、登録ポリシーを定義し、[OSPF-CAP]によって作成されます。このセクションでは、[RFC2740]で定義されていた、このレジストリに属している値が含まれています。
As defined in [RFC2740], the first 3 bits of the LSA Function
Code are the U, S1, and S2 bits. A given function code implies a
specific setting for the U, S1, and S2 bits as shown in the "LS Type"
column.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The U bit indicates how the LSA should be handled by a router which does not recognize the LSA's function code. Its values are:
Uビットは、LSAは、LSAの機能コードを認識しないルータによってどのように処理すべきかを示しています。その値は次のとおりです。
U-bit LSA Handling
----- ----------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA, as if type understood
The S1 and S2 bits indicate the flooding scope of the LSA. The values are:
S1とS2のビットは、LSAの氾濫範囲を示しています。値は次のとおりです。
S1 S2 Flooding Scope
-- -- --------------------------------------------------------------
0 0 Link-Local Scoping. Flooded only on link it is originated on
0 1 Area Scoping. Flooded to all routers in the originating area
1 0 AS Scoping. Flooded to all routers in the AS
1 1 Reserved
The initial registry contents are given below.
最初のレジストリの内容は以下の通りです。
OSPFv3 LSA Function Code (Section 2.5)
OSPFv3のLSAのファンクションコード（2.5節）
LSA Function Code LS Type Description Reference
----------------- ------- --------------------- ---------
1 0x2001 Router-LSA [RFC2740]
2 0x2002 Network-LSA [RFC2740]
3 0x2003 Inter-Area-Prefix-LSA [RFC2740]
4 0x2004 Inter-Area-Router-LSA [RFC2740]
5 0x4005 AS-External-LSA [RFC2740]
6 0x2006 Group-membership-LSA [RFC2740]
7 0x2007 Type-7-LSA [RFC2740]
8 0x0008 Link-LSA [RFC2740]
9 0x2009 Intra-Area-Prefix-LSA [RFC2740]
Section 2.5.1 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 4 are already assigned. The initial registry contents are given below.
2.5.1項では、「標準化アクション」として、このレジストリからのビットの割り当てのポリシーを定義します。そこだけ8ビットは、この分野であり、そして4がすでに割り当てられています。最初のレジストリの内容は以下の通りです。
OSPFv3 Prefix Options Registry (Section 2.5.1)
OSPFv3のプレフィックスオプションレジストリ（2.5.1項）
Value Description Reference
----- ----------- ---------
0x01 NU-bit [RFC2740]
0x02 LA-bit [RFC2740]
0x04 MC-bit [RFC2740]
0x08 P-bit [RFC2740]
Section 2.5.2 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
第2.5.2項は、異なる範囲のために、このレジストリから割り当てのポリシーを定義します。最初のレジストリの内容は以下の通りです。
OSPFv3 Router LSA Link Type (Section 2.5.2)
OSPFv3のルータLSAのリンクタイプ（2.5.2項）
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2740]
2 Transit Network [RFC2740]
3 Reserved [RFC2740]
4 Virtual Link [RFC2740]
This registry already exists at IANA, called "ospf-opaque-types". Section 2.6 defines the policy for allocation from this registry for different ranges.
このレジストリは、すでに「OSPF-不透明タイプ」と呼ばれ、IANAに存在します。 2.6節では、異なる範囲のために、このレジストリから割り当てのポリシーを定義します。
Section 2.6.1 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
2.6.1項では、異なる範囲のために、このレジストリから割り当てのポリシーを定義します。最初のレジストリの内容は以下の通りです。
OSPFv2 Grace LSA Top Level TLV (Section 2.6.1)
OSPFv2のグレースLSAトップレベルTLV（2.6.1項）
Value Description Reference
----- ----------------------- ---------
1 Grace Period [RFC3623]
2 Graceful Restart reason [RFC3623]
3 IP Interface Address [RFC3623]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[RFC1584]モイ、J.、 "OSPFへのマルチキャスト拡張機能"、RFC 1584、1994年3月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[RFC1793]モイ、J.、 "オンデマンド・サーキットをサポートするためのOSPFの拡張"、RFC 1793、1995年4月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[RFC2370] Coltun、R.、 "OSPF Opaque LSAオプション"、RFC 2370、1998年7月。
[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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[RFC3101]マーフィー、P.、 "OSPFない準スタブエリア（NSSA）オプション"、RFC 3101、2003年1月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623]モイ、J.、Pillay-Esnault、P.、およびA. Lindem、 "優雅なOSPF再起動"、RFC 3623、2003年11月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[ENTERPRISE-NUMBERS] "PRIVATE ENTERPRISE NUMBERS", http://www.iana.org/assignments/enterprise-numbers.
[ENTERPRISE-NUMBERS "民間企業番号"、http://www.iana.org/assignments/enterprise-numbers。
[OSPF-CAP] Lindem, A., "Extensions to OSPF for Advertising Optional Router Capabilities", Work in Progress, May 2007.
[OSPF-CAP] Lindem、A.、 "広告オプションのルータの機能のためのOSPFへの拡張"、進歩、2007年5月での作業。
Authors' Addresses
著者のアドレス
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Kireeti Kompellaジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089米国
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Bill Fenner AT&T Labs--Research 1 River Oaks Place San Jose, CA 95134 US
ビルフェナーAT＆T研究所 - 研究1リバーオークス置き、サンノゼ、CA 95134米国
Phone: +1 (408) 493-8505 EMail: fenner@research.att.com
電話：+1（408）493-8505 Eメール：fenner@research.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。