IPv6 ルータ警告オプション

広告

広告

原文

最終更新
2006-11-28T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/rfc2711.html#source

IPv6 ルータ警告オプション(和訳)

最終更新
2006-11-28T00:00:00+09:00
この記事のURI参照
http://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ホップバイホップオプションタイプについて触れるものである。特定の宛先へのアドレスを持つデータグラムが経路上のルータに特別な処理を要求する情報を含む状況で、このオプションは有用である。

1.0 序論

   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].

当文書内で登場するMUSTMUST NOTREQUIREDSHALLSHALL NOTSHOULDSHOULD NOTRECOMMENDEDMAYOPTIONALの意味は、[RFC 2119]の通り解釈するものとする。

2.0 方法

   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のようにプロトコルにこのオプションの使用を要求することである。この方法は、通常のデータグラムの転送に少し或いは全くパフォーマンスのペナルティを被らない。このオプションを含まないということは、厳密にデータグラムの中身を調査する必要の無いことをルータに伝えているのに等しい。

2.1 構文

   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
Value
以下のネットワークバイトオーダでの2オクテットコード
values
  • 0:データグラムはマルチキャストリスナ探索メッセージ[RFC-2710]を含む。
  • 1:データグラムはRSVPメッセージを含む。
  • 2:データグラムはアクティブネットワークメッセージを含む。
  • 3-65535:将来のためIANAによって予約されている。
Alignment requirement
2n + 0
      Values are registered and maintained by the IANA.  See section 5.0
      for more details.

値はIANAによって登録され、且つ維持される。より詳しくは5.0 IANAによる考察を参照のこと。

2.2 意味

   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)。

3.0 他のプロトコルとの影響

   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)。

4.0 安全性への配慮

   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)。

5.0 IANAによる考察

   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の総論により割り当てられる。

6.0 知的所有権

   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まで情報を提供願う。

7.0 参照文献

   [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.

6.0 著者への連絡先

   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編集者の職務に対する資金供給は、現在インターネット学会から提供されている。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年11月28日 最終更新:2006年11月28日