RFC5175 日本語訳
5175 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R.Hinden. March 2008. (Format: TXT=12463 bytes) (Obsoletes RFC5075) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Haberman, Ed.
Request for Comments: 5175 JHU APL
Obsoletes: 5075 R. Hinden
Category: Standards Track Nokia
March 2008
ワーキンググループのB.ハーバーマン、エドをネットワークでつないでください。コメントのために以下を要求してください。 5175年のJHU APLは以下を時代遅れにします。 5075年のR.Hindenカテゴリ: 2008年の標準化過程ノキアの行進
IPv6 Router Advertisement Flags Option
IPv6ルータ通知はオプションに旗を揚げさせます。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available.
IPv6 NeighborディスカバリーのRouter Advertisementメッセージは単一のビット旗のために予約された8ビットの分野を含んでいます。 いくつかのプロトコルがこの分野で旗を予約しました、そして、他のものは野原を枯渇させるように十分な数の旗を予約するのを準備しています。 このドキュメントはフラグビットの有効な数を広くするRouter Advertisementメッセージとオプションを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Current Router Advertisement Flags . . . . . . . . . . . . . . 2
4. Flags Expansion Option . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 現在のルータ通知は.2 4に旗を揚げさせます。 拡大オプション. . . . . . . . . . . . . . . . . . . . 3 5に旗を揚げさせます。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 4 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 5 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 6
Haberman & Hinden Standards Track [Page 1] RFC 5175 IPv6 RA Flags Options March 2008
ハーバーマンとHinden標準化過程[1ページ]RFC5175IPv6 RAは2008年のオプション行進のときに弛みます。
1. Introduction
1. 序論
The IPv6 Neighbor Discovery Protocol's (NDP) [RFC4861] Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field.
IPv6 Neighborディスカバリープロトコル(NDP)の[RFC4861]ルータAdvertisementメッセージは単一のビット旗のために予約された8ビットの分野を含んでいます。 いくつかのプロトコルがこの分野で旗を予約しました、そして、他のものは野原を枯渇させるように十分な数の旗を予約するのを準備しています。
This document defines an option for the Router Advertisement message that expands the available number of flag bits by adding an additional 48 flag bits to NDP messages.
このドキュメントは追加48個のフラグビットをNDPメッセージに追加することによってフラグビットの有効な数を広くするRouter Advertisementメッセージのためのオプションを定義します。
2. Terminology
2. 用語
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Current Router Advertisement Flags
3. 現在のルータ通知旗
Currently, the NDP Router Advertisement message contains the following one-bit flags defined in published RFCs:
現在、NDP Router Advertisementメッセージは発行されたRFCsで定義された以下の1ビットの旗を含みます:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|R|R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |M|O|H|Prf|P|R|R| +-+-+-+-+-+-+-+-+
Figure 1: Router Advertisement Flags
図1: ルータ通知旗
o M - Managed Address Configuration Flag [RFC4861]
o M--管理されたアドレス構成旗[RFC4861]
o O - Other Configuration Flag [RFC4861]
o O--他の構成旗[RFC4861]
o H - Mobile IPv6 Home Agent Flag [RFC3775]
o H--モバイルIPv6ホームエージェント旗[RFC3775]
o Prf - Router Selection Preferences [RFC4191]
o Prf--ルータ選択好み[RFC4191]
o P - Neighbor Discovery Proxy Flag [RFC4389]
o P--隣人発見プロキシ旗[RFC4389]
o R - Reserved
o R--予約されます。
With other protocols in the works (e.g., Detecting Network Attachment) that want to use flags in the NDP messages, it is necessary to define an expansion capability to support new features.
他のプロトコルがNDPメッセージで旗を使用したがっている作品(例えば、Detecting Network Attachment)にある状態で、新機能を支持する拡大能力を定義するのが必要です。
Haberman & Hinden Standards Track [Page 2] RFC 5175 IPv6 RA Flags Options March 2008
ハーバーマンとHinden標準化過程[2ページ]RFC5175IPv6 RAは2008年のオプション行進のときに弛みます。
4. Flags Expansion Option
4. 拡大オプションに旗を揚げさせます。
The Neighbor Discovery specification [RFC4861] contains the capability to define NDP options. The following (Figure 2) is the definition of the Expanded Flags Option (EFO) for NDP Router Advertisement messages.
Neighborディスカバリー仕様[RFC4861]はNDPオプションを定義する能力を含んでいます。 ↓これ(図2)はNDP Router AdvertisementメッセージのためのExpanded Flags Option(EFO)の定義です。
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 | Bit fields available ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... for assignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 2: Router Advertisement Expanded Flags Option
図2: 広げられたルータ通知はオプションに旗を揚げさせます。
o Type - 26
o タイプ--26
o Length - The length MUST be checked when processing the option in
order to allow for future expansion of this option. An
implementation of this specification MUST set the Length to 1,
MUST ignore any unrecognized data, and MUST be able to recognize
the specific length in order to skip over unrecognized bits.
o 長さ--このオプションの今後の拡大を考慮するためにオプションを処理するとき、長さをチェックしなければなりません。 この仕様の実現は、認識されていないビットの上スキップするために1にLengthを設定しなければならなくて、どんな認識されていないデータも無視しなければならなくて、特定の長さを認識できなければなりません。
o Bits - allocated by IANA
o ビット--IANAによって割り当てられます。
The definition and usage of these bits is to be found in the document requesting their allocation.
これらのビットの定義と使用法は彼らの配分を要求しながらドキュメントで見つけられることです。
During the construction/transmission, this option:
工事/トランスミッション、このオプションの間:
o MUST only occur in Router Advertisement messages.
o Router Advertisementメッセージに起こるだけでよいです。
o MUST occur prior to any additional options associated with any
flags set in this option.
o このオプションで設定されたどんな旗にも関連しているどんな追加オプションの前にも起こらなければなりません。
o MUST only occur once in the Router Advertisement message.
o Router Advertisementメッセージに一度起こるだけでよいです。
o MUST NOT be added to a Router Advertisement message if no flags in
the option are set.
o オプションにおける旗が全く設定されないなら、Router Advertisementメッセージに追加されてはいけません。
o MUST set all unused flags to zero.
o すべての未使用の旗をゼロに設定しなければなりません。
Haberman & Hinden Standards Track [Page 3] RFC 5175 IPv6 RA Flags Options March 2008
ハーバーマンとHinden標準化過程[3ページ]RFC5175IPv6 RAは2008年のオプション行進のときに弛みます。
Upon reception, a receiver processing NDP messages containing this option:
レセプション、このオプションを含むNDPメッセージを処理する受信機で:
o MUST ignore the option if it occurs in a message other than a
Router Advertisement.
o Router Advertisement以外のメッセージに起こるなら、オプションを無視しなければなりません。
o MUST ignore all instances of the option except the first one
encountered in the Router Advertisement message.
o 1つがRouter Advertisementメッセージで遭遇した1番目を除いたオプションのすべての例を無視しなければなりません。
o MUST ignore the option if the Length is less than 1.
o Lengthが1歳未満であるならオプションを無視しなければなりません。
o MUST ignore any unknown flag bits.
o どんな未知のフラグビット無視しなければなりません。
The bit fields within the option are numbered from left to right, from 8 to 55 (starting as bit offset 16 in the option) and follow the numbering of the flag bits in the RA option described in Figure 1. Flag bits 0 to 7 are found in the Router Advertisement message header defined in [RFC4861].
オプションの中の噛み付いている分野は、左から右まで8〜55まで付番されて(噛み付かれるように始まるのはオプションで16を相殺しました)、図1で説明されたRAオプションでフラグビットの付番に続きます。 フラグビット0〜7は[RFC4861]で定義されたRouter Advertisementメッセージヘッダーで見つけられます。
5. IANA Considerations
5. IANA問題
IANA has defined a new IPv6 Neighbor Discovery option for the option defined in this document of the form:
IANAは形式のこのドキュメントで定義されたオプションのための新しいIPv6 Neighborディスカバリーオプションを定義しました:
+------+---------------------------+-----------+
| Type | Description | Reference |
+------+---------------------------+-----------+
| 26 | RA Flags Extension Option | [RFC5175] |
+------+---------------------------+-----------+
+------+---------------------------+-----------+ | タイプ| 記述| 参照| +------+---------------------------+-----------+ | 26 | RAは拡大オプションに旗を揚げさせます。| [RFC5175]| +------+---------------------------+-----------+
The registry for these options can be found at: http://www.iana.org/assignments/icmpv6-parameters
以下でこれらのオプションのための登録を見つけることができます。 http://www.iana.org/assignments/icmpv6-parameters
IANA has created a new registry for IPv6 ND Router Advertisement flags. This should include the current flags in the RA option and in the extension option defined in this document. The new registry has been added to the icmpv6-parameters as shown above. The format for the registry is:
IANAはIPv6ノースダコタRouter Advertisement旗のための新しい登録を作成しました。 これはRAオプションと本書では定義された拡大オプションに現在の旗を含むべきです。 上に示されるようにicmpv6-パラメタに新しい登録を追加してあります。 登録への形式は以下の通りです。
Haberman & Hinden Standards Track [Page 4] RFC 5175 IPv6 RA Flags Options March 2008
ハーバーマンとHinden標準化過程[4ページ]RFC5175IPv6 RAは2008年のオプション行進のときに弛みます。
+---------------+---------------------------------------+-----------+ | RA Option Bit | Description | Reference | +---------------+---------------------------------------+-----------+ | 0 | M - Managed Address Configuration | [RFC4861] | | | Flag | | | 1 | O - Other Configuration Flag | [RFC4861] | | 2 | H - Mobile IPv6 Home Agent Flag | [RFC3775] | | 3 | Prf - Router Selection Preferences | [RFC4191] | | 4 | Prf - Router Selection Preferences | [RFC4191] | | 5 | P - Neighbor Discovery Proxy Flag | [RFC4389] | | 6-53 | R - Reserved; Available for | | | | assignment | | | 54-55 | Private Experimentation | | +---------------+---------------------------------------+-----------+
+---------------+---------------------------------------+-----------+ | RAオプションビット| 記述| 参照| +---------------+---------------------------------------+-----------+ | 0 | M--管理されたアドレス構成| [RFC4861]| | | 旗| | | 1 | O--他の構成旗| [RFC4861]| | 2 | H--モバイルIPv6ホームエージェント旗| [RFC3775]| | 3 | Prf--ルータ選択好み| [RFC4191]| | 4 | Prf--ルータ選択好み| [RFC4191]| | 5 | P--隣人発見プロキシ旗| [RFC4389]| | 6-53 | R--予約されます。 利用可能| | | | 課題| | | 54-55 | 個人的な実験| | +---------------+---------------------------------------+-----------+
The assignment of new RA flags in the RA option header and the bits defined in the RA extension option defined in this document require standards action or IESG approval [RFC2434].
RAオプションヘッダーの新しいRA旗の課題とオプションが定義したRA拡張子で定義されたビットは本書では、規格動作かIESG承認[RFC2434]を必要とします。
6. Security Considerations
6. セキュリティ問題
This protocol shares the security issues of NDP that are documented in the "Security Considerations" section of [RFC4861].
このプロトコルは[RFC4861]の「セキュリティ問題」セクションで記録されるNDPの安全保障問題を共有します。
The inclusion of additional optional bit fields provides a potential covert channel that is useful for passing information.
追加任意の噛み付いている分野の包含は情報を通過することの役に立つひそかな潜在的チャンネルを提供します。
7. References
7. 参照
7.1. Normative References
7.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月。
[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月)。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
Haberman & Hinden Standards Track [Page 5] RFC 5175 IPv6 RA Flags Options March 2008
ハーバーマンとHinden標準化過程[5ページ]RFC5175IPv6 RAは2008年のオプション行進のときに弛みます。
7.2. Informative References
7.2. 有益な参照
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves、研究開発ターレル、「デフォルトルータ好みの、そして、より特定のルート」、RFC4191、2005年11月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] ターレル、D.、Talwar、M.、およびC.パテル、「隣人発見プロキシ(第プロキシ)」、RFC4389、2006年4月。
Authors' Addresses
作者のアドレス
Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
ブライアンハーバーマン(エディタ)ジョーンズ・ホプキンス大学応用物理学研究室11100のジョーンズ・ホプキン・Road MD20723-6099ローレル(米国)
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
以下に電話をしてください。 +1 1319年の443 778メール: brian@innovationslab.net
Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートHindenノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625 2004 EMail: bob.hinden@nokia.com
以下に電話をしてください。 +1 2004年の650 625メール: bob.hinden@nokia.com
Haberman & Hinden Standards Track [Page 6] RFC 5175 IPv6 RA Flags Options March 2008
ハーバーマンとHinden標準化過程[6ページ]RFC5175IPv6 RAは2008年のオプション行進のときに弛みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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に情報を記述してください。
Haberman & Hinden Standards Track [Page 7]
ハーバーマンとHinden標準化過程[7ページ]
一覧
スポンサーリンク
