[要約] 要約：RFC 7279は、新しいICMPタイプとコードの使用に関する受け入れ可能な使用ポリシーを提供しています。 目的：このRFCの目的は、ネットワーク上での新しいICMPタイプとコードの使用を制御し、ネットワークの安定性とセキュリティを確保することです。
Internet Engineering Task Force (IETF) M. Shore
Request for Comments: 7279 No Mountain Software
BCP: 189 C. Pignataro
Category: Best Current Practice Cisco Systems, Inc.
ISSN: 2070-1721 May 2014
An Acceptable Use Policy for New ICMP Types and Codes
新しいICMPタイプとコードの許容される使用ポリシー
Abstract
概要
In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use.
このドキュメントでは、IPスタックにおけるICMPの役割の基本的な説明と、将来使用するためのいくつかのガイドラインを提供します。
This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.
このドキュメントは、新しいインターネット制御メッセージプロトコル（ICMP）のタイプやコードをいつ追加するかについての明確さの欠如に関する懸念に動機付けられています。これらの懸念により、ICMPに新しい機能を追加することが望ましい場合とそうでない場合のポリシーを説明する必要性が強調されています。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7279.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7279で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acceptable Use Policy . . . . . . . . . . . . . . . . . . . . 2
2.1. Classification of Existing Message Types . . . . . . . . 3
2.1.1. ICMP Use as a Routing Protocol . . . . . . . . . . . 6
2.1.2. A Few Notes on RPL . . . . . . . . . . . . . . . . . 6
2.2. Applications Using ICMP . . . . . . . . . . . . . . . . . 7
2.3. Extending ICMP . . . . . . . . . . . . . . . . . . . . . 7
2.4. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . 7
3. ICMP's Role in the Internet . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative references . . . . . . . . . . . . . . . . . . 8
6.2. Informative references . . . . . . . . . . . . . . . . . 9
There has been some recent concern expressed about a lack of clarity around when new message types and codes should be added to ICMP (including ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We lay out a policy regarding when (and when not) to move functionality into ICMP.
新しいメッセージタイプとコードをICMP（ICMPv4 [RFC0792]とICMPv6 [RFC4443]を含む）にいつ追加するかについての明確さの欠如について最近懸念が表明されています。機能をICMPに移す時期（および時期）に関するポリシーを示します。
This document is the result of discussions among ICMP experts within the Operations and Management (OPS) area's IP Diagnostics Technical Interest Group [DIAGNOSTICS] and concerns expressed by the OPS area leadership.
このドキュメントは、運用と管理（OPS）領域のIP診断技術的関心グループ[診断]内のICMP専門家による議論と、OPS領域のリーダーシップが表明した懸念の結果です。
Note that this document does not supercede the "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780], which specifies best practices and processes for the allocation of values in the IANA registries but does not describe the policies to be applied in the standards process.
このドキュメントは、「インターネットプロトコルと関連ヘッダーの値のIANA割り当てガイドライン」[RFC2780]に優先しないことに注意してください。これは、IANAレジストリでの値の割り当てに関するベストプラクティスとプロセスを指定していますが、適用されるポリシーについては説明していません標準プロセスで。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In this document, we describe an acceptable use policy for new ICMP message types and codes, and provide some background about the policy.
このドキュメントでは、新しいICMPメッセージタイプとコードの許容される使用ポリシーについて説明し、ポリシーに関する背景情報を提供します。
In summary, any future message types added to ICMP should be limited to two broad categories:
要約すると、ICMPに追加される今後のメッセージタイプは、2つの広範なカテゴリに限定する必要があります。
1. to inform a datagram's originator that a forwarding plane anomaly has been encountered downstream. The datagram originator must be able to determine whether or not the datagram was discarded by examining the ICMP message.
1. 転送プレーンの異常がダウンストリームで発生したことをデータグラムの発信者に通知します。データグラムの発信者は、ICMPメッセージを調べることにより、データグラムが破棄されたかどうかを判別できる必要があります。
2. to discover and convey dynamic information about a node (other than information usually carried in routing protocols), to discover and convey network-specific parameters, and to discover on-link routers and hosts.
2. ノードに関する動的な情報（通常はルーティングプロトコルで伝達される情報以外）を発見して伝達し、ネットワーク固有のパラメーターを発見して伝達し、リンク上のルーターとホストを発見します。
Normally, ICMP SHOULD NOT be used to implement a general-purpose routing or network management protocol. However, ICMP does have a role to play in conveying dynamic information about a network, which would belong in category 2 above.
通常、ICMPは、汎用ルーティングまたはネットワーク管理プロトコルの実装に使用すべきではありません（SHOULD NOT）。ただし、ICMPは、ネットワークに関する動的情報を伝達する役割を果たします。ネットワークは、上記のカテゴリ2に属します。
This section provides a rough breakdown of existing message types according to the taxonomy described in Section 2 at the time of publication.
このセクションでは、公開時にセクション2で説明されている分類法に従って、既存のメッセージタイプの大まかな内訳を示します。
IPv4 forwarding plane anomaly reporting:
IPv4転送プレーンの異常報告：
3: Destination Unreachable
3：宛先に到達できません
4: Source Quench (Deprecated)
4：ソースクエンチ（非推奨）
6: Alternate Host Address (Deprecated)
6：代替ホストアドレス（非推奨）
11: Time Exceeded
11：時間超過
12: Parameter Problem
12：パラメータの問題
31: Datagram Conversion Error (Deprecated)
31：データグラム変換エラー（非推奨）
IPv4 router or host discovery:
IPv4ルーターまたはホストの検出：
0: Echo Reply
0：エコー応答
5: Redirect
5：リダイレクト
8: Echo
8：エコー
9: Router Advertisement 10: Router Solicitation
9：ルーター広告10：ルーター要請
13: Timestamp
13：タイムスタンプ
14: Timestamp Reply
14：タイムスタンプ応答
15: Information Request (Deprecated)
15：情報リクエスト（非推奨）
16: Information Reply (Deprecated)
16：情報返信（非推奨）
17: Address Mask Request (Deprecated)
17：アドレスマスクリクエスト（非推奨）
18: Address Mask Reply (Deprecated)
18：アドレスマスク応答（非推奨）
30: Traceroute (Deprecated)
30：Traceroute（非推奨）
32: Mobile Host Redirect (Deprecated)
32：モバイルホストリダイレクト（非推奨）
33: IPv6 Where-Are-You (Deprecated)
33：IPv6 Where-Are-You（非推奨）
34: IPv6 I-Am-Here (Deprecated)
34：IPv6 I-Am-Here（非推奨）
35: Mobile Registration Request (Deprecated)
35：モバイル登録リクエスト（非推奨）
36: Mobile Registration Reply (Deprecated)
36：モバイル登録応答（非推奨）
37: Domain Name Request (Deprecated)
37：ドメイン名リクエスト（非推奨）
38: Domain Name Reply (Deprecated)
38：ドメイン名応答（非推奨）
39: SKIP (Deprecated)
39：SKIP（非推奨）
40: Photuris
40：フォトゥリス
41: ICMP messages utilized by experimental mobility protocols such as Seamoby
41：Seamobyなどの実験的なモビリティプロトコルで利用されるICMPメッセージ
Please note that some ICMP message types were formally deprecated by [RFC6918].
一部のICMPメッセージタイプは、[RFC6918]によって正式に非推奨になったことに注意してください。
IPv6 forwarding plane anomaly reporting:
IPv6転送プレーンの異常報告：
1: Destination Unreachable
1：宛先に到達できません
2: Packet Too Big 3: Time Exceeded
2：大きすぎるパケット3：時間超過
4: Parameter Problem
4：パラメータの問題
150: ICMP messages utilized by experimental mobility protocols such as Seamoby
150：Seamobyなどの実験的なモビリティプロトコルで利用されるICMPメッセージ
IPv6 router or host discovery:
IPv6ルーターまたはホストの検出：
128: Echo Request
128：エコー要求
129: Echo Reply
129：エコー応答
130: Multicast Listener Query
130：マルチキャストリスナークエリ
131: Multicast Listener Report
131：マルチキャストリスナーレポート
132: Multicast Listener Done
132：マルチキャストリスナーが完了しました
133: Router Solicitation
133：ルーター要請
134: Router Advertisement
134：ルーターアドバタイズメント
135: Neighbor Solicitation
135：近隣要請
136: Neighbor Advertisement
136：ネイバーアドバタイズメント
137: Redirect Message
137：リダイレクトメッセージ
138: Router Renumbering
138：ルーターの再番号付け
139: ICMP Node Information Query
139：ICMPノード情報クエリ
140: ICMP Node Information Response
140：ICMPノード情報応答
141: Inverse Neighbor Discovery Solicitation Message
141：逆近傍探索要請メッセージ
142: Inverse Neighbor Discovery Advertisement Message
142：逆ネイバー探索アドバタイズメントメッセージ
143: Version 2 Multicast Listener Report
143：バージョン2マルチキャストリスナーレポート
144: Home Agent Address Discovery Request Message
144：Home Agent Address Discovery Request Message
145: Home Agent Address Discovery Reply Message
145：Home Agent Address Discovery Reply Message
146: Mobile Prefix Solicitation 147: Mobile Prefix Advertisement
146：モバイルプレフィックス要請147：モバイルプレフィックスアドバタイズメント
148: Certification Path Solicitation Message
148：認定パス要請メッセージ
149: Certification Path Advertisement Message
149：証明書パスアドバタイズメントメッセージ
150: ICMP messages utilized by experimental mobility protocols such as Seamoby
150：Seamobyなどの実験的なモビリティプロトコルで利用されるICMPメッセージ
151: Multicast Router Advertisement
151：マルチキャストルーターアドバタイズメント
152: Multicast Router Solicitation
152：マルチキャストルーター要請
153: Multicast Router Termination
153：マルチキャストルーターの終了
154: FMIPv6 Messages
154：FMIPv6メッセージ
155: RPL Control Message
155：RPL制御メッセージ
As mentioned in Section 2, using ICMP as a general-purpose routing or network management protocol is not advisable and SHOULD NOT be used that way.
セクション2で述べたように、ICMPを汎用のルーティングまたはネットワーク管理プロトコルとして使用することはお勧めできません。そのように使用すべきではありません。
ICMP has a role in the Internet as an integral part of the IP layer; it is not as a routing protocol or as a transport protocol for other layers including routing information. From a more pragmatic perspective, some of the key characteristics of ICMP make it a less-than-ideal choice for a routing protocol. These key characteristics include that ICMP is frequently filtered, is not authenticated, and is easily spoofed. In addition, specialist hardware processing of ICMP would disrupt the deployment of an ICMP-based routing or management protocol.
ICMPは、IP層の不可欠な部分としてインターネットで役割を果たします。これは、ルーティングプロトコルとしても、ルーティング情報を含む他のレイヤーのトランスポートプロトコルとしても使用されません。より実用的な観点から見ると、ICMPのいくつかの主要な特性により、ICMPはルーティングプロトコルにとって理想的とは言えない選択肢となっています。これらの重要な特性には、ICMPが頻繁にフィルタリングされ、認証されず、簡単にスプーフィングされることが含まれます。さらに、ICMPの専門的なハードウェア処理は、ICMPベースのルーティングまたは管理プロトコルの展開を妨害します。
RPL, the IPv6 routing protocol for low-power and lossy networks (see [RFC6550]) uses ICMP as a transport. In this regard, it is an exception among the ICMP message types. Note that, although RPL is an IP routing protocol, it is not deployed on the general Internet; it is limited to specific, contained networks.
RPL、低電力で損失の多いネットワーク（[RFC6550]を参照）のIPv6ルーティングプロトコルは、トランスポートとしてICMPを使用します。この点で、これはICMPメッセージタイプの例外です。 RPLはIPルーティングプロトコルですが、一般的なインターネットには展開されていないことに注意してください。特定の封じ込めネットワークに限定されます。
This should be considered anomalous and is not a model for future ICMP message types. That is, ICMP is not intended as a transport for other protocols and SHOULD NOT be used in that way in future specifications. In particular, while it is adequate to use ICMP as a discovery protocol, it does not extend to full routing capabilities.
これは異常と見なされるべきであり、将来のICMPメッセージタイプのモデルではありません。つまり、ICMPは他のプロトコルのトランスポートとしては意図されておらず、将来の仕様ではそのように使用すべきではありません（SHOULD NOT）。特に、ICMPを検出プロトコルとして使用することは適切ですが、完全なルーティング機能にまでは拡張されません。
Some applications make use of ICMP error notifications, or even deliberately create anomalous conditions in order to elicit ICMP messages. These ICMP messages are then used to generate feedback to the higher layer. Some of these applications include some of the most widespread examples, such as PING, TRACEROUTE, and Path MTU Discovery (PMTUD). These uses are considered acceptable because they use existing ICMP message types and do not change ICMP functionality.
一部のアプリケーションは、ICMPエラー通知を利用するか、ICMPメッセージを引き出すために意図的に異常な状態を作成します。これらのICMPメッセージは、上位層へのフィードバックを生成するために使用されます。これらのアプリケーションの一部には、PING、TRACEROUTE、Path MTU Discovery（PMTUD）など、最も広く使用されている例が含まれています。これらの使用は、既存のICMPメッセージタイプを使用し、ICMP機能を変更しないため、許容できると見なされます。
ICMP multi-part messages are specified in [RFC4884] by defining an extension mechanism for selected ICMP messages. This mechanism addresses a fundamental problem in ICMP extensibility. An ICMP multi-part message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
ICMPマルチパートメッセージは、選択したICMPメッセージの拡張メカニズムを定義することによって[RFC4884]で指定されています。このメカニズムは、ICMP拡張性の根本的な問題に対処します。 ICMPマルチパートメッセージは、ICMPメッセージが以前に伝達したすべての情報と、アプリケーションが必要とする追加情報を伝達します。
Some currently defined ICMP extensions include ICMP extensions for Multiprotocol Label Switching [RFC4950] and ICMP extensions for interface and next-hop identification [RFC5837].
現在定義されているICMP拡張には、マルチプロトコルラベルスイッチング用のICMP拡張[RFC4950]と、インターフェイスおよびネクストホップ識別用のICMP拡張[RFC5837]が含まれます。
Extensions to ICMP SHOULD follow the requirements provided in [RFC4884].
ICMPの拡張機能は、[RFC4884]で提供される要件に従う必要があります（SHOULD）。
Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 routers, IPv6-capable security gateways, and IPv6-capable firewalls normally support administrator configuration of how specific ICMPv6 message types are handled. By contrast, deployed IPv4 routers, IPv4-capable security gateways, and IPv4-capable firewalls are less likely to allow an administrator to configure how specific ICMPv4 message types are handled. So, at present, ICMPv6 messages usually have a higher probability of travelling end-to-end than ICMPv4 messages.
ICMPv6はIPv6近隣探索に使用されるため、展開されたIPv6ルーター、IPv6対応セキュリティゲートウェイ、およびIPv6対応ファイアウォールは通常、特定のICMPv6メッセージタイプの処理方法の管理者設定をサポートします。対照的に、展開されたIPv4ルーター、IPv4対応のセキュリティゲートウェイ、およびIPv4対応のファイアウォールでは、管理者が特定のICMPv4メッセージタイプの処理方法を構成する可能性が低くなります。したがって、現在のところ、ICMPv6メッセージは通常、ICMPv4メッセージよりもエンドツーエンドで移動する可能性が高くなっています。
ICMP was originally intended to be a mechanism for gateways or destination hosts to report error conditions back to source hosts in ICMPv4 [RFC0792]; ICMPv6 [RFC4443] is modeled after it. ICMP is also used to perform IP-layer functions, such as diagnostics (e.g., PING).
ICMPはもともと、ゲートウェイまたは宛先ホストがICMPv4 [RFC0792]でソースホストにエラー状態を報告するためのメカニズムであることを目的としていました。 ICMPv6 [RFC4443]はそれをモデルにしています。 ICMPは、診断（PINGなど）などのIPレイヤー機能の実行にも使用されます。
ICMP is defined to be an integral part of IP and must be implemented by every IP module. This is true for ICMPv4 as an integral part of IPv4 (see the Introduction of [RFC0792]), and for ICMPv6 as an integral part of IPv6 (see Section 2 of [RFC4443]). When first defined, ICMP messages were thought of as IP messages that didn't carry any higher-layer data. It could be conjectured that the term "control" was used because ICMP messages were not "data" messages.
ICMPはIPの不可欠な部分として定義されており、すべてのIPモジュールで実装する必要があります。これは、IPv4の統合部分としてのICMPv4（[RFC0792]の概要を参照）、およびIPv6の統合部分としてのICMPv6（[RFC4443]のセクション2を参照）にも当てはまります。 ICMPメッセージは、最初に定義されたとき、上位層のデータを含まないIPメッセージと見なされていました。 ICMPメッセージが「データ」メッセージではなかったため、「制御」という用語が使用されたと推測できます。
The word "control" in the protocol name did not describe ICMP's function (i.e., it did not "control" the Internet); rather, it was used to communicate about the control functions in the Internet. For example, even though ICMP included a redirect message type that affects routing behavior in the context of a LAN segment, it was not and is not used as a generic routing protocol.
プロトコル名の「制御」という言葉はICMPの機能を説明していませんでした（つまり、インターネットを「制御」していませんでした）。むしろ、インターネットの制御機能について通信するために使用されました。たとえば、ICMPには、LANセグメントのコンテキストでのルーティング動作に影響を与えるリダイレクトメッセージタイプが含まれていましたが、汎用ルーティングプロトコルとしては使用されておらず、使用されていません。
This document describes a high-level policy for adding ICMP types and codes. While special attention must be paid to the security implications of any particular new ICMP type or code, this recommendation presents no new security considerations.
このドキュメントでは、ICMPタイプとコードを追加するための高レベルのポリシーについて説明します。特定の新しいICMPタイプまたはコードのセキュリティへの影響に特別な注意を払う必要がありますが、この推奨事項では新しいセキュリティの考慮事項はありません。
From a security perspective, ICMP plays a part in the Photuris protocol [RFC2521]. But more generally, ICMP is not a secure protocol and does not include features to be used to discover network security parameters or to report on network security anomalies in the forwarding plane.
セキュリティの観点から、ICMPはPhoturisプロトコル[RFC2521]で役割を果たす。ただし、より一般的には、ICMPは安全なプロトコルではなく、ネットワークセキュリティパラメータを検出したり、フォワーディングプレーンのネットワークセキュリティ異常をレポートしたりするために使用される機能が含まれていません。
Additionally, new ICMP functionality (e.g., ICMP extensions, or new ICMP types or codes) needs to consider potential ways that ICMP can be abused (e.g., Smurf IP DoS [CA-1998-01]).
さらに、新しいICMP機能（例：ICMP拡張、または新しいICMPタイプまたはコード）は、ICMPが悪用される可能性のある方法（例：Smurf IP DoS [CA-1998-01]）を考慮する必要があります。
This document was originally proposed by, and received substantial review and suggestions from, Ron Bonica. Discussions with Pascal Thubert helped clarify the history of RPL's use of ICMP. We are very grateful for the review, feedback, and comments from Ran Atkinson, Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much improved document.
このドキュメントは、もともとRon Bonicaによって提案され、Ron Bonicaから大幅なレビューと提案を受けました。 Pascal Thubertとの議論は、RPLによるICMPの使用の歴史を明確にするのに役立ちました。 Ran Atkinson、Tim Chown、Joe Clarke、Adrian Farrel、Ray Hunter、Hirarie Orman、Eric Rosen、JINMEI Tatuya、Wen Zhangからのレビュー、フィードバック、コメントに非常に感謝しており、ドキュメントが大幅に改善されました。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「拡張ICMPによるマルチパートメッセージのサポート」、RFC 4884、2007年4月。
[CA-1998-01] CERT, "Smurf IP Denial-of-Service Attacks", CERT Advisory CA-1998-01, January 1998, <http://www.cert.org/advisories/CA-1998-01.html>.
[CA-1998-01] CERT、「Smurf IPサービス拒否攻撃」、CERT Advisory CA-1998-01、1998年1月、<http://www.cert.org/advisories/CA-1998-01。 html>。
[DIAGNOSTICS] "IP Diagnostics Technical Interest Group", , <https://svn.tools.ietf.org/area/ops/trac/wiki/ TIG_DIAGNOSTICS>.
[診断] "IP Diagnostics Technical Interest Group"、、<https://svn.tools.ietf.org/area/ops/trac/wiki/ TIG_DIAGNOSTICS>。
[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
[RFC2521] Karn、P。およびW. Simpson、「ICMP Security Failures Messages」、RFC 2521、1999年3月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780] Bradner、S。およびV. Paxson、「IANA Allocation Allocation Guidelines for Values in the Internet Protocol and Related Headers」、BCP 37、RFC 2780、2000年3月。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007.
[RFC4950] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「ICMP Extensions for Multiprotocol Label Switching」、RFC 4950、2007年8月。
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.
[RFC5837] Atlas、A.、Bonica、R.、Pignataro、C.、Shen、N.、JR。 Rivers、「Interface and Next-Hop IdentificationのためのICMPの拡張」、RFC 5837、2010年4月。
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550]冬、T.、Thubert、P.、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP、およびR 。Alexander、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、2012年3月。
[RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some ICMPv4 Message Types", RFC 6918, April 2013.
[RFC6918] Gont、F。およびC. Pignataro、「正式にはいくつかのICMPv4メッセージタイプの非推奨」、RFC 6918、2013年4月。
Authors' Addresses
著者のアドレス
Melinda Shore No Mountain Software PO Box 16271 Two Rivers, AK 99716 US
Melinda Shore No Mountain Software PO Box 16271 Two Rivers、AK 99716 US
Phone: +1 907 322 9522
EMail: melinda.shore@nomountain.net
Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Carlos Pignataro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709 US
EMail: cpignata@cisco.com