広告
広告
https://www.7key.jp/rfc/rfc2711.html#source
https://www.7key.jp/rfc/rfc2711.html#translation
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.
当文書はインターネットコミュニティに役立つであろうインターネット標準プロトコルを提供するものであり、改良のための議論や提案を求めるものである。当プロトコル標準化の状況と現状については"Internet Official Protocol Standards"(STD1)の最新版を参照のこと。尚、当文書の配布に制限は設けていない。
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
このメモは、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].
当文書内で登場するMUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONALの意味は、[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ホップバイホップヘッダオプションを定義することであり、ISVPのようにプロトコルにこのオプションの使用を要求することである。この方法は、通常のデータグラムの転送に少し或いは全くパフォーマンスのペナルティを被らない。このオプションを含まないということは、厳密にデータグラムの中身を調査する必要の無いことをルータに伝えているのに等しい。
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つだけのオプションがなければならない(MUST)。
Value: A 2 octet code in network byte order with the following values: 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. Alignment requirement: 2n+0
Values are registered and maintained by the IANA. See section 5.0 for more details.
値はIANAによって登録され、且つ維持される。より詳しくは5.0 IANAによる考察を参照のこと。
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データグラムの最終宛先は、データグラムの複数の評価を防ぐために受信時にこのオプションを無視しなければならない(MUST)。識別されないvalueフィールドは、無視されなければならず(MUST)、ヘッダの処理は続けられる。
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.
このオプションを識別するルータは、更なる処理が必要かどうかを決定するため、より厳密に搬送中のデータグラムを調査するだろう。ルータは、興味のある内容を含むパケットであるかどうかを決定するため、十分詳細にパケットを解析する必要がある。通過ルータによるデータグラム処理速度を上げるため、実装はvalueフィールドを用いる。
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ルータとしてのどちらとして行動すればよいかについて非常に曖昧なものとなる。正確にルータが内容をどのように処理するかは、valueフィールドが指定をする。しかし、データグラムに要求される処理がIPv6データグラムのペイロードの調査を含むのであれば、中継ルータはホストとして振る舞い、ホストとしてデータを解釈すべきである(SHOULD)。
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.
有効なこのオプションについて、データグラム上で重要な処理を行うルータへ直接アドレス付けられないことが予期されるプロトコルでは必須となれなければならない(MUST)。データグラムがルータへの警告オプションを含まないのであれば、ルータはアドレス付けられないデータグラムの調査を要求されない。
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ホップバイホップオプションヘッダにこのオプションを含まなければならない(MUST)。
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.
従って、ルータでサポートされるのであれば、このオプションの使用は通過ルータによって速度もしくは他の項目によって制限されることがある(MAY)。
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 構文で触れたvalueフィールドは、IANAによって登録され且つ維持される。新しい値は、RFC2434[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.
当文書に記された実装や技術に関して主張される知的財産やその他の権利の有効性や範囲について、またこれらの権利の元でライセンスが利用可能か不可能化について、IETHはいかなる立場もとらない(そのような権利を確認する努力をしたわけではない)。IETFの標準手続きと標準関連文書での権利に関する手順はBCP11を参照のこと。出版に利用する権利やライセンス保証、この仕様書の実装者や利用者の所有権の一般的なライセンスや許可の取得については、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 Executive Directorまで情報を提供願う。
[RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1977. [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC 2205, September 1997. [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
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 Phone: +1 (617) 873-3000 EMail: awjacks@bbn.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
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 implmentation 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.
当文書とそれに含む情報は無保証で提供され、そしてインターネット学会とIETFは――明示的にも暗黙的にも――この情報の利用が権利を侵害しないことや、特別の目的への利用に適当であることの保証を含め、全ての保証を拒否するものである。
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC編集者の職務に対する資金供給は、現在インターネット学会から提供されている。
広告