[要約] RFC 5175は、IPv6ルータ広告フラグオプションに関する仕様を定めたものであり、IPv6ネットワークでルータ広告メッセージにフラグを追加するための方法を提供しています。このRFCの目的は、ネットワーク管理者がIPv6ネットワークのルータ広告をより柔軟に制御できるようにすることです。
Network Working Group B. Haberman, Ed.
Request for Comments: 5175 JHU APL
Obsoletes: 5075 R. Hinden
Category: Standards Track Nokia
March 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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 Discoveryのルーター広告メッセージには、単一ビットフラグ用に予約された8ビットフィールドが含まれています。いくつかのプロトコルがこの分野に旗を予約しており、他のプロトコルは、フィールドを使い果たすのに十分な数のフラグを予約する準備をしています。このドキュメントでは、利用可能なフラグビットの数を拡張するルーター広告メッセージのオプションを定義します。
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
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 Discovery Protocol（NDP）[RFC4861]ルーター広告メッセージには、単一ビットフラグ用に予約された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.
このドキュメントでは、NDPメッセージに48フラグビットを追加することにより、利用可能な数のフラグビット数を拡張するルーター広告メッセージのオプションを定義します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Currently, the NDP Router Advertisement message contains the following one-bit flags defined in published RFCs:
現在、NDPルーター広告メッセージには、公開されているRFCで定義されている次の1ビットフラグが含まれています。
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 -Router選択の好み[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メッセージでフラグを使用したい他のプロトコル（たとえば、ネットワークの添付ファイルを検出する）があるため、新機能をサポートする拡張機能を定義する必要があります。
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.
近隣発見仕様[RFC4861]には、NDPオプションを定義する機能が含まれています。以下（図2）は、NDPルーター広告メッセージの拡張フラグオプション（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に設定し、認識されていないデータを無視し、認識されていないビットをスキップするために特定の長さを認識できる必要があります。
o Bits - allocated by IANA
o ビット - イアナによって割り当てられました
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 ルーター広告メッセージでのみ発生する必要があります。
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 ルーター広告メッセージで1回のみ発生する必要があります。
o MUST NOT be added to a Router Advertisement message if no flags in the option are set.
o オプションにフラグが設定されていない場合、ルーター広告メッセージに追加しないでください。
o MUST set all unused flags to zero.
o 未使用のすべてのフラグをゼロに設定する必要があります。
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 ルーター広告以外のメッセージで発生する場合は、オプションを無視する必要があります。
o MUST ignore all instances of the option except the first one encountered in the Router Advertisement message.
o ルーター広告メッセージで遭遇した最初のインスタンスを除き、オプションのすべてのインスタンスを無視する必要があります。
o MUST ignore the option if the Length is less than 1.
o 長さが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]で定義されているルーター広告メッセージヘッダーで見つかりました。
IANA has defined a new IPv6 Neighbor Discovery option for the option defined in this document of the form:
IANAは、フォームのこのドキュメントで定義されているオプションの新しいIPv6 Neighter Discoveryオプションを定義しました。
+------+---------------------------+-----------+
| Type | Description | Reference |
+------+---------------------------+-----------+
| 26 | RA Flags Extension Option | [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 ndルーター広告フラグの新しいレジストリを作成しました。これには、RAオプションとこのドキュメントで定義されている拡張オプションオプションの現在のフラグを含める必要があります。上記のように、新しいレジストリがICMPV6パラメーターに追加されました。レジストリの形式は次のとおりです。
+---------------+---------------------------------------+-----------+
| 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 | |
+---------------+---------------------------------------+-----------+
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拡張オプションで定義されているBITSには、標準アクションまたはIESG承認[RFC2434]が必要です。
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.
追加のオプションのビットフィールドを含めると、情報を渡すのに役立つ潜在的な秘密チャネルが提供されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーターの設定とより固有のルート」、RFC 4191、2005年11月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、2006年4月。
Authors' Addresses
著者のアドレス
Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
ブライアンハーバーマン（編集者）ジョンズホプキンス大学応用物理学ラボ11100ジョンズホプキンスロードローレル、メリーランド20723-6099 USA
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。