RFC4940 日本語訳
4940 IANA Considerations for OSPF. K. Kompella, B. Fenner. July 2007. (Format: TXT=27595 bytes) (Also BCP0130) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
Kompellaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4940年の杜松はBCPをネットワークでつなぎます: 130B.フェナーカテゴリ: 最も良い現在の習慣AT&T研究室--研究2007年6月
IANA Considerations for OSPF
OSPFのためのIANA問題
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).
IETFが信じる著作権(C)(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に供給します。
Kompella & Fenner Best Current Practice [Page 1] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[1ページ]RFC4940IANA問題
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
1. 序論…3 1.1. このドキュメントで中古のコンベンション…4 2. OSPF登録…4 2.1. OSPFv2オプション…4 2.2. OSPFv3オプション…4 2.3. OSPF Packet Type(v2とv3の両方)…4 2.3.1. OSPF認証タイプ…5 2.4. OSPFv2リンク州の(LS)はタイプします…5 2.4.1. OSPFv2ルータLSAはタイプをリンクします…5 2.4.2. OSPFv2ルータの特性…6 2.5. OSPFv3 LSA機能コード…6 2.5.1. OSPFv3はオプションを前に置きます…6 2.5.2. OSPFv3ルータLSAはタイプをリンクします…6 2.6. OSPFv2の不透明なLSAはタイプします…7 2.6.1. OSPFv2優雅LSAはレベルTLVsを上回っています…7 3. 承認…8 4. セキュリティ問題…8 5. IANA問題…8 5.1. OSPFv2オプション登録…8 5.2. OSPFv3オプション登録…8 5.3. OSPFパケットタイプ登録…9 5.4. OSPF認証タイプ登録…9 5.5. OSPFv2は州のタイプ登録をリンクします…9 5.6. OSPFv2ルータLSAはタイプ登録をリンクします…10 5.7. OSPFv2ルータ特性の登録…10 5.8. OSPFv3 LSA機能コード登録…11 5.9. OSPFv3はオプション登録を前に置きます…12 5.10. OSPFv3ルータLSAはタイプ登録をリンクします…12 5.11. OSPFv2の不透明なLSAは登録をタイプします…13 5.12. OSPFv2優雅LSAは平らなTLV登録を付けます…13 6. 参照…13 6.1. 標準の参照…13 6.2. 有益な参照…14
Kompella & Fenner Best Current Practice [Page 2] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[2ページ]RFC4940IANA問題
1. Introduction
1. 序論
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 実験
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]).
規格Actionは、Standards Track RFCsのためにその範囲の課題をするだけでよいことを意味します([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.
登録のいくつかがExperimentationのために蓄えの下でさまざまな値を定義しました。 そのような値の使用に関するガイドラインに関しては、[RFC3692]を見てください。 この範囲からの値はIANAによって割り当てられてはいけません。 Experimentation範囲の使用のさらなる指導はパラグラフ4、5、および6の[RFC3692]で見つけられるかもしれません。 実装は、Experimentation範囲から値をサポートしないのを選ぶかもしれません。 このような場合には、Experimentation範囲からのコード・ポイントがあるプロトコルデータ構造は無視されます、他のプロトコル機械がそれに対処する方法を言わない場合。 浸水するのを含んでいて、関連データ構造がさらに処理する前に容認されたパケットから取り外されるのをこの文脈手段で「無視しました」。
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.
Vendor兵士のUseがIANAによって割り当てられてはいけないとき、値はかたわらに置かれます。 コード・ポイントがこの範囲に下がるプロトコルデータ構造はVendorを特定するあいまいさを除く分野を持たなければなりません。 この識別子はネットワークバイトオーダーにおける、VendorのSMI(Management情報の構造)企業コード([エンタープライズ-民数記]を見る)の4つの八重奏から成ります。 このコードの位置はデータ構造単位で明確であるに違いありません。 企業コードがそれが認識するものであるか否かに関係なく、Vendor兵士のコードポイントSHOULDチェックに遭遇する実装。 そうだとすれば、実装は、コード・ポイントとデータ構造を解釈するのを選ぶかもしれません。 そうでなければ、それ、SHOULDはコード・ポイントを無視します、プロトコル機械がデータ構造に対処する方法を言わない場合(前のパラグラフで定義されるように)。 これで、複数のベンダーの個人的な拡大がネットワークで共存します。
Values in the Reserved range MUST NOT be assigned until a Standards Track or Best Common Practices RFC is published defining the
Standards TrackかBest Common Practices RFCが発行された定義になるまでReserved範囲の値を割り当ててはいけません。
Kompella & Fenner Best Current Practice [Page 3] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[3ページ]RFC4940IANA問題
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 MUST、OSPF作業部会の製品になってください。 OSPF WGが終えられるなら、IESGによって指定されたExpert Reviewerはそれを見直さなければなりません。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. OSPF Registries
2. OSPF登録
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の1つのバージョンに特定の登録は登録名(例えば、OSPFv2 Options)にバージョン番号を反映します。 名前がバージョン番号について言及しない登録はOSPFv2とOSPFv3の両方(例えば、OSPF Packet Type)に適用されます。
2.1. OSPFv2 Options
2.1. OSPFv2オプション
(Defined in Section A.2 of [RFC2328], updated in Section A.1 of [RFC2370]. See also [RFC3101].)
([RFC2370] See[RFC3101]についてもセクションA.1でアップデートされた[RFC2328]のセクションA.2では、定義されます。)
Assignment policy: Standards Action.
課題方針: 規格動作。
2.2. OSPFv3 Options
2.2. OSPFv3オプション
(Defined in Section A.2 of [RFC2740])
([RFC2740]のセクションA.2では、定義されます)
Assignment policy: Standards Action.
課題方針: 規格動作。
2.3. OSPF Packet Type (Both v2 and v3)
2.3. OSPFパケットタイプ(v2とv3の両方)
(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 |
+---------+--------------------+
+---------+--------------------+ | 範囲| 課題方針| +---------+--------------------+ | 0 | 割り当てられないように| | 1-5 | 既に割り当てられます。| | 6-127 | 規格動作| | 128-255 | 予約されます。| +---------+--------------------+
Kompella & Fenner Best Current Practice [Page 4] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[4ページ]RFC4940IANA問題
2.3.1. OSPF Authentication Type
2.3.1. OSPF認証タイプ
(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 |
+-------------+-------------------+
+-------------+-------------------+ | 範囲| 課題方針| +-------------+-------------------+ | 0-2 | 既に割り当てられます。| | 3-247 | 規格動作| | 248-65519 | 予約されます。| | 65520-65535 | 実験| +-------------+-------------------+
2.4. OSPFv2 Link State (LS) Type
2.4. OSPFv2リンク州の(LS)はタイプします。
(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 |
+---------+--------------------+
+---------+--------------------+ | 範囲| 課題方針| +---------+--------------------+ | 0 | 割り当てられないように| | 1-11 | 既に割り当てられます。| | 12-127 | 規格動作| | 128-255 | 予約されます。| +---------+--------------------+
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 Typeが記録されるなら、ドキュメンテーションには、Link州IDがどのように記入されることになっているか、そして、LSA(リンク州Advertisement)の氾濫範囲が何であるか、そして、互換性がどれくらい後方であるかを維持されていた状態で書かなければなりません。
2.4.1. OSPFv2 Router LSA Link Type
2.4.1. OSPFv2ルータ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 |
+---------+--------------------+
+---------+--------------------+ | 範囲| 課題方針| +---------+--------------------+ | 0 | 割り当てられないように| | 1-4 | 既に割り当てられます。| | 5-127 | 規格動作| | 128-255 | 予約されます。| +---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor.
Vendor兵士のUseのための範囲が全くありません、企業コードがVendorを特定するようにスペースが全くないとき。
Kompella & Fenner Best Current Practice [Page 5] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[5ページ]RFC4940IANA問題
No Experimental range is defined, due to possible backwards compatibility issues.
Experimental範囲は全く定義されないで、後方に可能への支払われるべきものは互換性の問題です。
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.
新しいRouter LSA Link Typeが記録されるなら、ドキュメンテーションSHOULDはLink州Link ID(ID)、およびLink Data分野がどのように記入されるかことであり、互換性がどれくらい後方であるかを維持されていた状態で言います。
2.4.2. OSPFv2 Router Properties
2.4.2. OSPFv2ルータの特性
(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.
Router LSAのこの8ビットの分野は無名です。 それはすぐにRouter LSAの長さに続く分野です。
Assignment policy: Standards Action.
課題方針: 規格動作。
2.5. OSPFv3 LSA Function Code
2.5. OSPFv3 LSA機能コード
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で定義された値のために居住されるために値を提供します。
2.5.1. OSPFv3 Prefix Options
2.5.1. OSPFv3接頭語オプション
(Defined in Section A.4.1.1 of [RFC2740])
([RFC2740]のセクションA.4.1.1では、定義されます)
Assignment policy: Standards Action.
課題方針: 規格動作。
2.5.2. OSPFv3 Router LSA Link Type
2.5.2. OSPFv3ルータLSAリンク型
(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 |
+---------+--------------------+
+---------+--------------------+ | 範囲| 課題方針| +---------+--------------------+ | 0 | 割り当てられないように| | 1-4 | 既に割り当てられます。| | 5-127 | 規格動作| | 128-255 | 予約されます。| +---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor.
Vendor兵士のUseのための範囲が全くありません、企業コードがVendorを特定するようにスペースが全くないとき。
No Experimental range is defined, due to possible backwards compatibility issues.
Experimental範囲は全く定義されないで、後方に可能への支払われるべきものは互換性の問題です。
Kompella & Fenner Best Current Practice [Page 6] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[6ページ]RFC4940IANA問題
2.6. OSPFv2 Opaque LSA Type
2.6. OSPFv2の不透明なLSAはタイプします。
(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の不明瞭な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 |
+---------+--------------------+
+---------+--------------------+ | 範囲| 課題方針| +---------+--------------------+ | 0 | 割り当てられないように| | 1-3 | 既に割り当てられます。| | 4-127 | 規格動作| | 128-247 | 予約されます。| | 248-251 | 実験| | 252-255 | ベンダー私用| +---------+--------------------+
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.
Opaque LSA TypeがVendor兵士のUse範囲にあるOSPFv2 Opaque LSAでは、Opaque情報の最初の4つの八重奏がVendor企業コードであるに違いありません。
A document defining a new Standards Track Opaque LSA with TLVs and sub-TLVs MUST describe ranges and assignment policies for these TLVs.
TLVsと新しいStandards Track Opaque LSAとサブTLVsを定義するドキュメントはこれらのTLVsのために範囲と課題方針を説明しなければなりません。
2.6.1. OSPFv2 Grace LSA Top Level TLVs
2.6.1. OSPFv2の優雅LSAのトップレベルTLVs
(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 |
+-------------+--------------------+
+-------------+--------------------+ | 範囲| 課題方針| +-------------+--------------------+ | 0 | 割り当てられないように| | 1-3 | 既に割り当てられます。| | 4-255 | 規格動作| | 256-65519 | 予約されます。| | 65520-65527 | 実験| | 65528-65535 | ベンダー私用| +-------------+--------------------+
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.
グレースLSAでは、トップレベルTLVにVendor兵士のUse範囲からのTypeがあるなら、Lengthは少なくとも4歳であるに違いありません、そして、Value分野の最初の4つの八重奏がVendor企業コードであるに違いありません。
Kompella & Fenner Best Current Practice [Page 7] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[7ページ]RFC4940IANA問題
3. Acknowledgments
3. 承認
Many thanks to Adrian Farrel and Acee Lindem for their review and comments.
彼らのレビューとコメントのためにエードリアン・ファレルとAcee Lindemをありがとうございます。
4. Security Considerations
4. セキュリティ問題
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 Standards Processの上で見なされるかもしれません。 このメモは、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 SHOULDに拡大を熟考する作者が、慎重にそのような拡大を調べて、新しい登録が必要であるかどうか考える、そうだとすれば、各登録の中の配分方針。
5. IANA Considerations
5. IANA問題
This document specifies assignment policy for several existing IANA registries and creates several more.
このドキュメントは、いくつかの既存のIANA登録に課題方針を指定して、さらに数個を作成します。
5.1. OSPFv2 Options Registry
5.1. OSPFv2オプション登録
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]
値の記述参照----- ----------- --------- 0×02 Pで[RFC1584電子ビット[RFC2328]0x04ビット]N M.C.0x08/噛み付いている[RFC3101]0x10は0×20DC-ビット[RFC1793]0×40O-ビットを予約しました。[RFC2370]
5.2. OSPFv3 Options Registry
5.2. OSPFv3オプション登録
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は割り当てられます。 初期の登録内容を以下に与えます。
Kompella & Fenner Best Current Practice [Page 8] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[8ページ]RFC4940IANA問題
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]
値の記述参照-------- ----------- --------- 0×000001 [RFC1584V6-ビット[RFC2740]0x000002電子ビット[RFC2328]0x000004ビット]N-ビット]R-Bit]M.C.0x000008は0x000010 0x000020[RFC3101[RFC2740DC噛み付きました。[RFC1793]
5.3. OSPF Packet Type Registry
5.3. OSPFパケットタイプ登録
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]
値の記述参照----- -------------------- --------- 1 こんにちは、[RFC2328]2データベース記述[RFC2328]3リンク州の要求[RFC2328]4リンク州のアップデート[RFC2328]5リンク州のAck[RFC2328]
5.4. OSPF Authentication Type Registry
5.4. OSPF認証タイプ登録
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 この登録と異なった範囲と配分のための方針を定義します。
5.5. OSPFv2 Link State Type Registry
5.5. OSPFv2リンク州のタイプ登録
Section 2.4 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
セクション2.4はこの登録と異なった範囲と配分のための方針を定義します。 初期の登録内容を以下に与えます。
Kompella & Fenner Best Current Practice [Page 9] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[9ページ]RFC4940IANA問題
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]
値の記述参照----- ------------------------ --------- 1ルータ-LSA[RFC2328]2Network-LSA[RFC2328]3Summary-LSA(IPネットワーク)[RFC2328]4Summary-LSA(ASBR)[RFC2328]5ASの外部のLSA[RFC2328]6、Group会員資格LSA、[RFC1584]7NSSA AS外部のLSA[RFC3101]8Reserved9のLink地方のOpaque LSA[RFC2370]10Area地方のOpaque LSA[RFC2370]11Opaque LSA[RFC2370]
5.6. OSPFv2 Router LSA Link Type Registry
5.6. OSPFv2ルータLSAリンク型登録
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]
値の記述参照----- ------------------------------------------- --------- 1 別のルータ[RFC2328]2Transit Network[RFC2328]3Stub Network[RFC2328]4Virtual Linkとの指すポイント接続[RFC2328]
5.7. OSPFv2 Router Properties Registry
5.7. OSPFv2ルータ特性の登録
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]
値の記述参照----- ----------- --------- 0×01 B-ビット[RFC2328]0x02W-ビット[RFC2328]0x04V-ビット[RFC2328]0x08W-ビット[RFC1584]0x10はNt噛み付きました。[RFC3101]
Kompella & Fenner Best Current Practice [Page 10] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[10ページ]RFC4940IANA問題
5.8. OSPFv3 LSA Function Code Registry
5.8. OSPFv3 LSA機能コード登録
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
[RFC2740]で定義されるように、LSA Function Codeの最初の3ビットは、Uと、S1と、S2ビットです。 与えられた機能コードは「LSタイプ」コラムに示されるように特定の設定をU、S1、およびS2ビット含意します。 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機能コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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
U-ビットLSA取り扱い----- ---------------------------------------------------- 0は、まるでリンク地方の氾濫範囲1ストアを持っているかのようにLSAを扱って、LSAをあふれさせます、まるでタイプが分かるかのように
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
S1 S2氾濫範囲--、---------------------------------------------------------------- 0 0、リンク地方の見ること。 リンクだけの上にあふれて、それは0 1Area Scopingで溯源されます。 起因している領域1 0AS Scopingのすべてのルータに浸水しました。 AS1 1Reservedのすべてのルータに浸水します。
The initial registry contents are given below.
初期の登録内容を以下に与えます。
Kompella & Fenner Best Current Practice [Page 11] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[11ページ]RFC4940IANA問題
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]
LSA機能コードLS型記述参照----------------- ------- --------------------- --------- 1つの0×2001ルータ-LSA[RFC2740]2 0×2002ネットワーク-LSA[RFC2740]3 0×2003相互領域接頭語LSA[RFC2740]4 0×2004相互領域ルータLSA[RFC2740]5 0×4005、外部のLSA、会員資格LSAを分類している[RFC2740]6 0×2007 0×0008リンク-LSA[RFC2740]9 0×2006[RFC2740]7タイプ-7-LSA[RFC2740]8 0×2009、イントラ領域接頭語LSA[RFC2740]
5.9. OSPFv3 Prefix Options Registry
5.9. OSPFv3接頭語オプション登録
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]
値の記述参照----- ----------- --------- 0×01 [RFC2740ν-ビット[RFC2740]0x02LA-ビット[RFC2740]0x04ビット]M.C.0x08はPで噛み付きました。[RFC2740]
5.10. OSPFv3 Router LSA Link Type Registry
5.10. OSPFv3ルータLSAリンク型登録
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]
値の記述参照----- ------------------------------------------- --------- 1 別のルータ[RFC2740]2Transit Network[RFC2740]3Reserved[RFC2740]4Virtual Linkとの指すポイント接続[RFC2740]
Kompella & Fenner Best Current Practice [Page 12] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[12ページ]RFC4940IANA問題
5.11. OSPFv2 Opaque LSA Type Registry
5.11. OSPFv2の不透明なLSAは登録をタイプします。
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はこの登録と異なった範囲と配分のための方針を定義します。
5.12. OSPFv2 Grace LSA Top Level TLV Registry
5.12. OSPFv2の優雅LSAの先頭の平らなTLV登録
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]
値の記述参照----- ----------------------- --------- 1 優雅Period[RFC3623]2Graceful Restart理由[RFC3623]3IP Interface Address[RFC3623]
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[RFC1584] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995.
[RFC1793] Moy、J.、「要求が回路であるとサポートするためにOSPFを広げています」、RFC1793、1995年4月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998.
[RFC2370]Coltun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2370。
[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月)。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[RFC2740] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003.
[RFC3101] マーフィー、P.、「OSPFしたがって、短く太くない領域(NSSA)オプション」、RFC3101、2003年1月。
Kompella & Fenner Best Current Practice [Page 13] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[13ページ]RFC4940IANA問題
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", RFC 3623, November 2003.
[RFC3623] MoyとJ.とPillay-Esnault、P.とA.Lindem、「優雅なOSPFは再開する」RFC3623、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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計するトラフィック、RFC3630、2003年9月。」
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
6.2. Informative References
6.2. 有益な参照
[ENTERPRISE-NUMBERS]
"PRIVATE ENTERPRISE NUMBERS",
http://www.iana.org/assignments/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.
A.、「広告の任意のルータ能力のためのOSPFへの拡大」という[OSPF-キャップ]Lindemは進歩、2007年5月に働いています。
Authors' Addresses
作者のアドレス
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Kireeti Kompella杜松は1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア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川のオークは米国でサンノゼ、カリフォルニア 95134を置きます。
Phone: +1 (408) 493-8505 EMail: fenner@research.att.com
以下に電話をしてください。 +1 (408) 493-8505 メールしてください: fenner@research.att.com
Kompella & Fenner Best Current Practice [Page 14] RFC 4940 IANA Considerations for OSPF June 2007
OSPF2007年6月のためのKompellaとフェナー最も良い現在の習慣[14ページ]RFC4940IANA問題
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機能のための基金は現在、インターネット協会によって提供されます。
Kompella & Fenner Best Current Practice [Page 15]
KompellaとフェナーBest現在の習慣[15ページ]
一覧
スポンサーリンク
