[要約] RFC 2711はIPv6ルーターアラートオプションに関する仕様であり、IPv6パケットのルーターへの通知を可能にする。目的は、特定のパケットをルーターに対して識別し、特定の処理を行うための機能を提供すること。
Network Working Group C. Partridge
Request for Comments: 2711 BBN
Category: Standards Track A. Jackson
BBN
October 1999
IPv6 Router Alert 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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.
このメモは、TransitルーターにIPデータグラムの内容をより詳細に調べるように警告する新しいIPv6ホップバイホップオプションタイプについて説明しています。このオプションは、特定の宛先にアドレス指定されたデータグラムに、パスに沿ったルーターによる特別な処理を必要とする可能性のある情報が含まれている状況に役立ちます。
New protocols, such as RSVP, use control datagrams which, while addressed to a particular destination, contain information that needs to be examined, and in some case updated, by routers along the path between the source and destination. It is desirable to forward regular datagrams as rapidly as possible, while ensuring that the router processes these special control datagrams appropriately. Currently, however, the only way for a router to determine if it needs to examine a datagram is to at least partially parse upper layer data in all datagrams. This parsing is expensive and slow. This situation is undesirable.
RSVPなどの新しいプロトコルは、特定の宛先にアドレス指定されている間、検査する必要がある情報を含むコントロールデータグラムを使用し、場合によっては、ソースと宛先の間のパスに沿ったルーターによって更新される情報を含んでいます。ルーターがこれらの特別な制御データグラムを適切に処理するようにしながら、通常のデータグラムをできるだけ迅速に転送することが望ましいです。ただし、現在、ルーターがデータグラムを調べる必要があるかどうかを判断する唯一の方法は、すべてのデータグラムで少なくとも部分的に上層データを解析することです。この解析は高価で遅いです。この状況は望ましくありません。
This document defines a new option within the IPv6 Hop-by-Hop Header. The presence of this option in an IPv6 datagram informs the router that the contents of this datagram is of interest to the router and to handle any control data accordingly. The absence of this option in an IPv6 datagram informs the router that the datagram does not contain information needed by the router and hence can be safely routed without further datagram parsing. Hosts originating IPv6 datagrams are required to include this option in certain circumstances.
このドキュメントでは、IPv6ホップバイホップヘッダー内の新しいオプションを定義します。IPv6データグラムでのこのオプションの存在は、このデータグラムの内容がルーターにとって重要であり、それに応じてコントロールデータを処理することをルーターに通知します。IPv6データグラムにこのオプションがないことは、ルーターにルーターに必要な情報が含まれていないため、データグラムの解析なしに安全にルーティングできることをルーターに通知します。IPv6データグラムを発信するホストは、特定の状況にこのオプションを含める必要があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC-2119]に記載されているように解釈される。
The goal is to provide an efficient mechanism whereby routers can know when to intercept datagrams not addressed to them without having to extensively examine every datagram. The described solution is to define a new IPv6 Hop-by-Hop Header option having the semantic "routers should examine this datagram more closely" and require protocols such as RSVP to use this option. This approach incurs little or no performance penalty on the forwarding of normal datagrams. Not including this option tells the router that there is no need to closely examine the contents of the datagram.
目標は、すべてのデータグラムを広範囲に調べることなく、ルーターが対処されていないデータグラムをいつ傍受するかを知ることができる効率的なメカニズムを提供することです。記載されているソリューションは、セマンティック「ルーターがこのデータグラムをより詳細に調べる必要がある」というセマンティックを持つ新しいIPv6ホップバイホップヘッダーオプションを定義し、このオプションを使用するためにRSVPなどのプロトコルを必要とすることです。このアプローチは、通常のデータグラムの転送にパフォーマンスペナルティがほとんどまたはまったくありません。このオプションを含めないと、データグラムの内容を綿密に調べる必要がないことをルーターに伝えます。
The router alert option has the following format:
ルーターアラートオプションには、次の形式があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length = 2
The first three bits of the first byte are zero and the value 5 in the remaining five bits is the Hop-by-Hop Option Type number. [RFC-2460] specifies the meaning of the first three bits. By zeroing all three, this specification requires that nodes not recognizing this option type should skip over this option and continue processing the header and that the option must not change en route.
最初のバイトの最初の3ビットはゼロで、残りの5ビットの値5はホップバイホップオプションタイプ番号です。[RFC-2460]は、最初の3ビットの意味を指定します。3つすべてをゼロにすることにより、この仕様では、このオプションタイプを認識しないノードがこのオプションをスキップし、ヘッダーの処理を続け、オプションが途中で変更してはならないことが必要です。
There MUST only be one option of this type, regardless of value, per Hop-by-Hop header.
ホップバイホップヘッダーごとに、価値に関係なく、このタイプのオプションが1つしかない必要があります。
Value: A 2 octet code in network byte order with the following values:
値：次の値を持つネットワークバイト順序で2オクテットコード：
0 Datagram contains a Multicast Listener Discovery message [RFC-2710]. 1 Datagram contains RSVP message. 2 Datagram contains an Active Networks message. 3-65535 Reserved to IANA for future use.
0データグラムには、マルチキャストリスナーディスカバリーメッセージ[RFC-2710]が含まれています。1データグラムにはRSVPメッセージが含まれています。2データグラムには、アクティブなネットワークメッセージが含まれています。3-65535将来の使用のためにIANAに予約されています。
Alignment requirement: 2n+0
アライメント要件：2n 0
Values are registered and maintained by the IANA. See section 5.0 for more details.
値はIANAによって登録および維持されます。詳細については、セクション5.0を参照してください。
The option indicates that the contents of the datagram may be interesting to the router. The router's interest and the actions taken by employing Router Alert MUST be specified in the RFC of the protocol that mandates or allows the use of Router Alert.
このオプションは、データグラムの内容がルーターにとって興味深い場合があることを示しています。ルーターのアラートを使用することによって行われるルーターの関心とアクションは、ルーターアラートの使用を義務付けたり許可したりするプロトコルのRFCで指定する必要があります。
The final destination of the IPv6 datagram MUST ignore this option upon receipt to prevent multiple evaluations of the datagram. Unrecognized value fields MUST be silently ignored and the processing of the header continued.
IPv6データグラムの最終宛先は、データグラムの複数の評価を防ぐために、受領時にこのオプションを無視する必要があります。認識されていない価値フィールドは静かに無視する必要があり、ヘッダーの処理が継続する必要があります。
Routers that recognize the option will examine datagrams carrying it more closely to determine whether or not further processing is necessary. The router only needs to parse the packet in sufficient detail to decide whether the packet contains something of interest. The value field can be used by an implementation to speed processing of the datagram within the transit router.
オプションを認識するルーターは、さらに処理が必要かどうかを判断するために、それを運ぶデータグラムをより詳細に調べます。ルーターは、パケットに興味のあるものが含まれているかどうかを決定するために、パケットを十分に詳細に解析する必要があります。値フィールドは、実装で使用して、トランジットルーター内のデータグラムの処理を速めることができます。
Observe that further processing can involve protocol layers above IPv6. E.g., for RSVP messages, the datagram will have to undergo UDP and RSVP protocol processing. Once the datagram leaves the IPv6 layer, there is considerable ambiguity about whether the router is acting as an IPv6 host or an IPv6 router. Precisely how the router handles the contents is value-field specific. However, if the processing required for the datagram involves examining the payload of the IPv6 datagram, then the interim router is performing a host function and SHOULD interpret the data as a host.
さらなる処理には、IPv6の上のプロトコル層が含まれることを観察してください。たとえば、RSVPメッセージの場合、データグラムはUDPおよびRSVPプロトコル処理を受ける必要があります。データグラムがIPv6レイヤーを離れると、ルーターがIPv6ホストまたはIPv6ルーターとして機能しているかどうかにかなりのあいまいさがあります。正確には、ルーターが内容を処理する方法はバリューフィールド固有です。ただし、データグラムに必要な処理にIPv6データグラムのペイロードを調べることが含まれる場合、暫定ルーターはホスト機能を実行し、データをホストとして解釈する必要があります。
For this option to be effective, its use MUST be mandated in protocols that expect routers to perform significant processing on datagrams not directly addressed to them. Routers are not required to examine the datagrams not addressed to them unless the datagrams include the router alert option.
このオプションが効果的であるためには、その使用は、ルーターが直接対処されていないデータグラムで重要な処理を実行することを期待するプロトコルで義務付けられなければなりません。データグラムにルーターアラートオプションが含まれていない限り、ルーターはそれらに宛てられていないデータグラムを調べる必要はありません。
All IPv6 datagrams containing an RSVP message MUST contain this option within the IPv6 Hop-by-Hop Options Header of such datagrams.
RSVPメッセージを含むすべてのIPv6データグラムは、そのようなデータグラムのIPv6ホップバイホップオプションヘッダー内にこのオプションを含める必要があります。
Gratuitous use of this option can cause performance problems in routers. A more severe attack is possible in which the router is flooded by bogus datagrams containing router alert options.
このオプションを無償で使用すると、ルーターにパフォーマンスの問題が発生する可能性があります。ルーターがルーターアラートオプションを含む偽のデータグラムによってルーターが浸水する、より深刻な攻撃が可能です。
The use of the option, if supported in a router, MAY therefore be limited by rate or other means by the transit router.
したがって、ルーターでサポートされている場合、オプションの使用は、トランジットルーターによってレートまたはその他の手段によって制限される場合があります。
The value field described in Section 2.1 is registered and maintained by IANA. New values are to be assigned via IETF Consensus as defined in RFC 2434 [RFC-2434].
セクション2.1で説明されている値フィールドは、IANAによって登録および維持されます。RFC 2434 [RFC-2434]で定義されているように、新しい値はIETFコンセンサスによって割り当てられます。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
[RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1977.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1977年3月。
[RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC 2205, September 1997.
[RFC-2205] Braden、B。（ed。）、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource Reservation Protocol（RSVP）」、RFC 2205、1997年9月。
[RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460] Deering、S。and R. Hinden、「Internet Protocol、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC-2710] Deering、S.、Fenner、W.およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
Craig Partridge BBN Technologies 10 Moulton Street Cambridge、MA 02138 USA
Phone: +1 (617) 873-3000
EMail: craig@bbn.com
Alden Jackson BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
オールデンジャクソンBBNテクノロジーズ10モールトンストリートケンブリッジ、マサチューセッツ州02138 USA
Phone: +1 (617) 873-3000
EMail: awjacks@bbn.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。