この文書はRFC3228の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group                                          B. Fenner
Request for Comments: 3228                                 AT&T Research
BCP: 57                                                    February 2002
Category: Best Current Practice


                        IANA Considerations for
             IPv4 Internet Group Management Protocol (IGMP)
        ＩＰｖ４インターネットグループ管理プロトコル（ＩＧＭＰ）
                            に対するＩＡＮＡ考慮

Status of this Memo
この文書の状態


   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.
   この文書はインターネット共同体のために現在のインターネットの最良実
   践を指定し、改良のために議論と提案を求めます。このメモの配布は無制
   限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract
概要

   This memo requests that the IANA create a registry for fields in the
   IGMP (Internet Group Management Protocol) protocol header, and
   provides guidance for the IANA to use in assigning parameters for
   those fields.
   このメモはＩＧＭＰ（インターネットグループ管理プロトコル）プロトコル
   ヘッダーでＩＡＮＡがフィールドのための登記所を作ることを要請し、それ
   らのフィールドにＩＡＮＡがパラメータを割り当てる際に使うべき指導を提
   供します。

Table of Contents
目次

   1.  Introduction
   1.  はじめに
   2.  IANA Considerations for fields in the IPv4 IGMP header
   2.  ＩＰｖ４ＩＧＭＰヘッダフィールドに対するＩＡＮＡ考慮
   3.  Assignments for testing and experimentation
   3.  テストと実験のための割り当て
   4.  Security Considerations
   4.  セキュリティの考慮
   5.  Normative References
   5.  参照する参考文献

   6.  Informative References
   6.  有益な参考文献
   7.  Author's Address
   7.  著者のアドレス
   8.  Full Copyright Statement
   8.  著作権表示全文

1.  Introduction
1.  はじめに

   This memo requests that the IANA create a registry for fields in the
   IGMP protocol header.
   このメモはＩＡＮＡがＩＧＭＰプロトコルヘッダフィールドのために登記所
   を作ることを要請します。


   The terms "Specification Required", "Expert Review", "IESG Approval",
   "IETF Consensus", and "Standards Action", are used in this memo to
   refer to the processes described in [2].
   用語「要求される仕様書」、「専門家再調査」、「ＩＥＳＧ承認」、「ＩＥ
   ＴＦ合意」と「標準化行動」は[2]で記述されたプロセスを参照するためこの
   メモで使われます。

2.  IANA Considerations for fields in the IPv4 IGMP header
2.  ＩＰｖ４ＩＧＭＰヘッダフィールドに対するＩＡＮＡ考慮

   The IPv4 IGMP header [1] contains the following fields that carry
   values assigned from IANA-managed name spaces: Type and Code.  Code
   field values are defined relative to a specific Type value.
   ＩＰｖ４ＩＧＭＰヘッダ[1]はＩＡＮＡによって管理された名前空間から割り
   当てられた値を運ぶ次のフィールドを含んでいます：タイプとコード。コー
   ドフィールド値が特定のタイプ値と関連して定義されます。

   Values for the IPv4 IGMP Type fields are allocated using an IESG
   Approval or Standards Action processes.  Code Values for existing
   IPv4 IGMP Type fields are allocated using IESG Approval or Standards
   Action processes.  The policy for assigning Code values for new IPv4
   IGMP Types should be defined in the document defining the new Type
   value.
   ＩＰｖ４ＩＧＭＰタイプフィールドの値がＩＥＳＧ承認あるいは標準化行動
   プロセスを使って割り当てられます。既存のＩＰｖ４ＩＧＭＰタイプフィー
   ルドのコード値がＩＥＳＧ承認あるいは標準化行動プロセスを使って割り当
   てられます。新しいＩＰｖ４ＩＧＭＰタイプのためにコード値を割り当てる
   ためのポリシーは新しいタイプ値を定義している文書で定義されるべきです。

3.  Assignments for testing and experimentation
3.  テストと実験のための割り当て


   Instead of suggesting temporary assignments as in [3], this document
   follows the lead of [4] and assigns a range of values for
   experimental use.  The IGMP Code values 240-255 inclusive (0xf0 -
   0xff) are reserved for protocol testing and experimentation.
   [3]のように一時的割り当てを提案する代わりに、この文書は[4]の案内に従っ
   て、実験的な使用のための広範囲の値を割り当てます。ＩＧＭＰコード値
   ２４０-２５５（0xf0 - 0xff）はプロトコルテストと実験のために確保され
   ます。

   Systems should silently ignore IGMP messages with unknown Code
   values.
   システムが未知のコード値のＩＧＭＰメッセージを静かに無視するべきです。

4.  Security Considerations
4.  セキュリティの考慮

   Security analyzers such as firewalls and network intrusion detection
   monitors often rely on unambiguous interpretations of the fields
   described in this memo.  As new values for the fields are assigned,
   existing security analyzers that do not understand the new values may
   fail, resulting in either loss of connectivity if the analyzer
   declines to forward the unrecognized traffic, or loss of security if
   it does forward the traffic and the new values are used as part of an
   attack.  This vulnerability argues for high visibility (which the
   Standards Action and IETF Consensus processes ensure) for the
   assignments whenever possible.
   ファイアウォールのようなセキュリティ分析機とネットワーク侵入検出モニ
   ターがしばしばこのメモで記述されたフィールドの明確な解釈に頼ります。
   フィールドの新しい値が割り当てられるにつれて、新しい値を理解しない既
   存のセキュリティアナライザが認識できないがトラフィックの転送を拒否す
   れば接続性が失われたり、もしアナライザが認識できないがトラフィックを
   転送し、そして新しい値が攻撃の一部として用いられるなら、セキュリティ
   の損失をもたらし、失敗するかもしれません。この弱点は、割当て時に可能
   であれば高い視点で議論します（標準化行動とＩＥＴＦ合意) プロセスが保
   証します。

5.  Normative References
5.  参照する参考文献



   [1]   Fenner, W., "Internet Group Management Protocol, Version 2",
         RFC 2236, November 1997.

   [2]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

6.  Informative References
6.  有益な参考文献


   [3]   Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
         Values In the Internet Protocol and Related Headers", BCP 37,
         RFC 2780, March 2000.

   [4]   Narten, T., "Assigning Experimental and Testing Numbers
         Considered Useful", Work in Progress.

7.  Author's Address
7.  著者のアドレス

         Bill Fenner
         AT&T Labs -- Research
         75 Willow Rd
         Menlo Park, CA 94025
         USA

         EMail: fenner@research.att.com

8.  Full Copyright Statement
8.  著作権表示全文

   Copyright (C) The Internet Society (2002).  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 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.
   ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。