Network Working Group J. Manner
Request for Comments: 5350 TKK
Updates: 2113, 3175 A. McDonald
Category: Standards Track Siemens/Roke
September 2008
IANA Considerations for the IPv4 and IPv6 Router Alert Options
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
Abstract
抽象
This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values.
この文書では、IPv4とIPv6のルータ警告オプション値のIANA配分ルールおよびレジストリを更新します。
Table of Contents
目次
1. Introduction ....................................................2
2. Use of the Router Alert Option Value Field ......................2
3. IANA Considerations .............................................4
3.1. IANA Considerations for IPv4 Router Alert Option Values ....4
3.2. IANA Considerations for IPv6 Router Alert Option Values ....5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
The IP Router Alert Option is defined for IPv4 in [RFC2113]. A similar IPv6 option is defined in [RFC2711]. When one of these options is present in an IP datagram, it indicates that the contents of the datagram may be interesting to routers. The Router Alert Option (RAO) is used by protocols such as the Resource Reservation Protocol (RSVP) [RFC2205] and IGMP [RFC3376].
IPルータアラートオプションは、[RFC2113]にはIPv4のために定義されています。類似のIPv6オプションは[RFC2711]で定義されています。これらのオプションのいずれかが、IPデータグラム中に存在する場合、それはデータグラムの内容がルータに興味深いものになる可能性があることを示します。ルータ警告オプション（RAO）は、そのようなリソース予約プロトコル（RSVP）[RFC2205]とIGMP [RFC3376]などのプロトコルによって使用されます。
Both the IPv4 and IPv6 options contain a two-octet Value field to carry extra information. This information can be used, for example, by routers to determine whether or not the packet should be more closely examined by them.
IPv4とIPv6の両方のオプションは、追加の情報を運ぶために2オクテットの値フィールドが含まれています。この情報は、パケットがより密接にそれらによって検討されるべきであるか否かを決定するためにルータにより、例えば、使用することができます。
There can be up to 65536 values for the RAO. Yet, currently there is only a registry for IPv6 values. No registry or allocation policies are defined for IPv4.
RAOのために最大65536個の値が存在する場合があります。しかし、現在のIPv6値に対してのみレジストリがあります。いいえ、レジストリまたは割り当てポリシーは、IPv4のために定義されていません。
This document updates the IANA registry for managing IPv4 and IPv6 Router Alert Option Values, and removes one existing IPv6 Router Alert Option Value.
この文書では、IPv4とIPv6のルータ警告オプション値を管理するためのIANAレジストリを更新し、IPv6ルーター警告オプション値を既存のものを削除します。
One difference between the specifications for the IPv4 and IPv6 Router Alert Options is the way values for the Value field are managed. In [RFC2113], the IPv4 Router Alert Option Value field has the value 0 assigned to "Router shall examine packet". All other values (1-65535) are reserved. Neither a management mechanism (e.g., an IANA registry) nor an allocation policy are provided for the IPv4 RAO values.
IPv4とIPv6ルータアラートオプションの仕様の違いの1つは、値フィールドの値が管理されている方法です。 [RFC2113]で、IPv4ルーターの警告オプション値フィールドは「ルータがパケットを検査しなければならない」に割り当てられた値0を持っています。他のすべての値（1〜65535）が予約されています。管理機構（例えば、IANAレジストリ）も割り当てポリシーもがIPv4のRAO値のために提供されます。
The IPv6 Router Alert Option has an IANA-managed registry [IANA-IPv6RAO] containing allocations for the Value field.
IPv6ルーターアラートオプションは、値フィールドの割り当てを含むIANAが管理するレジストリ[IANA-IPv6RAO]を持っています。
In [RFC3175], the IPv4 Router Alert Option Value is described as a parameter that provides "additional information" to the router in making its interception decision, rather than as a registry managed by IANA. As such, this aggregation mechanism makes use of the Value field to carry the reservation aggregation level. For the IPv6 option, IANA has assigned a set of 32 values to indicate reservation levels. However, since other registrations have already been made in that registry, these values are from 3-35 (which is actually a set of 33 values).
[RFC3175]で、IPv4のルータアラートオプション値はむしろ、IANAによって管理されたレジストリとしてよりも、その傍受決定を行うには、ルータに「追加情報」を提供し、パラメータとして記載されています。このように、この凝集機構は、Valueフィールドの使用は、予約集合レベルを運ぶことができます。 IPv6のオプションのために、IANA予約レベルを示すために、32個の値の組を割り当てました。他の登録はすでにそのレジストリに行われているので、これらの値は、（実際には33個の値のセットです）3-35からです。
Although it might have been desirable to have the same values used in both the IPv4 and IPv6 registries, the initial allocations in [RFC2711] and the aggregation-level allocations in [RFC3175] have
それはIPv4とIPv6の両方のレジストリで使用したものと同じ値を有することが望ましいされているかもしれないが、[RFC3175]に[RFC2711]での初期割り振りおよび凝集レベルの割り当ては有します
made this impossible. The following table shows the allocations in the IPv6 registry and the values used in the IPv4 registry, where the latter have been deduced from [RFC2113] and [RFC3175] with the assumption that the number of aggregation levels can be limited to 32 as in the IPv6 case. Entries for values 6 to 31 have been elided for brevity.
これが不可能になりました。次の表は、IPv6レジストリに割り当て、後者は凝集レベルの数は、同様に32に限定することができると仮定して、[RFC2113]及び[RFC3175]から推定されているIPv4のレジストリで使用される値を示しIPv6のケース。値6〜31のエントリは、簡潔にするために省略されています。
+----------+-------------------------+------------------------------+
| Value | IPv4 RAO Meaning | IPv6 RAO Meaning |
+----------+-------------------------+------------------------------+
| 0 | Router shall examine | Datagram contains a |
| | packet [RFC2113] | Multicast Listener Discovery |
| | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] |
| | [RFC4286] | [RFC4286] |
| 1 | Aggregated Reservation | Datagram contains RSVP |
| | Nesting Level 1 | message [RFC2711] [RFC2205] |
| | [RFC3175] | |
| 2 | Aggregated Reservation | Datagram contains an Active |
| | Nesting Level 2 | Networks message [RFC2711] |
| | [RFC3175] | [Schwartz2000] |
| 3 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 3 | Nesting Level 0 [RFC3175](*) |
| | [RFC3175] | |
| 4 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 4 | Nesting Level 1 [RFC3175] |
| | [RFC3175] | |
| 5 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 5 | Nesting Level 2 [RFC3175] |
| | [RFC3175] | |
| ... | ... | ... |
| 32 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 32 | Nesting Level 29 [RFC3175] |
| | [RFC3175] | |
| 33 | Reserved | Aggregated Reservation |
| | | Nesting Level 30 [RFC3175] |
| 34 | Reserved | Aggregated Reservation |
| | | Nesting Level 31 [RFC3175] |
| 35 | Reserved | Aggregated Reservation |
| | | Nesting Level 32(*) |
| | | [RFC3175] |
| 36-65534 | Reserved | Reserved to IANA for future |
| | | assignment |
| 65535 | Reserved | Reserved [IANA-IPv6RAO] |
+----------+-------------------------+------------------------------+
Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and is consequently reflected
注（*）：35のIPv6 RAO値（凝集予約ネスティング・レベル32）のために上記テーブルのエントリは、[RFC3175]のテキストにおける矛盾に起因マークされており、その結果、反射され
in the IANA registry. In that document, the values 3-35 (i.e., 33 values) are defined for nesting levels 0-31 (i.e., 32 levels). Similarly, value 3 is a duplicate, because aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value "1" assigned.
IANAレジストリインチその文書では、値3-35（すなわち、33値）は入れ子のレベル0-31（即ち、32のレベル）のために定義されています。集約レベル0は、エンドツーエンドシグナリングを意味し、これは既に割り当てられたIPv6 RAO値「1」を有しているので、同様に、値3は、重複しています。
Also note that nesting levels begin at 1 for IPv4 (described in Section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in Section 6 of [RFC3175]).
また、ネスティングレベルは、IPv4の場合は1から始まり（[RFC3175]のセクション1.4.9に記載）およびIPv6のための0（[RFC3175]のセクション6に割り当てられた）ことに注意してください。
Section 3.2 of this document redefines these so that for IPv6, value 3 is no longer used and values 4-35 represent levels 1-32. This removes the above inconsistencies.
IPv6のための、値3は、もはや使用され、4-35のレベル1-32を表す値ように、この文書のセクション3.2は、これらを再定義していません。これは、上記の矛盾を削除します。
This section contains the new procedures for managing IPv4 Router Alert Option Values. IANA has created a registry for IPv4 Router Alert Option Values (described in Section 3.1) and has updated the IPv6 Router Alert Option Values (described in Section 3.2).
このセクションでは、IPv4ルータアラートオプション値を管理するための新しい手順が含まれています。 IANA（セクション3.1で説明）のIPv4ルータアラートオプション値のレジストリを作成しましたし、（3.2節に記述）は、IPv6ルータ警告オプション値を更新しました。
IP Router Alert Option Values are currently managed separately for IPv4 and IPv6. This document does not change this, as there is little value in forcing the two registries to be aligned.
IPルータアラートオプション値は、現在、IPv4とIPv6のために別々に管理されています。整列するために2つのレジストリを強制的にはほとんど価値があるとしてこの文書では、これを変更しません。
The Value field, as specified in [RFC2113], is two octets in length. The Value field is registered and maintained by IANA. The initial contents of this registry are:
値フィールドは、[RFC2113]で指定されるように、長さが2つのオクテットです。 Valueフィールドが登録され、IANAによって維持されています。このレジストリの初期の内容は以下のとおりです。
+-------------+--------------------------------------+-----------+
| Value | Description | Reference |
+-------------+--------------------------------------+-----------+
| 0 | Router shall examine packet | [RFC2113] |
| 1-32 | Aggregated Reservation Nesting Level | [RFC3175] |
| 33-65502 | Available for assignment by the IANA | |
| 65503-65534 | Available for experimental use | |
| 65535 | Reserved | |
+-------------+--------------------------------------+-----------+
New values are to be assigned via IETF Review as defined in [RFC5226].
新しい値は、[RFC5226]で定義されているIETFレビューを経由して割り当てられます。
The registry for IPv6 Router Alert Option Values continues to be maintained as specified in [RFC2711]. In addition, the following value has been removed from the IANA registry and reserved for possible future use (not to be allocated currently). The reason is that it is a duplicate value; aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value "1" assigned.
IPv6ルーター警告オプション値のレジストリは、[RFC2711]で指定されるように維持され続けます。加えて、以下の値がIANAレジストリから削除され、将来の使用のために予約（現在割り当てされるべきではありません）。その理由は、それが重複した値であるということです。集約レベル0は、エンドツーエンドシグナリングを意味し、これは既に割り当てられたIPv6 RAO値「1」を有します。
+-------+--------------------------+-----------+
| Value | Description | Reference |
+-------+--------------------------+-----------+
| 3 | RSVP Aggregation level 0 | [RFC3175] |
+-------+--------------------------+-----------+
The following IPv6 RAO values are available for experimental use:
次のIPv6 RAO値は、実験的な使用のために用意されています。
+-------------+------------------+-----------+
| Value | Description | Reference |
+-------------+------------------+-----------+
| 65503-65534 | Experimental use | |
+-------------+------------------+-----------+
Since this document is only concerned with the IANA management of the IPv4 and IPv6 Router Alert Option Values registry, it raises no new security issues beyond those identified in [RFC2113] and [RFC2711].
このドキュメントは、IPv4とIPv6のルータ警告オプション値レジストリのIANA管理のみに関心あるので、それは[RFC2113]と[RFC2711]で特定されたものを超えてどんな新しい安全保障問題も提起しません。
Yet, as discussed in RFC 4727 [RFC4727], production networks do not necessarily support the use of experimental code points in IP option headers. The network scope of support for experimental values should be evaluated carefully before deploying any experimental RAO value across extended network domains, such as the public Internet. The potential to disrupt the stable operation of the network hosting the experiment through the use of unsupported experimental code points is a serious consideration when planning an experiment using such code points.
まだ、[RFC4727] RFC 4727で説明したように、製造ネットワークが必ずしもIPオプションヘッダの実験コードポイントの使用をサポートしていません。実験値のサポートのネットワーク範囲は、公共のインターネットのような拡張ネットワークドメインにわたって任意実験RAO値を展開する前に慎重に評価すべきです。このようなコード・ポイントを使用して実験を計画する際に、サポートされていない実験的なコードポイントを使用して実験をホスティングしているネットワークの安定した動作を妨害する可能性が真剣に検討されます。
When experimental RAO values are deployed within an administratively self-contained network domain, the network administrators should ensure that each value is used consistently to avoid interference between experiments. When experimental values are used in traffic that crosses multiple administrative domains, the experimenters should assume that there is a risk that the same values will be used simultaneously by other experiments, and thus that there is a possibility that the experiments will interfere. Particular attention should be given to security threats that such interference might create.
実験RAO値が管理自己完結型のネットワーク・ドメイン内に配置されている場合、ネットワーク管理者は、各値が、実験間の干渉を回避するために一貫して使用されていることを確認すべきです。実験値は、複数の管理ドメインを横断するトラフィックに使用される場合、実験者は実験を妨害する可能性があること、従って同じ値が他の実験によって同時に使用されるリスクがあると仮定し、そしてべきです。特に注意がこのような干渉を作成することがありますセキュリティ上の脅威に与えられるべきです。
Thanks to Robert Hancock, Martin Stiemerling, Alan Ford, and Francois Le Faucheur for their helpful comments on this document.
このドキュメントの彼らの役に立つコメントについてロバート・ハンコック、マーティンStiemerling、アラン・フォード、そしてフランソワ・ルFaucheurに感謝します。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[IANA-IPv6RAO] "IANA Registry for Internet Protocol version 6 (IPv6) Router Alert Option Values", <http://www.iana.org>.
<http://www.iana.org> [IANA-IPv6RAO] "インターネットプロトコルバージョン6（IPv6）ルータ警告オプション値のためのIANAレジストリ"。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見（MLD）"、RFC 2710、1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]ハーバーマン、B.及びJ.マーチン、 "マルチキャストルータ発見"、RFC 4286、2005年12月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]フェナー、B.、RFC 4727、2006年11月 "のIPv4、IPv6の、ICMPv4の、ICMPv6の、UDP、およびTCPヘッダには実験値"。
[Schwartz2000] Schwartz, B., Jackson, A., Strayer, W., Zhou, W., Rockwell, D., and C. Partridge, "Smart Packets: Applying Active Networks to Network Management", ACM Transactions on Computer Systems (TOCS), Volume 18, Issue 1, February 2000.
[Schwartz2000]シュワルツ、B.、ジャクソン、A.、ストレイヤー、W.、周、W.、ロックウェル、D.、およびC.ヤマウズラ、 "スマートパケット：ネットワーク管理にアクティブネットワークの適用"、コンピュータシステム上のACM取引（TOCS）、18巻、1号、2000年2月。
Authors' Addresses
著者のアドレス
Jukka Manner Department of Communications and Networking (Comnet) Helsinki University of Technology (TKK) P.O. Box 3000 Espoo FIN-02015 TKK Finland
コミュニケーションのユッカマナー部門とネットワーキング（Comnet）ヘルシンキ工科大学（TKK）P。ボックス3000エスポーFIN-02015 TKKフィンランド
Phone: +358 9 451 2481 EMail: jukka.manner@tkk.fi
電話：+358 9 451 2481 Eメール：jukka.manner@tkk.fi
Andrew McDonald Roke Manor Research Ltd (a Siemens company) Old Salisbury Lane Romsey, Hampshire SO51 0ZN United Kingdom
アンドリュー・マクドナルドRokeマナーリサーチ株式会社（シーメンス社）オールド・ソールズベリーレーンロムジー、ハンプシャーSO51 0ZNイギリス
EMail: andrew.mcdonald@roke.co.uk
メールアドレス：andrew.mcdonald@roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎と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に情報を記述してください。