RFC 3228 - IANA Considerations for IPv4 Internet Group Management Protocol (IGMP) 日本語訳

URL : https://tools.ietf.org/html/rfc3228
タイトル : RFC 3228 - IPv4インターネットグループ管理プロトコル（IGMP）のためのIANAの考慮事項
翻訳編集 : 自動生成

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.

このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2002）。全著作権所有。

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.

このメモはIANAがIGMP（インターネットグループ管理プロトコル）プロトコルヘッダー内のフィールドのためのレジストリを作成することを要求し、IANAは、これらのフィールドのパラメータを割り当てる際に使用するためのガイダンスを提供します。

Table of Contents

   1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   1
   2. IANA Considerations for fields in the IPv4 IGMP header. . . .   2
   3. Assignments for testing and experimentation . . . . . . . . .   2
   4. Security Considerations . . . . . . . . . . . . . . . . . . .   2
   5. Normative References. . . . . . . . . . . . . . . . . . . . .   2
   6. Informative References. . . . . . . . . . . . . . . . . . . .   3
   7. Author's Address. . . . . . . . . . . . . . . . . . . . . . .   3
   8. Full Copyright Statement. . . . . . . . . . . . . . . . . . .   4

1. Introduction

1. はじめに

This memo requests that the IANA create a registry for fields in the IGMP protocol header.

このメモはIANAがIGMPプロトコルヘッダ内のフィールドのためのレジストリを作成することを要求します。

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

用語「仕様が必要」、「エキスパートレビュー」、「IESG承認」、「IETFコンセンサス」、および「標準アクションは」、[2]に記載の方法を参照するためにこのメモで使用されています。

2. IANA Considerations for fields in the IPv4 IGMP header

IPv4のIGMPヘッダ内のフィールド2. IANAの考慮事項

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.

タイプとコード：IPv4のIGMPヘッダ[1]はIANA管理名前空間から割り当てられた値を運ぶ次のフィールドを含んでいます。コード・フィールド値は、特定のタイプの値に対して定義されています。

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.

IPv4のIGMPタイプフィールドの値は、IESG ApprovalかStandards Actionプロセスを使用して割り当てられています。既存のIPv4 IGMPタイプフィールドのコード値はIESG ApprovalかStandards Actionプロセスを使用して割り当てられています。新しいIPv4のIGMPタイプのコード値を割り当てるためのポリシーは、新しいタイプの値を定義する文書で定義する必要があります。

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]のリードに従い、実験的使用のための値の範囲を割り当てます。プロトコルテストと実験のために予約されている - IGMPコード240~255包括（0xFFで0xF0が）が値。

Systems should silently ignore IGMP messages with unknown Code values.

システムは黙って、未知のコード値を持つIGMPメッセージを無視すべきです。

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.

ファイアウォールやネットワーク侵入検知モニターなどのセキュリティアナライザは、多くの場合、このメモに記載されているフィールドの明確な解釈に依存しています。フィールドの新しい値が割り当てられているとして、それはトラフィックを転送していた場合、新しい値を理解していないセキュリティアナライザを既存のは、アナライザの下落が認識されていないトラフィックを転送する場合は、接続のいずれかの損失で、その結果、失敗、またはセキュリティの損失も新しい値は、攻撃の一部として使用されています。この脆弱性は、可能な限りの割り当てのための（標準アクションとIETFコンセンサスプロセスが確保）高い視認性のために主張します。

5. Normative References

5.引用規格

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

[1]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。

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

[2] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。

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.

[3]ブラドナー、S.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC 2780、2000年3月を。

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

[4] Narten氏、T.、「役に立つと考えられた実験的でテスト番号の割り当て」が進行中で働いています。

7. Author's Address

7.著者のアドレス

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

EMail: fenner@research.att.com

メールアドレス：fenner@research.att.com

8. Full Copyright Statement

8.完全な著作権声明

著作権（C）インターネット協会（2002）。全著作権所有。

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 Editor機能のための基金は現在、インターネット協会によって提供されます。