[要約] RFC 4890は、ファイアウォールでICMPv6メッセージをフィルタリングするための推奨事項を提供しています。このRFCの目的は、ネットワークセキュリティを向上させ、不正なトラフィックや攻撃からネットワークを保護することです。
Network Working Group E. Davies
Request for Comments: 4890 Consultant
Category: Informational J. Mohacsi
NIIF/HUNGARNET
May 2007
Recommendations for Filtering ICMPv6 Messages in Firewalls
ファイアウォールでICMPV6メッセージをフィルタリングするための推奨事項
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.
IPv6をサポートするネットワークでは、インターネットコントロールメッセージプロトコルバージョン6（ICMPV6）は、多数の関数と、それに応じて多数のメッセージタイプとオプションを備えた基本的な役割を果たします。ICMPV6はIPv6の機能に不可欠ですが、ICMPV6メッセージの制御されていない転送に関連する多くのセキュリティリスクがあります。IPv4ネットワーク内の対応するプロトコルであるICMP向けに設計されたフィルタリング戦略は、正しい機能に必要ではない有用な補助プロトコルに対応することを目的としているため、直接適用できません。
This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks.
このドキュメントは、ネットワークの機能を維持するために必要なが潜在的なセキュリティリスクであるメッセージをドロップするために必要なICMPV6メッセージの伝播を可能にするICMPV6ファイアウォールフィルター構成に関するいくつかの推奨事項を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6
2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6
2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6
2.3. Network Topology and Address Scopes . . . . . . . . . . . 7
2.4. Role in Establishing and Maintaining Communication . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 9
3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . . 9
3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 10
3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10
4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10
4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11
4.2. Interaction of Link-Local Messages with
Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12
4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 13
4.3.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 14
4.3.2. Traffic That Normally Should Not Be Dropped . . . . . 14
4.3.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 15
4.3.4. Traffic for Which a Policy Should Be Defined . . . . . 16
4.3.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 17
4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 18
4.4.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 18
4.4.2. Traffic That Normally Should Not Be Dropped . . . . . 19
4.4.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 19
4.4.4. Traffic for Which a Policy Should Be Defined . . . . . 20
4.4.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 24
A.1. Destination Unreachable Error Message . . . . . . . . . . 24
A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 24
A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 25
A.4. Parameter Problem Error Message . . . . . . . . . . . . . 25
A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 26
A.6. Neighbor Solicitation and Neighbor Advertisement
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.7. Router Solicitation and Router Advertisement Messages . . 27
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 27
A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 27
A.10. Multicast Listener Discovery Messages . . . . . . . . . . 27
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 28
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 28
A.13. Node Information Query and Reply . . . . . . . . . . . . . 28
A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 28
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 29
Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 30
When a network supports IPv6 [RFC2460], the Internet Control Message Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role including being an essential component in establishing and maintaining communications both at the interface level and for sessions to remote nodes. This means that overly aggressive filtering of ICMPv6 by firewalls may have a detrimental effect on the establishment and maintenance of IPv6 communications. On the other hand, allowing indiscriminate passage of all ICMPv6 messages can be a major security risk. This document recommends a set of rules that seek to balance effective IPv6 communication against the needs of site security.
ネットワークがIPv6 [RFC2460]をサポートする場合、インターネットコントロールメッセージプロトコルバージョン6（ICMPV6）[RFC4443]は、インターフェイスレベルでのコミュニケーションの確立と維持に不可欠なコンポーネントであり、リモートノードへのセッションのために、コミュニケーションを確立および維持することを含む基本的な役割を果たします。これは、ファイアウォールによるICMPV6の過度に積極的なフィルタリングが、IPv6通信の確立と維持に有害な影響を与える可能性があることを意味します。一方、すべてのICMPV6メッセージの無差別の通過を許可することは、主要なセキュリティリスクになる可能性があります。このドキュメントは、サイトセキュリティのニーズと効果的なIPv6通信のバランスをとることを目的とする一連のルールを推奨しています。
In a few cases, the appropriate rules will depend on whether the firewall is protecting
いくつかのケースでは、適切なルールはファイアウォールが保護されているかどうかによって異なります
o an individual host,
o 個別のホスト、
o an end site where all ICMPv6 messages originate or terminate within the site, or
o すべてのICMPV6メッセージがサイト内で発生または終了するエンドサイト、または
o a transit site such as an Internet Service Provider's site where some ICMPv6 messages will be passing through.
o ICMPV6メッセージが通過するインターネットサービスプロバイダーのサイトなどのトランジットサイト。
The document suggests alternative rules appropriate to each situation where it is relevant. It also notes some situations where alternative rules could be adopted according to the nature of the work being carried out on the site and consequent security policies. In general, Internet Service Providers should not filter ICMPv6 messages transiting their sites so that all the necessary communication elements are available to their customers to decide and filter according to their policy.
このドキュメントは、関連する各状況に適した代替ルールを提案しています。また、サイトで実行されている作業の性質に応じて代替ルールを採用できる状況と、その結果としてのセキュリティポリシーにも注目しています。一般に、インターネットサービスプロバイダーは、サイトを通過するICMPv6メッセージをフィルタリングして、必要なすべての通信要素が顧客が利用できるように、ポリシーに従って決定およびフィルタリングできるようにする必要があります。
Readers familiar with ICMPv6 can skip to the recommended filtering rules in Section 4 and an example configuration script for Linux Netfilter in Appendix B.
ICMPV6に精通している読者は、セクション4の推奨フィルタリングルールと、付録BのLinux NetFilterの例の構成スクリプトにスキップできます。
ICMPv6 has a large number of functions defined in a number of sub-protocols, and there are a correspondingly large number of messages and options within these messages. The functions currently defined fall into a number of categories:
ICMPV6には、多数のサブプロトコルで定義された多数の機能があり、これらのメッセージ内に多数のメッセージとオプションがあります。現在定義されている関数は、多くのカテゴリに分類されます。
Returning Error Messages
エラーメッセージを返す
* Returning error messages to the source if a packet could not be delivered. Four different error messages, each with a number of sub-types, are specified in [RFC4443].
* パケットを配信できなかった場合、ソースにエラーメッセージを返します。それぞれが多数のサブタイプを備えた4つの異なるエラーメッセージが[RFC4443]で指定されています。
Connection Checking
接続チェック
* Simple monitoring of connectivity through echo requests and responses used by the ping and traceroute utilities. The Echo Request and Echo Response messages are specified in [RFC4443].
* PingおよびTracerouteユーティリティで使用されるエコー要求と応答による接続の簡単な監視。エコーリクエストとエコー応答メッセージは[RFC4443]で指定されています。
Discovery Functions
発見機能
* Finding neighbors (both routers and hosts) connected to the same link and determining their IP and link layer addresses. These messages are also used to check the uniqueness of any addresses that an interface proposes to use (Duplicate Address Detection - DAD). Four messages -- Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Solicitation (RS) and Router Advertisement (RA) -- are specified in [RFC2461].
* 同じリンクに接続され、IPおよびリンクレイヤーアドレスを決定する隣人（ルーターとホストの両方）を見つける。これらのメッセージは、インターフェイスが使用することを提案するアドレスの一意性を確認するためにも使用されます（Duplicate Address Detection -DAD）。4つのメッセージ - Neighbor Solicitation（NS）、Neighbor Advertisement（NA）、Router Solicitation（RS）、Router Advertisement（RA）は[RFC2461]で指定されています。
* Ensuring that neighbors remain reachable using the same IP and link layer addresses after initial discovery (Neighbor Unreachability Discovery - NUD) and notifying neighbors of changes to link layer addresses. Uses NS and NA [RFC2461].
* 最初の発見後に同じIPおよびリンクレイヤーアドレスを使用して隣人が到達可能であることを保証し（近隣の到達不能発見-NUD）、リンクレイヤーアドレスへの変更について隣人に通知します。NSとNA [RFC2461]を使用します。
* Finding routers and determining how to obtain IP addresses to join the subnets supported by the routers. Uses RS and RA [RFC2461].
* ルーターを見つけ、ルーターでサポートされているサブネットを結合するためにIPアドレスを取得する方法を決定します。RSとRA [RFC2461]を使用します。
* If stateless autoconfiguration of hosts is enabled, communicating prefixes and other configuration information (including the link Maximum Transmission Unit (MTU) and suggested hop limit default) from routers to hosts. Uses RS and RA [RFC2462].
* ホストのステートレスオートコンチュレーションが有効になっている場合、プレフィックスとその他の構成情報（リンク最大送信ユニット（MTU）および提案されたホップリミットデフォルトを含む）をルーターからホストに通知します。RSとRA [RFC2462]を使用します。
* When using SEcure Neighbor Discovery (SEND) to authenticate a router attached to a link, the Certificate Path Solicitation and Advertisement messages specified in [RFC3971] are used by hosts to retrieve the certificates documenting the trust chain between a trust anchor and the router from the router.
* セキュアネイバーディスカバリー（送信）を使用してリンクに接続されたルーターを認証する場合、[RFC3971]で指定された証明書パス勧誘と広告メッセージは、ホストが信頼アンカーとルーターの間の信頼チェーンを文書化する証明書を取得するために使用され、ルーター。
* Determining the MTU along a path. The Packet Too Big error message is essential to this function [RFC1981].
* パスに沿ってMTUを決定する。この関数にはパケットが大きすぎるエラーメッセージが不可欠です[RFC1981]。
* Providing a means to discover the IPv6 addresses associated with the link layer address of an interface (the inverse of Neighbor Discovery, where the link layer address is
* インターフェイスのリンクレイヤーアドレスに関連付けられているIPv6アドレスを発見する手段を提供します（リンクレイヤーアドレスがあります。
discovered given an IPv6 address). Two messages, Inverse Neighbor Discovery Solicitation and Advertisement messages, are specified in [RFC3122].
IPv6アドレスが与えられたことを発見）。逆近隣の発見の勧誘と広告メッセージの2つのメッセージが[RFC3122]で指定されています。
* Communicating which multicast groups have listeners on a link to the multicast capable routers connected to the link. Uses messages Multicast Listener Query, Multicast Listener Report (two versions), and Multicast Listener Done (protocol version 1 only) as specified in Multicast Listener Discovery MLDv1 [RFC2710] and MLDv2 [RFC3810].
* どのマルチキャストグループがリンクに接続されたマルチキャスト対応のルーターへのリンクにリスナーを持っているかを伝える。メッセージを使用します。マルチキャストリスナーのクエリ、マルチキャストリスナーレポート（2つのバージョン）、およびマルチキャストリスナーディスカバリーMLDV1 [RFC2710]およびMLDV2 [RFC3810]で指定されているマルチキャストリスナー（プロトコルバージョン1のみ）。
* Discovering multicast routers attached to the local link. Uses messages Multicast Router Advertisement, Multicast Router Solicitation, and Multicast Router Termination as specified in Multicast Router Discovery [RFC4286].
* ローカルリンクに接続されたマルチキャストルーターの発見。メッセージを使用します。マルチキャストルーターの発見[RFC4286]で指定されているように、マルチキャストルーター広告、マルチキャストルーター勧誘、マルチキャストルーター終了。
Reconfiguration Functions
再構成関数
* Redirecting packets to a more appropriate router on the local link for the destination address or pointing out that a destination is actually on the local link even if it is not obvious from the IP address (where a link supports multiple subnets). The Redirect message is specified in [RFC2461].
* 宛先アドレスのローカルリンクのより適切なルーターにパケットをリダイレクトするか、IPアドレス（リンクが複数のサブネットをサポートする場合）から明らかでない場合でも、宛先が実際にローカルリンクにあることを指摘します。リダイレクトメッセージは[RFC2461]で指定されています。
* Supporting renumbering of networks by allowing the prefixes advertised by routers to be altered. Uses NS, NA, RS and RA together with the Router Renumbering message specified in [RFC2894].
* ルーターによって宣伝されているプレフィックスを変更することにより、ネットワークの変更をサポートします。[RFC2894]で指定されたルーターの名前変更メッセージとともに、NS、NA、RS、RAを使用します。
Mobile IPv6 Support
モバイルIPv6サポート
* Providing support for some aspects of Mobile IPv6 especially dealing with the IPv6 Mobile Home Agent functionality provided in routers and needed to support a Mobile node homed on the link. The Home Agent Address Discovery Request and Reply and the Mobile Prefix Solicitation and Advertisement messages are specified in [RFC3775].
* モバイルIPv6のいくつかの側面のサポートを提供することは、特にルーターで提供され、リンクにあるモバイルノードをサポートする必要があるIPv6モバイルホームエージェント機能を扱っています。ホームエージェントは、発見のリクエストと返信に対処し、モバイルプレフィックスの勧誘と広告メッセージは[RFC3775]で指定されています。
Experimental Extensions
実験的拡張機能
* An experimental extension to ICMPv6 specifies the ICMP Node Information Query and Response messages that can be used to retrieve some basic information about nodes [RFC4620].
* ICMPV6の実験的拡張機能は、ノードに関する基本情報を取得するために使用できるICMPノード情報クエリと応答メッセージを指定します[RFC4620]。
* The SEAmless IP MOBility (SEAMOBY) working group specified a pair of experimental protocols that use an ICMPv6 message specified in [RFC4065] to help in locating an access router and moving the attachment point of a mobile node from one access router to another.
* シームレスなIPモビリティ（Seamoby）ワーキンググループは、[RFC4065]で指定されたICMPV6メッセージを使用して、アクセスルーターを見つけてモバイルノードのアタッチメントポイントをあるアクセスルーターから別のアクセスのポイントを移動するのに役立つ実験プロトコルのペアを指定しました。
Many of these messages should only be used in a link-local context rather than end-to-end, and filters need to be concerned with the type of addresses in ICMPv6 packets as well as the specific source and destination addresses.
これらのメッセージの多くは、エンドツーエンドではなくリンクローカルコンテキストでのみ使用する必要があり、フィルターは、ICMPv6パケットのアドレスのタイプと特定のソースおよび宛先アドレスに関係する必要があります。
Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be treated as an auxiliary function with packets that can be dropped in most cases without damaging the functionality of the network. This means that firewall filters for ICMPv6 have to be more carefully configured than was the case for ICMP, where typically a small set of blanket rules could be applied.
対応するIPv4プロトコル、ICMP、ICMPV6と比較して、ネットワークの機能を損傷することなく、ほとんどの場合にドロップできるパケットを使用して補助関数として扱うことはできません。つまり、ICMPV6のファイアウォールフィルターは、通常、ブランケットルールの小さなセットを適用できるICMPの場合よりも慎重に構成する必要があります。
ICMPv6 messages contain an eight-bit Type field interpreted as an integer between 0 and 255. Messages with Type values less than or equal to 127 are Error messages. The remainder are Informational messages. In general terms, Error messages with well-known (standardized) Type values would normally be expected to be allowed to be sent to or pass through firewalls, and may be essential to the establishment and maintenance of communications (see Section 2.4) whereas Informational messages will generally be the subject of policy rules, and those passing through end site firewalls can, in many but by no means all cases, be dropped without damaging IPv6 communications.
ICMPV6メッセージには、0〜255の間の整数として解釈される8ビットタイプフィールドが含まれています。127以下のタイプ値を持つメッセージはエラーメッセージです。残りは情報メッセージです。一般的に、よく知られている（標準化された）タイプの値を持つエラーメッセージは通常、ファイアウォールに送信または通過することが許可されることが期待され、通信の確立とメンテナンスに不可欠である可能性があります（セクション2.4を参照）、情報メッセージは一般に、ポリシールールの対象となり、エンドサイトのファイアウォールを通過する人は、多くの場合、すべての場合、IPv6通信を損傷することなくドロップすることはできません。
ICMPv6 messages are sent using various kinds of source and destination address types and scopes. The source address is usually a unicast address, but during address autoconfiguration message exchanges, the unspecified address (::) is also used as a source address [RFC2462].
ICMPV6メッセージは、さまざまな種類のソースおよび宛先アドレスの種類とスコープを使用して送信されます。ソースアドレスは通常、ユニキャストアドレスですが、アドレスの自動構成メッセージ交換中、不特定のアドレス（：:)もソースアドレス[RFC2462]として使用されます。
Multicast Listener Discovery (MLD) Report and Done messages are sent with a link-local address as the IPv6 source address, if a valid address is available on the interface. If a valid link-local address is not available (e.g., one has not been configured), the message is sent with the unspecified address (::) as the IPv6 source address. Subsequently, the node will generate new MLD Report messages with proper link-local source address once it has been configured [RFC3590].
マルチキャストリスナーディスカバリー（MLD）レポートと完了したメッセージは、インターフェイスで有効なアドレスが利用可能である場合、IPv6ソースアドレスとしてリンクローカルアドレスで送信されます。有効なLink-Localアドレスが使用できない場合（たとえば、構成されていません）、メッセージはIPv6ソースアドレスとして不特定のアドレス（：:)を使用して送信されます。その後、ノードは、構成された[RFC3590]を構成すると、適切なリンクローカルソースアドレスを使用して新しいMLDレポートメッセージを生成します。
The destination address can be either a well-known multicast address, a generated multicast address such as the solicited-node multicast address, an anycast address, or a unicast address. While many ICMPv6 messages use multicast addresses most of the time, some also use unicast addresses. For instance, the Router Advertisement messages are sent to the all-nodes multicast address when unsolicited, but can also be sent to a unicast address in response to a specific Router Solicitation, although this is rarely seen in current implementations.
宛先アドレスは、よく知られているマルチキャストアドレス、勧誘されたノードマルチキャストアドレス、Anycastアドレス、ユニキャストアドレスなどの生成されたマルチキャストアドレスのいずれかです。多くのICMPV6メッセージはほとんどの場合マルチキャストアドレスを使用していますが、一部はユニキャストアドレスも使用しています。たとえば、ルーターの広告メッセージは、未承諾の場合、All Nodesマルチキャストアドレスに送信されますが、特定のルーターの勧誘に応じてユニキャストアドレスに送信することもできますが、現在の実装ではめったに見られません。
ICMPv6 messages can be classified according to whether they are meant for end-to-end communications or local communications within a link. There are also messages that we can classify as 'any-to-end', which can be sent from any point within a path back to the source; typically, these are used to announce an error in processing the original packet. For instance, the address resolution messages are solely for local communications [RFC2461], whereas the Destination Unreachable messages are any-to-end in nature. Generally, end-to-end and any-to-end messages might be expected to pass through firewalls depending on policies but local communications must not.
ICMPV6メッセージは、リンク内のエンドツーエンド通信またはローカル通信を対象としているかどうかに応じて分類できます。また、「任意のエンド」として分類できるメッセージもあります。これは、ソースに戻るパス内の任意のポイントから送信できます。通常、これらは元のパケットの処理際のエラーを発表するために使用されます。たとえば、アドレス解像度メッセージはローカルコミュニケーション[RFC2461]専用ですが、宛先のないメッセージは本質的には無効です。一般に、エンドツーエンドのメッセージと任意のメッセージは、ポリシーに応じてファイアウォールを通過することが期待される場合がありますが、地域の通信はそうではありません。
Local communications will use link-local addresses in many cases but may also use global unicast addresses when configuring global addresses, for example. Also, some ICMPv6 messages used in local communications may contravene the usual rules requiring compatible scopes for source and destination addresses.
地域の通信は、多くの場合、Link-Localアドレスを使用しますが、たとえばグローバルアドレスを構成するときにグローバルユニキャストアドレスを使用する場合があります。また、ローカル通信で使用される一部のICMPV6メッセージは、ソースアドレスと宛先アドレスに互換性のあるスコープを必要とする通常のルールに違反する場合があります。
Many ICMPv6 messages have a role in establishing or maintaining communications to and from the firewall and such messages have to be accepted by firewalls for local delivery. Generally, a firewall will also be acting as a router so that all the messages that might be used in configuring a router interface need to be accepted and generated. These messages should not transit through a firewall that is also acting as a router as they are normally intended for use within a link.
多くのICMPV6メッセージは、ファイアウォールとの間で通信を確立または維持する役割を担っており、そのようなメッセージは、ローカル配信のためにファイアウォールで受け入れなければなりません。一般に、ファイアウォールはルーターとして機能するため、ルーターインターフェイスの構成に使用される可能性のあるすべてのメッセージを受け入れて生成する必要があります。これらのメッセージは、通常、リンク内で使用することを目的としているため、ルーターとしても機能するファイアウォールを通過するべきではありません。
On the other hand, most ICMPv6 error messages traveling end-to-end or any-to-end are essential to the establishment and maintenance of communications. These messages must be passed through firewalls and might also be sent to and from firewalls to assist with establishment and maintenance of communications. For example, the Packet Too Big error message is needed to determine the MTU along a path both when a communication session is established initially and later if the path is rerouted during the session.
一方、ほとんどのICMPV6エラーメッセージは、エンドツーエンドまたはアブエンドツーエンドを移動しており、通信の確立とメンテナンスに不可欠です。これらのメッセージはファイアウォールを通過する必要があり、コミュニケーションの確立と維持を支援するために、ファイアウォールとの間でも送信される場合があります。たとえば、パケットが最初に確立されたときとセッション中にパスが再ルーティングされた場合に通信セッションが確立されたときのパスに沿ってMTUを決定するには、パケットが大きすぎるエラーメッセージが必要です。
The remaining ICMPv6 messages that are not associated with communication establishment or maintenance will normally be legitimately attempting to pass through a firewall from inside to out or vice versa, but in most cases decisions as to whether or not to allow them to pass can be made on the basis of local policy without interfering with IPv6 communications.
コミュニケーションの確立やメンテナンスに関連付けられていない残りのICMPV6メッセージは、通常、内部から外出、またはその逆にファイアウォールを通過しようとすることを合法的に試みますが、ほとんどの場合、それらを渡すことを許可するかどうかについての決定は、IPv6通信を妨害することなく、ローカルポリシーの基礎。
The filtering rules for the various message roles will generally be different.
さまざまなメッセージの役割のフィルタリングルールは一般に異なります。
This memo recommends filtering configurations for firewalls designed to minimize the security vulnerabilities that can arise in using the many different sub-protocols of ICMPv6 in support of IPv6 communication.
このメモでは、IPv6通信をサポートするためにICMPv6のさまざまなサブプロトコルを使用する際に発生する可能性のあるセキュリティの脆弱性を最小限に抑えるために設計されたファイアウォールの構成のフィルタリングを推奨しています。
A major concern is that it is generally not possible to use IPsec or other means to authenticate the sender and validate the contents of many ICMPv6 messages. To a large extent, this is because a site can legitimately expect to receive certain error and other messages from almost any location in the wider Internet, and these messages may occur as a result of the first message sent to a destination. Establishing security associations with all possible sources of ICMPv6 messages is therefore impossible.
主な懸念は、一般に、送信者を認証し、多くのICMPV6メッセージの内容を検証するためにIPSECまたはその他の手段を使用することはできないことです。これは、サイトが特定のエラーや他のメッセージをより広いインターネット内のほぼすべての場所から受け取ることを合法的に期待できるため、これらのメッセージが最初のメッセージが宛先に送信された結果として発生する可能性があるためです。したがって、ICMPV6メッセージのすべての可能なソースとセキュリティ関連を確立することは不可能です。
The inability to establish security associations to protect some messages that are needed to establish and maintain communications means that alternative means have to be used to reduce the vulnerability of sites to ICMPv6-based attacks. The most common way of doing this is to establish strict filtering policies in site firewalls to limit the unauthenticated ICMPv6 messages that can pass between the site and the wider Internet. This makes control of ICMPv6 filtering a delicate balance between protecting the site by dropping some of the ICMPv6 traffic passing through the firewall and allowing enough of the traffic through to make sure that efficient communication can be established.
通信を確立および維持するために必要ないくつかのメッセージを保護するためにセキュリティ協会を確立できないことは、ICMPV6ベースの攻撃に対するサイトの脆弱性を減らすために代替手段を使用する必要があることを意味します。これを行う最も一般的な方法は、サイトファイアウォールで厳格なフィルタリングポリシーを確立して、サイトとより広いインターネット間を通過できる認可されていないICMPV6メッセージを制限することです。これにより、ICMPV6の制御により、ファイアウォールを通過するICMPv6トラフィックの一部をドロップし、効率的な通信を確立できるように十分なトラフィックを通過することにより、サイトを保護することとの微妙なバランスが整理されます。
SEND [RFC3971] has been specified as a means to improve the security of local ICMPv6 communications. SEND sidesteps security association bootstrapping problems that would result if IPsec was used. SEND affects only link-local messages and does not limit the filtering that firewalls can apply, and its role in security is therefore not discussed further in this document.
[RFC3971]は、ローカルICMPV6通信のセキュリティを改善する手段として指定されています。IPSecが使用された場合に生じるSidesteps Security Association Bootstrappingの問題を送信します。送信はリンク局所メッセージのみに影響を与え、ファイアウォールが適用できるフィルタリングを制限しないため、セキュリティにおけるその役割はこのドキュメントではこれ以上議論されていません。
Firewalls will normally be used to monitor ICMPv6 to control the following security concerns:
通常、ファイアウォールはICMPV6を監視するために使用され、次のセキュリティの懸念を制御します。
ICMPv6 can be used to cause a denial of service (DoS) in a number of ways, including simply sending excessive numbers of ICMPv6 packets to destinations in the site and sending error messages that disrupt established communications by causing sessions to be dropped. Also, if spurious communication establishment or maintenance messages can be infiltrated onto a link, it might be possible to invalidate legitimate addresses or disable interfaces.
ICMPV6は、サイト内の宛先に過剰な数のICMPV6パケットを送信したり、セッションをドロップしたりして確立された通信を破壊するエラーメッセージを送信するなど、さまざまな方法でサービス拒否（DOS）を引き起こすために使用できます。また、偽のコミュニケーションの確立またはメンテナンスメッセージをリンクに浸透させることができる場合、正当なアドレスを無効にしたり、インターフェイスを無効にしたりすることが可能かもしれません。
A major security consideration is preventing attackers from probing the site to determine the topology and identify hosts that might be vulnerable to attack. Carefully crafted but, often, malformed messages can be used to provoke ICMPv6 responses from hosts thereby informing attackers of potential targets for future attacks. However, the very large address space of IPv6 makes probing a less effective weapon as compared with IPv4 provided that addresses are not allocated in an easily guessable fashion. This subject is explored in more depth in [SCAN-IMP].
主要なセキュリティの考慮事項は、攻撃者がサイトを調査してトポロジを決定し、攻撃に対して脆弱なホストを特定することを防ぐことです。慎重に作成されたが、多くの場合、不正なメッセージを使用して、ホストからICMPV6応答を引き起こすことができ、将来の攻撃の潜在的なターゲットを攻撃者に通知することができます。ただし、IPv6の非常に大きなアドレススペースにより、アドレスが簡単に推測可能な方法で割り当てられていない場合、IPv4と比較して、より効果的な武器を調査することができます。この主題は、[スキャンインピック]でより深く調査されています。
A redirection attack could be used by a malicious sender to perform man-in-the-middle attacks or divert packets either to a malicious monitor or to cause DoS by blackholing the packets. These attacks would normally have to be carried out locally on a link using the Redirect message. Administrators need to decide if the improvement in efficiency from using Redirect messages is worth the risk of malicious use. Factors to consider include the physical security of the link and the complexity of addressing on the link. For example, on an open wireless link, redirection would be a serious hazard due to the lack of physical security. On the other hand, with a wired link in a secure building with complex addressing and redundant routers, the efficiency gains might well outweigh the small risk of a rogue node being connected.
悪意のある送信者がリダイレクト攻撃を使用して、中間の攻撃を実行したり、パケットを悪意のあるモニターに迂回させるか、パケットをブラックホールすることでDOSを引き起こすことができます。これらの攻撃は通常、リダイレクトメッセージを使用してリンクでローカルに実行する必要があります。管理者は、リダイレクトメッセージの使用による効率の改善が悪意のある使用のリスクに見合うかどうかを判断する必要があります。考慮すべき要因には、リンクの物理的なセキュリティとリンク上のアドレス指定の複雑さが含まれます。たとえば、オープンワイヤレスリンクでは、物理的なセキュリティがないため、リダイレクトは深刻な危険になります。一方、複雑なアドレス指定と冗長なルーターを備えた安全な建物に有線リンクがあるため、効率の向上は、不正なノードが接続されるという小さなリスクを大きく上回る可能性があります。
Spurious Renumbering messages can lead to the disruption of a site. Although Renumbering messages are required to be authenticated with IPsec, so that it is difficult to carry out such attacks in practice, they should not be allowed through a site boundary firewall. On the other hand, a site may employ multiple "layers" of firewalls. In this case, Renumbering messages might be expected to be allowed to transit interior firewalls but not pass across the outer boundary.
偽の名前を変更するメッセージは、サイトの混乱につながる可能性があります。IPSECで認証される必要があるため、メッセージを変更する必要がありますが、実際にそのような攻撃を実行することは困難ですが、サイトの境界ファイアウォールを通じて許可されるべきではありません。一方、サイトは、ファイアウォールの複数の「レイヤー」を採用する場合があります。この場合、メッセージを変更すると、内部のファイアウォールを通過することが許可されますが、外側の境界を通過しないことが期待される場合があります。
Because some ICMPv6 error packets need to be passed through a firewall in both directions, malicious users can potentially use these messages to communicate between inside and outside, bypassing administrative inspection. For example, it might be possible to carry out a covert conversation through the payload of ICMPv6 error messages or tunnel inappropriate encapsulated IP packets in ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6 errors using a deep packet inspection mechanism to ensure that the packet carried as a payload is associated with legitimate traffic to or from the protected network.
一部のICMPV6エラーパケットを両方向のファイアウォールに渡す必要があるため、悪意のあるユーザーは、これらのメッセージを使用して内側と外側の間で通信して、管理検査をバイパスできます。たとえば、ICMPV6エラーメッセージまたはICMPV6エラーメッセージのトンネル不適切なカプセル化されたIPパケットのペイロードを介して、秘密の会話を実行することが可能かもしれません。この問題は、深いパケット検査メカニズムを使用してICMPV6エラーをフィルタリングして、ペイロードとして運ばれたパケットが保護されたネットワークとの間の正当なトラフィックに関連付けられていることを確認することで軽減できます。
When designing firewall filtering rules for ICMPv6, the rules can be divided into two classes:
ICMPV6のファイアウォールフィルタリングルールを設計する場合、ルールは2つのクラスに分けることができます。
o Rules for ICMPv6 traffic transiting the firewall, with some minor variations for
o ICMPV6トラフィックのルールファイアウォールを通過するもの、
* firewalls protecting end sites or individual hosts, and
* エンドサイトまたは個々のホストを保護するファイアウォール、および
* firewalls protecting transit sites
* トランジットサイトを保護するファイアウォール
o Rules for ICMPv6 directed to interfaces on the firewall
o ファイアウォールのインターフェイスに向けられたICMPv6のルール
Firewalls integrated with an individual host ("end host firewalls") can be treated as end site firewalls, but the special considerations discussed in Section 4.2 may be relevant because the firewall is not a router.
個々のホスト（「エンドホストファイアウォール」）と統合されたファイアウォールは、エンドサイトファイアウォールとして扱うことができますが、セクション4.2で説明する特別な考慮事項は、ファイアウォールがルーターではないため、関連する場合があります。
This section suggests some common considerations that should be borne in mind when designing filtering rules and then categorizes the rules for each class. The categories are:
このセクションでは、フィルタリングルールを設計する際に留意する必要があるいくつかの一般的な考慮事項を提案し、各クラスのルールを分類します。カテゴリは次のとおりです。
o Messages that must not be dropped: usually because establishment or maintenance of communications will be prevented or severely impacted.
o ドロップしてはならないメッセージ：通常、通信の確立またはメンテナンスが防止されるか、深刻な影響を受けるためです。
o Messages that should not be dropped: administrators need to have a very good reason for dropping this category.
o 削除すべきではないメッセージ：管理者は、このカテゴリを削除する非常に正当な理由が必要です。
o Messages that may be dropped in firewall/routers, but these messages may already be targeted to drop for other reasons (e.g., because they are using link-local addresses) or because the protocol specification would cause the messages to be rejected if they had passed through a router. Special considerations apply to transit traffic if the firewall is not a router as discussed in Section 4.2.
o ファイアウォール/ルーターでドロップされる可能性がありますが、これらのメッセージは、他の理由（例えば、リンクローカルアドレスを使用しているため）またはプロトコル仕様が渡された場合にメッセージが拒否されるためにドロップすることを既にターゲットにしている可能性がありますルーターを介して。セクション4.2で説明したように、ファイアウォールがルーターでない場合、交通トラフィックに特別な考慮事項が適用されます。
o Messages that administrators may or may not want to drop depending on local policy.
o 管理者がローカルポリシーに応じて削除したくない場合と望まないメッセージ。
o Messages that administrators should consider dropping (e.g., ICMP node information name lookup queries).
o 管理者がドロップを検討する必要があるメッセージ（たとえば、ICMPノード情報名前のルックアップクエリ）。
More detailed analysis of each of the message types can be found in Appendix A.
各メッセージタイプのより詳細な分析は、付録Aにあります。
Depending on the classification of the message to be filtered (see Section 2), ICMPv6 messages should be filtered based on the ICMPv6 type of the message and the type (unicast, multicast, etc.) and scope (link-local, global unicast, etc.) of source and destination addresses. In some cases, it may be desirable to filter on the Code field of ICMPv6 error messages.
フィルタリングするメッセージの分類（セクション2を参照）に応じて、ICMPV6メッセージは、メッセージのICMP6タイプとタイプ（ユニキャスト、マルチキャストなど）とスコープ（リンクローカル、グローバルユニキャスト、など）ソースおよび宛先アドレスの。場合によっては、ICMPV6エラーメッセージのコードフィールドでフィルタリングすることが望ましい場合があります。
Messages that can be authenticated on delivery, probably because they contain an IPsec AH header or ESP header with authentication, may be subject to less strict policies than messages that cannot be authenticated. In the remainder of this section, we are generally considering what should be configured for unauthenticated messages. In many cases, it is not realistic to expect more than a tiny fraction of the messages to be authenticated.
おそらく、IPSEC AHヘッダーまたは認証を備えたESPヘッダーを含むため、配信時に認証できるメッセージは、認証できないメッセージよりも厳格なポリシーの対象となる可能性があります。このセクションの残りの部分では、一般に、認識されていないメッセージに対して何を構成すべきかを検討しています。多くの場合、メッセージのごく一部以上が認証されることを期待することは現実的ではありません。
Where messages are not essential to the establishment or maintenance of communications, local policy can be used to determine whether a message should be allowed or dropped.
通信の確立やメンテナンスにメッセージが不可欠ではない場合、ローカルポリシーを使用して、メッセージを許可するか削除するかを判断できます。
Depending on the capabilities of the firewall being configured, it may be possible for the firewall to maintain state about packets that may result in error messages being returned or about ICMPv6 packets (e.g., Echo Requests) that are expected to receive a specific response. This state may allow the firewall to perform more precise checks based on this state, and to apply limits on the number of ICMPv6 packets accepted incoming or outgoing as a result of a packet traveling in the opposite direction. The capabilities of firewalls to perform such stateful packet inspection vary from model to model, and it is not assumed that firewalls are uniformly capable in this respect.
構成されているファイアウォールの機能に応じて、ファイアウォールが、エラーメッセージが返される可能性のあるパケットまたはICMPV6パケット（例：エコーリクエスト）について特定の応答を受信すると予想される状態を維持することが可能です。この状態により、ファイアウォールはこの状態に基づいてより正確なチェックを実行し、パケットが反対方向に移動した結果、受信または発信を受け入れたICMPv6パケットの数に制限を適用することができます。このようなステートフルなパケット検査を実行するファイアウォールの機能は、モデルごとに異なり、この点でファイアウォールが均一に能力があるとは想定されていません。
Firewalls that are able to perform deep packet inspection may be able to check the header fields in the start of the errored packet that is carried by ICMPv6 error messages. If the embedded packet has a source address that does not match the destination of the error message, the packet can be dropped. This provides a partial defense against some possible attacks on TCP that use spoofed ICMPv6 error messages, but the checks can also be carried out at the destination. For further information on these attacks see [ICMP-ATTACKS].
深いパケット検査を実行できるファイアウォールは、ICMPv6エラーメッセージによって運ばれるエラーパケットの開始時にヘッダーフィールドを確認できる場合があります。埋め込まれたパケットにエラーメッセージの宛先と一致しないソースアドレスがある場合、パケットをドロップできます。これにより、スプーフィングされたICMPV6エラーメッセージを使用するTCPに対するいくつかの可能な攻撃に対する部分的な防御が提供されますが、チェックは目的地でも実行できます。これらの攻撃の詳細については、[ICMP攻撃]を参照してください。
In general, the scopes of source and destination addresses of ICMPv6 messages should be matched, and packets with mismatched addresses should be dropped if they attempt to transit a router. However, some of the address configuration messages carried locally on a link may legitimately have mismatched addresses. Node implementations must accept these messages delivered locally on a link, and administrators should be aware that they can exist.
一般に、ICMPV6メッセージのソースアドレスと宛先アドレスのスコープを一致させる必要があり、ルーターがルーターを通過しようとする場合は、不一致のアドレスを備えたパケットをドロップする必要があります。ただし、リンクでローカルに携帯されるアドレス構成メッセージの一部には、正当にアドレスが不一致になる場合があります。ノードの実装は、リンクでローカルに配信されるこれらのメッセージを受け入れる必要があり、管理者は存在できることを認識する必要があります。
ICMPv6 messages transiting firewalls inbound to a site may be treated differently depending on whether they are addressed to a node on the site or to some other node. For end sites, packets addressed to nodes not on the site should be dropped, but would generally be forwarded by firewalls on transit sites.
ICMPV6メッセージファイアウォールをサイトにインバウンドするファイアウォールを通過すると、サイト上のノードまたは他のノードにアドレス指定されているかどうかによって、異なる扱いがあります。エンドサイトの場合、サイト上にないノードにアドレス指定されたパケットはドロップする必要がありますが、通常、トランジットサイトのファイアウォールによって転送されます。
Firewalls can be implemented both as IP routers (firewall/routers) and as link layer bridges (e.g., Ethernet bridges) that are transparent to the IP layer although they will actually be inspecting the IP packets as they pass through (firewall/bridges).
ファイアウォールは、IPルーター（ファイアウォール/ルーター）と、IPレイヤーに透明なリンクレイヤーブリッジ（例えば、イーサネットブリッジ）として実装できますが、実際にはIPパケットを通過するときにIPパケットを検査します（ファイアウォール/ブリッジ）。
Many of the messages used for establishment and maintenance of communications on the local link will be sent with link-local addresses for at least one of their source and destination. Routers conforming to the IPv6 standards will not forward these packets; there is no need to configure additional rules to prevent these packets traversing a firewall/router, although administrators may wish to configure rules that would drop these packets for insurance and as a means of monitoring for attacks. Also, the specifications of ICMPv6 messages intended for use only on the local link specify various measures that would allow receivers to detect if the message had passed through a router, including:
ローカルリンクでの通信の確立とメンテナンスに使用されるメッセージの多くは、少なくとも1つのソースと宛先のリンクローカルアドレスで送信されます。IPv6標準に準拠しているルーターは、これらのパケットを転送しません。これらのパケットがファイアウォール/ルーターを通過するのを防ぐために追加のルールを構成する必要はありませんが、管理者は、保険のためにこれらのパケットをドロップし、攻撃の監視手段としてドロップするルールを構成することを希望する場合があります。また、ローカルリンクでのみ使用することを目的としたICMPV6メッセージの仕様は、メッセージがルーターを通過したかどうかを受信者が検出できるようにするさまざまな測定値を指定します。
o Requiring that the hop limit in the IPv6 header is set to 255 on transmission. Receivers verify that the hop limit is still 255, to ensure that the packet has not passed through a router.
o IPv6ヘッダーのホップ制限が送信時に255に設定されることを要求します。受信者は、ホップ制限がまだ255であることを確認して、パケットがルーターを通過していないことを確認します。
o Checking that the source address is a link-local unicast address.
o ソースアドレスがリンクローカルユニキャストアドレスであることを確認します。
Accordingly, it is not essential to configure firewall/router rules to drop out-of-specification packets of these types. If they have non-link-local source and destination addresses, allowing them to traverse the firewall/router, they would be rejected because of the checks performed at the destination. Again, firewall administrators may still wish to configure rules to log or drop such out-of-specification packets.
したがって、これらのタイプの仕様不足パケットをドロップするようにファイアウォール/ルータールールを構成することは不可欠ではありません。リンクローカルのソースと宛先アドレスがある場合、ファイアウォール/ルーターを通過できる場合、目的地で実行されるチェックのために拒否されます。繰り返しますが、ファイアウォール管理者は、そのような仕様不足パケットをログまたはドロップするようにルールを構成することを希望する場合があります。
For firewall/bridges, slightly different considerations apply. The physical links on either side of the firewall/bridge are treated as a single logical link for the purposes of IP. Hence, the link local messages used for discovery functions on the link must be allowed to transit the transparent bridge. Administrators should ensures that routers and hosts attached to the link containing the firewall/bridge are built to the correct specifications so that out-of-specification packets are actually dropped as described in the earlier part of this section.
ファイアウォール/ブリッジには、わずかに異なる考慮事項が適用されます。ファイアウォール/ブリッジの両側にある物理的なリンクは、IPの目的のために単一の論理リンクとして扱われます。したがって、リンク上のディスカバリー関数に使用されるリンクローカルメッセージは、透明ブリッジを通過するために許可する必要があります。管理者は、ファイアウォール/ブリッジを含むリンクに接続されたルーターとホストが正しい仕様に合わせて構築されていることを確認する必要があります。これにより、このセクションの前の部分で説明されているように、明確なパケットが実際に削除されます。
An end host firewall can generally be thought of as a special case of a firewall/bridge, but the only link-local messages that need to be allowed through are those directed to the host's interface.
エンドホストファイアウォールは一般に、ファイアウォール/ブリッジの特別なケースと考えることができますが、許可する必要がある唯一のリンクローカルメッセージは、ホストのインターフェイスに向けられたものです。
This section recommends rules that should be applied to ICMPv6 traffic attempting to transit a firewall.
このセクションでは、ファイアウォールを通過しようとするICMPV6トラフィックに適用すべきルールを推奨します。
Error messages that are essential to the establishment and maintenance of communications:
コミュニケーションの確立とメンテナンスに不可欠なエラーメッセージ：
o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only
o 宛先の到達不能（タイプ1） - すべてのコードoパケットが大きすぎる（タイプ2）o時間を超えた（タイプ3） - コード0パラメーター問題（タイプ4） - コード1および2のみ
Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the necessary packet inspection capabilities.
付録A.4は、ファイアウォールに必要なパケット検査機能がある場合、パラメーター問題メッセージで実行できるいくつかの具体的なチェックを提案しています。
Connectivity checking messages:
接続チェックメッセージ：
o Echo Request (Type 128) o Echo Response (Type 129)
o エコーリクエスト（タイプ128）oエコー応答（タイプ129）
For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are allowed through the firewall. It has been common practice in IPv4 networks to drop Echo Request messages in firewalls to minimize the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe, and it is not necessary to filter IPv6 Echo Request messages.
可能な限り、サイト上のIPv6ノードにteredoトンネル[RFC4380]の場合、ファイアウォールを通じて接続チェックメッセージを許可することが不可欠です。IPv4ネットワークでは、保護されたネットワークでの攻撃をスキャンするリスクを最小限に抑えるために、ファイアウォールでエコーリクエストメッセージをドロップすることが一般的な慣行でした。セクション3.2で説明したように、IPv6ネットワークでのポートスキャンによるリスクはそれほど深刻ではなく、IPv6エコーリクエストメッセージをフィルタリングする必要はありません。
Error messages other than those listed in Section 4.3.1:
セクション4.3.1にリストされているもの以外のエラーメッセージ：
o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0
o 時間を超えた（タイプ3） - コード1 oパラメーター問題（タイプ4） - コード0
Mobile IPv6 messages that are needed to assist mobility:
モビリティを支援するために必要なモバイルIPv6メッセージ：
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement (Type 147)
o ホームエージェントアドレスディスカバリーリクエスト（タイプ144）oホームエージェントアドレスディスカバリー返信（タイプ145）oモバイルプレフィックス勧誘（タイプ146）oモバイルプレフィックス広告（タイプ147）
Administrators may wish to apply more selective rules as described in Appendix A.14 depending on whether the site is catering for mobile nodes that would normally be at home on the site and/or foreign mobile nodes roaming onto the site.
管理者は、サイトがサイトで通常自宅にあるモバイルノードや外国のモバイルノードがサイトに移動するかどうかに応じて、付録A.14で説明されているように、より選択的なルールを適用したい場合があります。
The messages listed in this section are all involved with local management of nodes connected to the logical link on which they were initially transmitted. All these messages should never be propagated beyond the link on which they were initially transmitted. If the firewall is a firewall/bridge rather than a firewall/router, these messages should be allowed to transit the firewall as they would be intended for establishing communications between the two physical parts of the link that are bridged into a single logical link.
このセクションにリストされているメッセージはすべて、最初に送信された論理リンクに接続されたノードのローカル管理に関係しています。これらすべてのメッセージは、最初に送信されたリンクを超えて伝播することはありません。ファイアウォールがファイアウォール/ルーターではなくファイアウォール/ブリッジである場合、これらのメッセージは、単一の論理リンクにブリッジされたリンクの2つの物理部分間の通信を確立するためのファイアウォールを通過することを許可する必要があります。
During normal operations, these messages will have destination addresses, mostly link local but in some cases global unicast addresses, of interfaces on the local link. No special action is needed to filter messages with link-local addresses in a firewall/ router. As discussed in Section 4.1, these messages are specified so that either the receiver is able to check that the message has not passed through a router or it will be dropped at the first router it encounters.
通常の操作中に、これらのメッセージには、主にローカルをリンクしますが、場合によってはローカルリンク上のインターフェイスのグローバルユニキャストアドレスをリンクする宛先アドレスがあります。ファイアウォール/ルーターのリンクローカルアドレスを含むメッセージをフィルタリングするための特別なアクションは必要ありません。セクション4.1で説明したように、これらのメッセージは指定されているため、受信機がメッセージがルーターを通過していないことを確認できるか、遭遇する最初のルーターで削除されます。
Administrators may also wish to consider providing rules in firewall/ routers to catch illegal packets sent with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being generated for these packets.
また、管理者は、これらのパケットのために生成されるメッセージを超えるICMPv6時間を超えるホップ制限= 1で送信された違法なパケットをキャッチするためのファイアウォール/ルーターでルールを提供することを検討することもできます。
Address Configuration and Router Selection messages (must be received with hop limit = 255):
アドレス構成とルーターの選択メッセージ（ホップ制限= 255で受信する必要があります）：
o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Redirect (Type 137) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142)
o ルーターの勧誘（タイプ133）oルーター広告（タイプ134）o近隣勧誘（タイプ135）o近隣広告（タイプ136）oリダイレクト（タイプ137）o逆近隣発見勧誘（タイプ141）o逆近隣発見広告（タイプ1422222））
Link-local multicast receiver notification messages (must have link-local source address):
Link-Local Multicast Receiver通知メッセージ（Link-Local Sourceアドレスが必要です）：
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143) SEND Certificate Path notification messages (must be received with hop limit = 255):
o リスナークエリ（タイプ130）oリスナーレポート（タイプ131）oリスナーDONE（タイプ132）oリスナーレポートV2（タイプ143）
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
o 証明書パス勧誘（タイプ148）o証明書パス広告（タイプ149）
Multicast Router Discovery messages (must have link-local source address and hop limit = 1):
マルチキャストルーター発見メッセージ（リンクローカルソースアドレスとホップ制限= 1が必要です）：
o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153)
o マルチキャストルーター広告（タイプ151）oマルチキャストルーターの勧誘（タイプ152）oマルチキャストルーター終了（タイプ153）
The message type that the experimental Seamoby protocols are using will be expected to have to cross site boundaries in normal operation. Transit sites must allow these messages to transit the site. End site administrators should determine if they need to support these experiments and otherwise messages of this type should be dropped:
実験的なSeamobyプロトコルが使用しているメッセージタイプは、通常の動作でサイトの境界を越える必要があると予想されます。トランジットサイトでは、これらのメッセージがサイトを通過できるようにする必要があります。エンドサイト管理者は、これらの実験をサポートする必要があるかどうかを判断する必要があります。このタイプのメッセージは削除する必要があります。
o Seamoby Experimental (Type 150)
o Seamoby Experimental（タイプ150）
Error messages not currently defined by IANA: o Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
現在IANAによって定義されていないエラーメッセージ：o未割り当てのエラーメッセージ（タイプ5-99包括的および102-126包括的）
The base ICMPv6 specification suggests that error messages that are not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators of end sites should be aware of this and determine whether they wish to allow these messages through the firewall. Firewalls protecting transit sites must allow all types of error messages to transit the site but may adopt different policies for error messages addressed to nodes within the site.
ベースICMPV6仕様は、ノードに明示的に知られていないエラーメッセージを転送し、それらを解釈できる可能性のある高レベルのプロトコルに渡す必要があることを示唆しています。そのようなメッセージを使用して、秘密のチャネルを提供したり、DOS攻撃の一部を形成することができるという小さなリスクがあります。エンドサイトの管理者はこれを認識し、ファイアウォールを介してこれらのメッセージを許可するかどうかを判断する必要があります。トランジットサイトを保護するファイアウォールは、あらゆる種類のエラーメッセージがサイトを通過することを許可する必要がありますが、サイト内のノードにアドレス指定されたエラーメッセージの異なるポリシーを採用する場合があります。
All informational messages with types not explicitly assigned by IANA, currently:
IANAによって明示的に割り当てられていないタイプのすべての情報メッセージ、現在：
o Unallocated Informational messages (Types 154-199 inclusive and 202-254 inclusive).
o 未配分の情報メッセージ（タイプ154-199インクルーシブおよび202-254包括的）。
Note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded. Transit sites must allow these messages to transit the site. End site administrators can either adopt a policy of allowing all these messages through the firewall, relying on end hosts to drop unrecognized messages, or drop all such messages at the firewall. Different policies could be adopted for inbound and outbound messages.
ベースICMPV6仕様では、未知のタイプの情報メッセージを静かに破棄する必要があることに注意してください。トランジットサイトでは、これらのメッセージがサイトを通過できるようにする必要があります。エンドサイト管理者は、これらすべてのメッセージをファイアウォールを介して許可するポリシーを採用し、エンドホストに依存して認識されていないメッセージをドロップするか、ファイアウォールでそのようなすべてのメッセージをドロップすることができます。インバウンドメッセージとアウトバウンドメッセージには、さまざまなポリシーを採用できます。
If administrators choose to implement policies that drop currently unallocated error or informational messages, it is important to review the set of messages affected in case new message types are assigned by IANA.
管理者は、現在認定されていないエラーまたは情報メッセージをドロップするポリシーを実装することを選択した場合、IANAによって新しいメッセージタイプが割り当てられた場合に影響を受けるメッセージのセットを確認することが重要です。
Node Information enquiry messages should generally not be forwarded across site boundaries. Some of these messages will be using non-link-local unicast addresses so that they will not necessarily be dropped by address scope limiting rules:
ノード情報照会メッセージは、通常、サイトの境界を越えて転送されるべきではありません。これらのメッセージの一部は、非リンクローカルユニキャストアドレスを使用するため、アドレススコープ制限ルールによって必ずしも削除されるわけではありません。
o Node Information Query (Type 139) o Node Information Response (Type 140)
o ノード情報クエリ（タイプ139）oノード情報応答（タイプ140）
Router Renumbering messages should not be forwarded across site boundaries. As originally specified, these messages may use a site scope multicast address or a site local unicast address. They should be caught by standard rules that are intended to stop any packet with a multicast site scope or site local destination being forwarded across a site boundary provided these are correctly configured. Since site local addresses have now been deprecated, it seems likely that changes may be made to allow the use of unique local addresses or global unicast addresses. Should this happen, it will be essential to explicitly filter these messages at site boundaries. If a site has internal as well as boundary firewalls, individual policies should be established for the internal firewalls depending on whether or not the site wishes to use Router Renumbering:
ルーターの名前を変更すると、サイトの境界を越えて転送しないでください。当初指定されたように、これらのメッセージは、サイトスコープマルチキャストアドレスまたはサイトローカルユニキャストアドレスを使用する場合があります。これらは、マルチキャストサイトスコープまたはサイトの境界を越えて転送される任意のパケットを停止することを目的とした標準ルールに巻き込まれるべきです。サイトのローカルアドレスは現在廃止されているため、一意のローカルアドレスまたはグローバルユニキャストアドレスの使用を可能にするために変更が加えられる可能性が高いようです。これが起こった場合、これらのメッセージをサイトの境界で明示的にフィルタリングすることが不可欠です。サイトに内部および境界ファイアウォールがある場合、サイトがルーターの変更を希望するかどうかに応じて、内部ファイアウォールの個々のポリシーを確立する必要があります。
o Router Renumbering (Type 138)
o ルーターの変更（タイプ138）
Messages with types in the experimental allocations:
実験的割り当てにタイプがあるメッセージ：
o Types 100, 101, 200, and 201.
o タイプ100、101、200、および201。
Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions:
ICMPV6などの時間まで拡張タイプ番号を使用したメッセージは、次のような拡張機能を使用する必要があります。
o Types 127 and 255.
o タイプ127および255。
This section recommends filtering rules for ICMPv6 traffic addressed to an interface on a firewall. For a small number of messages, the desired behavior may differ between interfaces on the site or private side of the firewall and the those on the public Internet side of the firewall.
このセクションでは、ファイアウォール上のインターフェイスに宛てられたICMPV6トラフィックのフィルタリングルールを推奨します。少数のメッセージの場合、目的の動作は、ファイアウォールのサイトまたはプライベート側のインターフェイスとファイアウォールのパブリックインターネット側のインターフェイス間で異なる場合があります。
Error messages that are essential to the establishment and maintenance of communications:
コミュニケーションの確立とメンテナンスに不可欠なエラーメッセージ：
o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only
o 宛先の到達不能（タイプ1） - すべてのコードoパケットが大きすぎる（タイプ2）o時間を超えた（タイプ3） - コード0パラメーター問題（タイプ4） - コード1および2のみ
Connectivity checking messages:
接続チェックメッセージ：
o Echo Request (Type 128) o Echo Response (Type 129)
o エコーリクエスト（タイプ128）oエコー応答（タイプ129）
As discussed in Section 4.3.1, dropping connectivity checking messages will prevent the firewall being the destination of a Teredo tunnel and it is not considered necessary to disable connectivity checking in IPv6 networks because port scanning is less of a security risk.
セクション4.3.1で説明したように、接続のチェックメッセージをドロップすると、ファイアウォールがTeredoトンネルの宛先であることが妨げられ、ポートスキャンはセキュリティリスクが低いため、IPv6ネットワークの接続チェックを無効にする必要はありません。
There are a number of other sets of messages that play a role in configuring the node and maintaining unicast and multicast communications through the interfaces of a node. These messages must not be dropped if the node is to successfully participate in an IPv6 network. The exception to this is the Redirect message for which an explicit policy decision should be taken (see Section 4.4.4).
ノードの構成とノードのインターフェイスを介してユニキャストとマルチキャストの通信を維持する上で役割を果たすメッセージは他にもたくさんあります。ノードがIPv6ネットワークに正常に参加する場合、これらのメッセージをドロップしてはなりません。これの例外は、明示的な政策決定を下すべきリダイレクトメッセージです（セクション4.4.4を参照）。
Address Configuration and Router Selection messages:
アドレス構成とルーターの選択メッセージ：
o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142) Link-Local Multicast Receiver Notification messages:
o ルーターの勧誘（タイプ133）oルーター広告（タイプ134）o近隣勧誘（タイプ135）o近隣広告（タイプ136）o逆近隣発見勧誘（タイプ141）o逆近隣発見広告（タイプ142）リンク - ローカストレシーバー通知メッセージ：
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143)
o リスナークエリ（タイプ130）oリスナーレポート（タイプ131）oリスナーDONE（タイプ132）oリスナーレポートV2（タイプ143）
SEND Certificate Path Notification messages:
証明書パス通知メッセージを送信します。
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
o 証明書パス勧誘（タイプ148）o証明書パス広告（タイプ149）
Multicast Router Discovery messages:
マルチキャストルーターディスカバリーメッセージ：
o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153)
o マルチキャストルーター広告（タイプ151）oマルチキャストルーターの勧誘（タイプ152）oマルチキャストルーター終了（タイプ153）
Error messages other than those listed in Section 4.4.1:
セクション4.4.1にリストされているもの以外のエラーメッセージ：
o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0
o 時間を超えた（タイプ3） - コード1 oパラメーター問題（タイプ4） - コード0
Router Renumbering messages must be authenticated using IPsec, so it is not essential to filter these messages even if they are not allowed at the firewall/router:
ルーターの名前を変更するメッセージは、IPSECを使用して認証する必要があるため、ファイアウォール/ルーターで許可されていない場合でも、これらのメッセージをフィルタリングすることは不可欠ではありません。
o Router Renumbering (Type 138)
o ルーターの変更（タイプ138）
Mobile IPv6 messages that are needed to assist mobility:
モビリティを支援するために必要なモバイルIPv6メッセージ：
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement (Type 147)
o ホームエージェントアドレスディスカバリーリクエスト（タイプ144）oホームエージェントアドレスディスカバリー返信（タイプ145）oモバイルプレフィックス勧誘（タイプ146）oモバイルプレフィックス広告（タイプ147）
It may be desirable to drop these messages, especially on public interfaces, if the firewall is not also providing mobile home agent services, but they will be ignored otherwise.
ファイアウォールがモバイルホームエージェントサービスも提供していない場合、特に公共インターフェイスでこれらのメッセージをドロップすることが望ましい場合がありますが、それ以外の場合は無視されます。
The message used by the experimental Seamoby protocols may be dropped but will be ignored if the service is not implemented:
実験的なSeamobyプロトコルで使用されるメッセージは削除される場合がありますが、サービスが実装されていない場合は無視されます。
o Seamoby Experimental (Type 150)
o Seamoby Experimental（タイプ150）
Redirect messages provide a significant security risk, and administrators should take a case-by-case approach to whether firewalls, routers in general, and other nodes should accept these messages:
リダイレクトメッセージは重要なセキュリティリスクを提供し、管理者はファイアウォール、ルーター全般、および他のノードがこれらのメッセージを受け入れるかどうかについて、ケースバイケースのアプローチを取る必要があります。
o Redirect (Type 137)
o リダイレクト（タイプ137）
Conformant nodes must provide configuration controls that allow nodes to control their behavior with respect to Redirect messages so that it should only be necessary to install specific filtering rules under special circumstances, such as if Redirect messages are accepted on private interfaces but not public ones.
コンフォーマントノードは、ノードがメッセージをリダイレクトするために動作を制御できるようにする構成制御を提供する必要があります。そうすることで、リダイレクトメッセージがプライベートインターフェイスで受け入れられているが公開されていない場合など、特別な状況下で特定のフィルタリングルールをインストールする必要があります。
If a node implements the experimental Node Information service, the administrator needs to make an explicit decision as to whether the node should respond to or accept Node Information messages on each interface:
ノードが実験ノード情報サービスを実装する場合、管理者は、ノードが各インターフェイスのノード情報メッセージに応答するか、受け入れるかについて明示的な決定を下す必要があります。
o Node Information Query (Type 139) o Node Information Response (Type 140)
o ノード情報クエリ（タイプ139）oノード情報応答（タイプ140）
It may be possible to disable the service on the node if it is not wanted, in which case these messages will be ignored and no filtering is necessary.
必要でない場合は、ノード上のサービスを無効にすることができる場合があります。その場合、これらのメッセージは無視され、フィルタリングは必要ありません。
Error messages not currently defined by IANA:
現在IANAによって定義されていないエラーメッセージ：
o Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
o 未配分のエラーメッセージ（タイプ5-99包括的および102-126包括的）
The base ICMPv6 specification suggests that error messages that are not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators should be aware of this and determine whether they wish to allow these messages to be sent to the firewall.
ベースICMPV6仕様は、ノードに明示的に知られていないエラーメッセージを転送し、それらを解釈できる可能性のある高レベルのプロトコルに渡す必要があることを示唆しています。そのようなメッセージを使用して、秘密のチャネルを提供したり、DOS攻撃の一部を形成することができるという小さなリスクがあります。管理者はこれを認識し、これらのメッセージをファイアウォールに送信することを許可するかどうかを判断する必要があります。
Messages with types in the experimental allocations:
実験的割り当てにタイプがあるメッセージ：
o Types 100, 101, 200, and 201.
o タイプ100、101、200、および201。
Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions:
ICMPV6などの時間まで拡張タイプ番号を使用したメッセージは、次のような拡張機能を使用する必要があります。
o Types 127 and 255.
o タイプ127および255。
All informational messages with types not explicitly assigned by IANA, currently:
IANAによって明示的に割り当てられていないタイプのすべての情報メッセージ、現在：
o Types 154-199 inclusive and 202-254 inclusive.
o タイプ154-199インクルーシブおよび202-254インクルーシブ。
Note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded.
ベースICMPV6仕様では、未知のタイプの情報メッセージを静かに破棄する必要があることに注意してください。
Pekka Savola created the original IPv6 Security Overview document, which contained suggestions for ICMPv6 filter setups. This information has been incorporated into this document. He has also provided important comments. Some analysis of the classification of ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in a document relating to ICMPv6 and IKE.
Pekka Savolaは、ICMPV6フィルターセットアップの提案が含まれる元のIPv6セキュリティ概要ドキュメントを作成しました。この情報は、このドキュメントに組み込まれています。彼はまた、重要なコメントを提供しています。ICMPV6メッセージの分類と「任意のエンド」という用語の分析は、Jari ArkkoがICMPv6およびIKEに関連するドキュメントで使用しました。
The Netfilter configuration script in Appendix B was contributed by Suresh Krishnan.
付録BのNetFilter構成スクリプトは、Suresh Krishnanによって寄稿されました。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894] Crawford、M。、「IPv6の変更ルーター」、RFC 2894、2000年8月。
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3122] Conta、A。、「逆発見仕様のためのIPv6近隣発見への拡張」、RFC 3122、2001年6月。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590] Haberman、B。、「マルチキャストリスナーディスカバリー（MLD）プロトコルのソースアドレス選択」、RFC 3590、2003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4065] Kempf、J。、「Seamoby and Experimental Mobility Protocol Ianaの割り当ての指示」、RFC 4065、2005年7月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286] Haberman、B。およびJ. Martin、「マルチキャストルーターディスカバリー」、RFC 4286、2005年12月。
[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、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006.
[RFC4620] Crawford、M。およびB. Haberman、「IPv6ノード情報クエリ」、RFC 4620、2006年8月。
[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[ICMP-attacks] Gont、F。、「TCPに対するICMP攻撃」、2006年10月、進行中の作業。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する」、RFC 4380、2006年2月。
[SCAN-IMP] Chown, T., "IPv6 Implications for Network Scanning", Work in Progress, March 2007.
[Scan-Imp] Chown、T。、「ネットワークスキャンへのIPv6の影響」、2007年3月、進行中の作業。
[netfilter] netfilter.org, "The netfilter.org project", Firewalling, NAT and Packet Mangling for Linux , 2006, <http://www.netfilter.org/>.
[netfilter] netfilter.org、 "the netfilter.org project"、firewalling、nat and packet Mangling for Linux、<http://www.netfilter.org/>。
Destination Unreachable (Type 1) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses when the node is unable to forward the packet for any reason except congestion.
宛先到達不能（タイプ1）エラーメッセージ[RFC4443]は、ユニキャストアドレス間で任意のエンドに送られます。メッセージは、ノードが混雑以外の理由でパケットを転送できない場合にパケットが通過するノードから生成できます。
Destination Unreachable messages are useful for debugging, but are also important to speed up cycling through possible addresses, as they can avoid the need to wait through timeouts and hence can be part of the process of establishing or maintaining communications. It is a common practice in IPv4 to refrain from generating ICMP Destination Unreachable messages in an attempt to hide the networking topology and/or service structure. The same idea could be applied to IPv6, but this can slow down connection if a host has multiple addresses, some of which are deprecated, as they may be when using privacy addresses [RFC3041]. If policy allows the generation of ICMPv6 Destination Unreachable messages, it is important that nodes provide the correct reason code, one of: no route to destination, administratively prohibited, beyond scope of source address, address unreachable, port unreachable, source address failed ingress/egress policy, or reject route to destination.
宛先の届かないメッセージはデバッグに役立ちますが、タイムアウトを待つ必要性を回避できるため、可能なアドレスを介してサイクリングを加速するためにも重要です。IPv4では、ネットワークトポロジおよび/またはサービス構造を非表示にするために、ICMP宛先の到達不可能なメッセージの生成を控えることは一般的な慣行です。同じアイデアをIPv6に適用できますが、ホストに複数のアドレスがある場合、これは接続を遅くすることができます。プライバシーアドレスを使用する場合は、その一部は非推奨です[RFC3041]。ポリシーがICMPV6宛先の到達不可能なメッセージの生成を許可する場合、ノードが正しい理由コードを提供することが重要です。ポリシーを出力するか、宛先へのルートを拒否します。
Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses on the path when the node is unable to forward the packet because the packet is too large for the MTU of the next link. This message is vital to the correct functioning of Path MTU Discovery and hence is part of the establishment and maintenance of communications. Since routers are not allowed to fragment packets, informing sources of the need to fragment large packets is more important than for IPv4. If these messages are not generated when appropriate, hosts will continue to send packets that are too large or may assume that the route is congested. Effectively, parts of the Internet will become inaccessible.
パケットが大きすぎる（タイプ2）エラーメッセージ[RFC4443]は、ユニキャストアドレス間で任意のエンドに送信されます。メッセージは、次のリンクのMTUにはパケットが大きすぎるため、ノードがパケットを転送できない場合にパケットがパスを通過できない場合にパケットが通過するノードから生成できます。このメッセージは、PATH MTU発見の正しい機能に不可欠であるため、コミュニケーションの確立と維持の一部です。ルーターはパケットをフラグメントすることは許可されていないため、大きなパケットをフラグメントする必要性を情報源に通知することは、IPv4よりも重要です。これらのメッセージが必要に応じて生成されない場合、ホストは大きすぎるパケットを送信し続けるか、ルートが混雑していると想定する場合があります。事実上、インターネットの一部はアクセスできなくなります。
If a network chooses to generate packets that are no larger than the Guaranteed Minimum MTU (1280 octets) and the site's links to the wider Internet have corresponding MTUs, Packet Too Big messages should not be expected at the firewall and could be dropped if they arrive.
ネットワークが保証された最小MTU（1280オクテット）よりも大きくないパケットを生成することを選択し、サイトのより広いインターネットへのリンクには対応するMTUがあります。。
Time Exceeded (Type 3) error messages [RFC4443] can occur in two contexts:
時間を超えた（タイプ3）エラーメッセージ[RFC4443]は、2つのコンテキストで発生する可能性があります。
o Code 0 are generated at any node on the path being taken by the packet and sent, any-to-end between unicast addresses, if the Hop Limit value is decremented to zero at that node.
o コード0は、ホップ制限値がそのノードでゼロに減少した場合、パケットによって使用されて送信されるパスの任意のノードで生成され、ユニキャストアドレス間の任意のエンドで生成されます。
o Code 1 messages are generated at the destination node and sent end-to-end between unicast addresses if all the segments of a fragmented message are not received within the reassembly time limit.
o コード1のメッセージは、宛先ノードで生成され、断片化されたメッセージのすべてのセグメントが再組み立て時間制限内で受信されない場合、ユニキャストアドレス間でエンドツーエンドで送信されます。
Code 0 messages can be needed as part of the establishment of communications if the path to a particular destination requires an unusually large number of hops.
特定の宛先へのパスが異常に多数のホップを必要とする場合、通信の確立の一部としてコード0メッセージが必要になる場合があります。
Code 1 messages will generally only result from congestion in the network, and it is less essential to propagate these messages.
コード1のメッセージは通常、ネットワークの混雑からのみ生じ、これらのメッセージを伝播することはそれほど重要ではありません。
The great majority of Parameter Problem (Type 4) error messages will be generated by the destination node when processing destination options and other extension headers, and hence are sent end-to-end between unicast addresses. Exceptionally, these messages might be generated by any node on the path if a faulty or unrecognized hop-by-hop option is included or from any routing waypoint if there are faulty or unrecognized destination options associated with a Type 0 routing header. In these cases, the message will be sent any-to-end using unicast source and destination addresses.
パラメーター問題の大部分（タイプ4）エラーメッセージは、宛先オプションやその他の拡張ヘッダーを処理するときに宛先ノードによって生成されるため、ユニキャストアドレス間でエンドツーエンドが送信されます。例外的には、これらのメッセージは、障害または認識されていないホップバイホップオプションが含まれている場合、またはタイプ0ルーティングヘッダーに関連付けられた障害または認識されていない宛先オプションがある場合は、ルーティングウェイポイントからパス上の任意のノードによって生成される場合があります。これらの場合、メッセージはユニキャストソースと宛先アドレスを使用して任意のエンドで送信されます。
Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 (Unrecognized IPv6 Option) messages may result if a node on the path (usually the destination) is unable to process a correctly formed extension header or option. If these messages are not returned to the source, communication cannot be established, as the source would need to adapt its choice of options probably because the destination does not implement these capabilities. Hence, these messages need to be generated and allowed for effective IPv6 communications.
パラメーター問題コード1（認識されていない次のヘッダー）とコード2（認識されていないIPv6オプション）メッセージは、パス上のノード（通常は宛先）が正しく形成された拡張ヘッダーまたはオプションを処理できない場合に生じる場合があります。これらのメッセージがソースに返されない場合、ソースはおそらくこれらの機能を実装していないためにソースがオプションを選択する必要があるため、通信を確立できません。したがって、これらのメッセージを生成し、効果的なIPv6通信を可能にする必要があります。
Code 0 (Erroneous Header) messages indicate a malformed extension header generally as a result of incorrectly generated packets. Hence, these messages are useful for debugging purposes, but it is unlikely that a node generating such packets could establish communications without human intervention to correct the problem.
コード0（誤ったヘッダー）メッセージは、一般的に誤って生成されたパケットの結果として奇形の拡張ヘッダーを示します。したがって、これらのメッセージはデバッグの目的に役立ちますが、そのようなパケットを生成するノードが、問題を修正するために人間の介入なしにコミュニケーションを確立できる可能性は低いです。
Code 2 messages, only, can be generated for packets with multicast destination addresses.
コード2メッセージのみは、マルチキャストの宛先アドレスを備えたパケットに対して生成できます。
It is possible that attackers may seek to probe or scan a network by deliberately generating packets with unknown extension headers or options or with faulty headers. If nodes generate Parameter Problem error messages in all cases and these outgoing messages are allowed through firewalls, the attacker may be able to identify active addresses that can be probed further or learn about the network topology. The vulnerability could be mitigated whilst helping to establish communications if the firewall was able to examine such error messages in depth and was configured to only allow Parameter Problem messages for headers that had been standardized but were not supported in the protected network. If the network administrator believes that all nodes in the network support all legitimate extension headers, then it would be reasonable to drop all outgoing Parameter Problem messages. Note that this is not a major vulnerability in a well-designed IPv6 network because of the difficulties of performing scanning attacks (see Section 3.2).
攻撃者は、未知の拡張ヘッダーまたはオプションまたは故障したヘッダーを使用して、意図的にパケットを生成することにより、ネットワークを調査またはスキャンしようとする可能性があります。ノードがすべての場合にパラメーター問題エラーメッセージを生成し、これらの発信メッセージがファイアウォールを通じて許可されている場合、攻撃者はさらに調査できるアクティブアドレスを特定したり、ネットワークトポロジについて学んだりすることができる場合があります。ファイアウォールがそのようなエラーメッセージを詳細に調べることができ、保護されたネットワークではサポートされていないヘッダーのパラメーター問題メッセージのみを許可するように構成された場合、通信を確立するのに役立ちながら、脆弱性を軽減できます。ネットワーク管理者が、ネットワーク内のすべてのノードがすべての正当な拡張ヘッダーをサポートすると考えている場合、すべての発信パラメーター問題メッセージをドロップすることは合理的です。これは、スキャン攻撃を実行するのが難しいため、適切に設計されたIPv6ネットワークの大きな脆弱性ではないことに注意してください（セクション3.2を参照）。
Echo Request (Type 128) uses unicast addresses as source addresses, but may be sent to any legal IPv6 address, including multicast and anycast addresses [RFC4443]. Echo Requests travel end-to-end. Similarly, Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. They are mainly used in combination for monitoring and debugging connectivity. Their only role in establishing communication is that they are required when verifying connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to IPv6 nodes on the site will not be possible if these messages are blocked. It is not thought that there is a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), and so connectivity checks should be allowed by default.
Echo Request（Type 128）は、Unicastアドレスをソースアドレスとして使用しますが、マルチキャストやAnycastアドレス[RFC4443]を含む法的IPv6アドレスに送信される場合があります。エコーは旅行のエンドツーエンドを要求します。同様に、エコー応答（タイプ129）はエンドツーエンドで移動し、宛先としてユニキャストアドレスを持ち、ソースとしてユニキャストまたはanycastアドレスのいずれかを持ちます。それらは主に、接続性の監視とデバッグのために組み合わせて使用されます。通信を確立する唯一の役割は、Teredoトンネル[RFC4380]を介した接続を検証する際に必要であることです[RFC4380]：これらのメッセージがブロックされている場合、サイト上のIPv6ノードへのTeredoトンネルは不可能です。適切に設計されたIPv6ネットワークに対する攻撃のスキャンから大きなリスクがあるとは考えられていないため（セクション3.2を参照）、デフォルトで接続性チェックを許可する必要があります。
ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 136) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate and accept these messages to allow them to establish and maintain interfaces onto their connected links.
ICMPV6近隣の勧誘と近隣広告（タイプ135および136）メッセージは、ローカルリンクでの通信の確立とメンテナンスに不可欠です。ファイアウォールは、これらのメッセージを生成および受け入れて、接続されたリンクにインターフェイスを確立および維持できるようにする必要があります。
Note that the address scopes of the source and destination addresses on Neighbor Solicitations and Neighbor Advertisements may not match. The exact functions that these messages will be carrying out depends on the mechanism being used to configure IPv6 addresses on the link (Stateless, Stateful, or Static configuration).
近隣の勧誘と近隣の広告に関するソースおよび宛先アドレスのアドレススコープは一致しない場合があることに注意してください。これらのメッセージが実行される正確な関数は、リンク上のIPv6アドレスを構成するために使用されるメカニズムに依存します（ステートレス、ステートフル、または静的構成）。
ICMPv6 Router Solicitation and Router Advertisement (Type 133 and 134) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate (since the firewall will generally be behaving as a router) and accept these messages to allow them to establish and maintain interfaces onto their connected links.
ICMPV6ルーターの勧誘とルーター広告（タイプ133および134）メッセージは、ローカルリンクでの通信の確立とメンテナンスに不可欠です。ファイアウォールは（通常、ファイアウォールはルーターとして動作しているため）生成する必要があり、これらのメッセージを受け入れて、接続されたリンクにインターフェイスを確立および維持できるようにします。
ICMPv6 Redirect Messages (Type 137) are used on the local link to indicate that nodes are actually link-local and communications need not go via a router, or to indicate a more appropriate first-hop router. Although they can be used to make communications more efficient, they are not essential to the establishment of communications and may be a security vulnerability, particularly if a link is not physically secured. Conformant nodes are required to provide configuration controls that suppress the generation of Redirect messages and allow them to be ignored on reception. Using Redirect messages on, for example, a wireless link without link level encryption/authentication is particularly hazardous because the link is open to eavesdropping and packet injection.
ICMPV6リダイレクトメッセージ（タイプ137）はローカルリンクで使用され、ノードが実際にリンクローカルであり、通信がルーターを介して行く必要がないことを示すか、より適切な最初のホップルーターを示す必要はありません。通信をより効率的にするために使用できますが、コミュニケーションの確立に不可欠ではなく、特にリンクが物理的に保護されていない場合、セキュリティの脆弱性である可能性があります。適合ノードは、リダイレクトメッセージの生成を抑制し、受信時にそれらを無視できるようにする構成制御を提供するために必要です。たとえば、リダイレクトメッセージを使用すると、リンクレベルの暗号化/認証のないワイヤレスリンクは、リンクが盗聴やパケットインジェクションに開かれているため、特に危険です。
SEND [RFC3971] uses two messages (Certificate Path Solicitation and Advertisement - Types 148 and 149) sent from nodes to supposed routers on the same local link to obtain a certificate path that will allow the node to authenticate the router's claim to provide routing services for certain prefixes. If a link connected to a firewall/ router is using SEND, the firewall must be able to exchange these messages with nodes on the link that will use its routing services.
送信[RFC3971]は、同じローカルリンク上のノードから送信された2つのメッセージ（証明書パスの勧誘と広告 - タイプ148および149）を使用して、ノードがルーターの主張を認証することを可能にする証明書パスを取得する証明書パスを取得する2つのメッセージを使用します。特定のプレフィックス。ファイアウォール/ルーターに接続されたリンクが送信を使用している場合、ファイアウォールは、ルーティングサービスを使用するリンク上のノードとこれらのメッセージを交換できる必要があります。
Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener Query, Listener Report, and Listener Done - Types 130, 131, and 132) and version 2 [RFC3810] (Listener Query and Listener Report version 2 - Types 130 and 143) messages are sent on the local link to communicate between multicast-capable routers and nodes that wish to join or leave specific multicast groups. Firewalls need to be able to generate Listener messages in order to establish communications and may generate all the messages if they also provide multicast routing services.
マルチキャストリスナーディスカバリー（MLD）バージョン1 [RFC2710]（リスナークエリ、リスナーレポート、リスナーが完了 - タイプ130、131、および132）およびバージョン2 [RFC3810]（リスナークエリおよびリスナーレポートバージョン2-タイプ130および143）メッセージはローカルリンクで送信され、特定のマルチキャストグループを結合または残したいマルチキャスト対応ルーターとノード間の通信があります。ファイアウォールは、通信を確立するためにリスナーメッセージを生成できる必要があり、マルチキャストルーティングサービスも提供する場合、すべてのメッセージを生成する必要があります。
Multicast Router Discovery [RFC4286] (Router Advertisement, Router Solicitation, and Router Termination - Types 151, 152, and 153) messages are sent by nodes on the local link to discover multicast-capable routers on the link, and by multicast-capable routers to notify other nodes of their existence or change of state. Firewalls that also act as multicast routers need to process these messages on their interfaces.
マルチキャストルーターの発見[RFC4286]（ルーター広告、ルーターの勧誘、およびルーター終了 - タイプ151、152、および153）メッセージは、ローカルリンクでノードによって送信され、リンク上のマルチキャスト対応ルーターを発見し、マルチキャストで課せられるルーターによって送信されます。他のノードにそれらの存在または状態の変化を通知する。マルチキャストルーターとしても機能するファイアウォールは、これらのメッセージをインターフェイスで処理する必要があります。
ICMPv6 Router Renumbering (Type 138) command messages can be received and results messages sent by routers to change the prefixes that they advertise as part of Stateless Address Configuration [RFC2461], [RFC2462]. These messages are sent end-to-end to either the all-routers multicast address (site or local scope) or specific unicast addresses from a unicast address.
ICMPV6ルーターの変更（タイプ138）コマンドメッセージを受信し、結果のメッセージをルーターから送信して、ステートレスアドレス構成[RFC2461]、[RFC2462]の一部として宣伝するプレフィックスを変更することができます。これらのメッセージは、エンドツーエンドで、オールルーターのマルチキャストアドレス（サイトまたはローカルスコープ）またはユニキャストアドレスから特定のユニキャストアドレスのいずれかに送信されます。
Router Renumbering messages are required to be protected by IPsec authentication since they could be readily misused by attackers to disrupt or divert site communications. Renumbering messages should generally be confined to sites for this reason.
ルーターの名前を変更するメッセージは、サイト通信を混乱させたり迂回させたりするために攻撃者が容易に誤用する可能性があるため、IPSEC認証によって保護される必要があります。この理由で、メッセージを変更することは通常、サイトに限定される必要があります。
ICMPv6 Node Information Query and Reply (Type 139 and 140) messages defined in [RFC4620] are sent end-to-end between unicast addresses, and they can also be sent to link-local multicast addresses. They can, in theory, be sent from any node to any other, but it would generally not be desirable for nodes outside the local site to be able to send queries to nodes within the site. Also, these messages are not required to be authenticated.
[RFC4620]で定義されているICMPV6ノード情報クエリと応答（タイプ139および140）メッセージは、ユニキャストアドレス間でエンドツーエンドで送信され、Link-Local Multicastアドレスに送信することもできます。理論的には、任意のノードから他のノードに送信することはできますが、通常、ローカルサイトの外側のノードがサイト内のノードにクエリを送信できるようには望ましくありません。また、これらのメッセージは認証する必要はありません。
Mobile IPv6 [RFC3775] defines four ICMPv6 messages that are used to support mobile operations: Home Agent Address Discovery Request, Home Agent Address Discovery Reply, Mobile Prefix Solicitation, and ICMP Mobile Prefix Advertisement (Type 144, 145, 146, and 147) messages. These messages are sent end-to-end between unicast addresses of a mobile node and its home agent. They must be expected to be sent from outside a site and must traverse site-boundary firewalls to reach the home agent in order for Mobile IPv6 to function. The two Mobile prefix messages should be protected by the use of IPsec authentication.
モバイルIPv6 [RFC3775]は、モバイル操作をサポートするために使用される4つのICMPV6メッセージを定義します：ホームエージェントアドレスディスカバリーリクエスト、ホームエージェントアドレスディスカバリー返信、モバイルプレフィックス勧誘、およびICMPモバイルプレフィックス広告（タイプ144、145、146、および147）メッセージ。これらのメッセージは、モバイルノードのユニキャストアドレスとそのホームエージェントの間でエンドツーエンドで送信されます。それらはサイトの外部から送信されることが期待されている必要があり、モバイルIPv6が機能するためにホームエージェントに到達するために、サイトに囲まれたファイアウォールを横断する必要があります。2つのモバイルプレフィックスメッセージは、IPSEC認証を使用して保護する必要があります。
o If the site provides home agents for mobile nodes, the firewall must allow incoming Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and outgoing Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages. It may be desirable to limit the destination addresses for the incoming messages to links that are known to support home agents.
o サイトがモバイルノードにホームエージェントを提供する場合、ファイアウォールは、入ってくるホームエージェントアドレスディスカバリーリクエストとモバイルプレフィックス勧誘メッセージ、および発信ホームエージェントアドレスディスカバリーの返信とICMPモバイルプレフィックス広告メッセージを許可する必要があります。入ってくるメッセージの宛先アドレスを、ホームエージェントをサポートすることが知られているリンクに制限することが望ましい場合があります。
o If the site is prepared to host roaming mobile nodes, the firewall must allow outgoing Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and incoming Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages.
o サイトがローミングモバイルノードをホストする準備ができている場合、ファイアウォールは発信ホームエージェントアドレスディスカバリーリクエストとモバイルプレフィックス勧誘メッセージ、および着信ホームエージェントアドレスディスカバリーの返信とICMPモバイルプレフィックス広告メッセージを許可する必要があります。
o Administrators may find it desirable to prevent static nodes that are normally resident on the site from behaving as mobile nodes by dropping Mobile IPv6 messages from these nodes.
o 管理者は、これらのノードからモバイルIPv6メッセージを削除することにより、通常サイトに居住する静的ノードをモバイルノードとして動作させるのを防ぐことが望ましい場合があります。
A large number of ICMPv6 Type values are currently unused. These values have not had a specific function registered with IANA. This section describes how to treat messages that attempt to use these Type values in a way of which the network administrator (and hence the firewall) is not aware.
多数のICMPV6タイプの値は現在未使用です。これらの値には、IANAに登録された特定の関数がありません。このセクションでは、ネットワーク管理者（したがってファイアウォール）が認識していない方法でこれらのタイプの値を使用しようとするメッセージを扱う方法について説明します。
[RFC4443] defines a number of experimental Type values for ICMPv6 Error and Informational messages, which could be used in site-specific ways. These messages should be dropped by transit networks and at site edges. They should also not be propagated within sites unless the network administrator is explicitly made aware of usage.
[RFC4443]は、サイト固有の方法で使用できるICMPV6エラーと情報メッセージの多くの実験型値を定義します。これらのメッセージは、トランジットネットワークおよびサイトエッジでドロップする必要があります。また、ネットワーク管理者が明示的に使用を認識しない限り、サイト内で伝播するべきではありません。
The codes reserved for future extension of the ICMPv6 Type space should currently be dropped as this functionality is as yet undefined.
この機能はまだ定義されていないため、ICMPV6型スペースの将来の拡張のために予約されているコードは現在削除する必要があります。
Any ICMPv6 Informational messages of which the firewall is not aware should be allowed to transit through the firewall but should not be accepted for local delivery on any of its interfaces.
ファイアウォールが認識していないICMPV6情報メッセージは、ファイアウォールを通過することを許可されるべきではありませんが、そのインターフェイスでのローカル配信に受け入れられるべきではありません。
Unknown ICMPv6 Error messages should be allowed to pass through transit networks. At end site boundaries any incoming ICMPv6 Error messages of which the firewall is not aware may be allowed through the firewall in line with the specification in [RFC4443], which requests delivery of unknown error messages to higher-layer protocol processes. However, administrators may wish to disallow forwarding of these incoming messages as a potential security risk. Unknown outgoing Error messages should be dropped as the administrator should be aware of all messages that could be generated on the site.
不明なICMPV6エラーメッセージは、トランジットネットワークを通過することを許可する必要があります。エンドサイトの境界では、[RFC4443]の仕様に沿ったファイアウォールを介してファイアウォールが認識していない任意のICMPV6エラーメッセージが許可されます。ただし、管理者は、潜在的なセキュリティリスクとして、これらの着信メッセージの転送を禁止することを望む場合があります。管理者は、サイトで生成できるすべてのメッセージを管理者が認識する必要があるため、不明な発信エラーメッセージをドロップする必要があります。
Also, the SEAMOBY working group has had an ICMPv6 message (Type 150) allocated for experimental use in two protocols. This message is sent end-to-end and may need to pass through firewalls on sites that are supporting the experimental protocols.
また、Seamobyワーキンググループには、2つのプロトコルで実験的に使用するためにICMPV6メッセージ（タイプ150）が割り当てられています。このメッセージはエンドツーエンドで送信され、実験プロトコルをサポートしているサイトのファイアウォールを通過する必要がある場合があります。
This appendix contains an example script to implement most of the rules suggested in this document when using the Netfilter packet filtering system for Linux [netfilter]. When used with IPv6, the 'ip6tables' command is used to configure packet filtering rules for the Netfilter system. The script is targeted at a simple enterprise site that may or may not support Mobile IPv6.
この付録には、Linux [netFilter]のNetFilterパケットフィルタリングシステムを使用する際に、このドキュメントで提案されているほとんどのルールを実装するための例のスクリプトが含まれています。IPv6で使用する場合、「IP6Tables」コマンドを使用して、NetFilterシステムのパケットフィルタリングルールを構成します。このスクリプトは、モバイルIPv6をサポートする場合とサポートしていない場合があるシンプルなエンタープライズサイトを対象としています。
#!/bin/bash
# Set of prefixes on the trusted ("inner") side of the firewall
export INNER_PREFIXES="2001:DB8:85::/60"
# Set of hosts providing services so that they can be made pingable
export PINGABLE_HOSTS="2001:DB8:85::/64"
# Configuration option: Change this to 1 if errors allowed only for
# existing sessions
export STATE_ENABLED=0
# Configuration option: Change this to 1 if messages to/from link
# local addresses should be filtered.
# Do not use this if the firewall is a bridge.
# Optional for firewalls that are routers.
export FILTER_LINK_LOCAL_ADDRS=0
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 Home Agents - see Appendix A.14
export HOME_AGENTS_PRESENT=1
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 mobile nodes being present on the site -
# see Appendix A.14
export MOBILE_NODES_PRESENT=1
ip6tables -N icmpv6-filter
ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
# Match scope of src and dest else deny
# This capability is not provided for in base ip6tables functionality
# An extension (agr) exists which may support it.
#@TODO@
# ECHO REQUESTS AND RESPONSES
# ===========================
# Allow outbound echo requests from prefixes which belong to the site for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type echo-request -j ACCEPT done
＃$ inner_prefixes do ip6tables -a icmpv6 -filter -p icmpv6 -s $ inner_prefix \ -icmpv6 -type echo -request -j compced doing in innine_prefixesのinner_prefixのサイトに属するプレフィックスからのアウトバウンドエコー要求を許可
# Allow inbound echo requests towards only predetermined hosts for pingable_host in $PINGABLE_HOSTS do ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ --icmpv6-type echo-request -j ACCEPT done
＃$ pingable_hosts do ip6tables -a icmpv6 -d $ pingable_host \ -icmpv6 -type echo -request -j受け入れ行われた$ pinable_hosts do ip6tables do ip6tablesのpingable_hostの所定のホストのみにインバウンドエコー要求を許可する
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming and outgoing echo reply messages # only for existing sessions ip6tables -A icmpv6-filter -m state -p icmpv6 \ --state ESTABLISHED,RELATED --icmpv6-type \ echo-reply -j ACCEPT else # Allow both incoming and outgoing echo replies for pingable_host in $PINGABLE_HOSTS do # Outgoing echo replies from pingable hosts ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \ --icmpv6-type echo-reply -j ACCEPT done # Incoming echo replies to prefixes which belong to the site for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type echo-reply -j ACCEPT done fi
["$ state_enabled" -eq "1"]]の場合、＃既存のセッションのみの既存のセッションのみの場合にのみ受信と発信エコーの応答メッセージを許可します。返信-J Accept done＃inner_prefixのinner_prefixのサイトに属するプレフィックスへの着信エコー応答$ inner_prefixes do ip6tables -a icmpv6 -filter -p icmpv6 -d $ inen_prefix \ -icmpv6 -type echo -reply -jAcceant done fi fi
# Deny icmps to/from link local addresses
# If the firewall is a router:
# These rules should be redundant as routers should not forward
# link local addresses but to be sure...
# DO NOT ENABLE these rules if the firewall is a bridge
if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ]
then
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
fi
# Drop echo replies which have a multicast address as a
# destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
--icmpv6-type echo-reply -j DROP
# DESTINATION UNREACHABLE ERROR MESSAGES
# ======================================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming destination unreachable messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type \ destination-unreachable -j ACCEPT done else # Allow incoming destination unreachable messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type destination-unreachable -j ACCEPT done fi
["$ state_enabled" -eq "1"]]の場合、$ inner_prefixesのinner_prefixの既存のセッションに対してのみ到達不可能なメッセージを許可します。州の確立、関連、関連、ICMPV6 -Type \ Destination -Unreachable -J Accepce Accept enth＃IP6tablesを行う$ inner_prefixes do icmpv6 -filter -p icmpv6 -d $ inner_prefix \ -icmpv6 -type destinationのintern_prefixのinner_prefixの到達不可能なメッセージを許可します-nReachable -jはfiを受け入れます
# Allow outgoing destination unreachable messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type destination-unreachable -j ACCEPT done
＃$ inner_prefixesのinner_prefixの発信先の到達不可能なメッセージを許可するip6tables -a icmpv6 -filter -p icmpv6 -s $ inner_prefix \ -icmpv6 -type -cmpv6 -type -unreachable -j Acceat
# PACKET TOO BIG ERROR MESSAGES
# =============================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming Packet Too Big messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \
["$ state_enabled" -eq "1"]]の場合、$ inner_prefixs do ip6tables -a icmpv6 -filter -m state -p icmpv6 \ in inner_prefixの既存のセッションに対してのみ、着信パケットが大きすぎるメッセージを許可します。
-d $inner_prefix \ --state ESTABLISHED,RELATED \ --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming Packet Too Big messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type packet-too-big -j ACCEPT done fi
-d $ inner_prefix \ - ステートは確立された、関連する\ -icmpv6-type packet-too-big \ -jを受け入れる＃intern_prefixesのintern_prefixのinner_prefixのために入力パケットを許可することを許可します-ip6tables -a icmpv6-filter -p icmpv666-d $ inner_prefix \ -icmpv6-type packet-too-big -j Accept done fi
# Allow outgoing Packet Too Big messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type packet-too-big -j ACCEPT done
＃$ inner_prefixes do ip6tables -a icmpv6 -filter -p icmpv6 -s $ inner_prefix \ -icmpv6 -type packet -too -big -j Accept doned doned done done doin
# TIME EXCEEDED ERROR MESSAGES
# ============================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi
["$ state_enabled" -eq "1"]]の場合、＃inner_prefixの既存のセッションのみの既存のセッションのみのコード0メッセージを超えてください。 - ステートは確立された、関連、ICMPV6-TYPE PACKET-TOO-BIG \ -J ACCEPT OND DONE＃IP6TABLES -A ICMPV6-FILTER -P ICMPV6 -D $ INNER_PREFIX \のINNEN_PREFIXEのINNEN_PREFIXのコード0メッセージを超えたintern_prefixを超えます。-ICMPV6-TTL-ZERO-DURING-TRANSIT -J Accept Done fi
#@POLICY@
# Allow incoming time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
# Allow outgoing time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done
＃$ inner_prefixesのinner_prefixのコード0メッセージを超えた出力時間を超えてip6tables -a icmpv6-filter -p icmpv6 -s $ inner_prefix \ -icmpv6-type ttl-zero-during-transit -j Accect done
#@POLICY@
# Allow outgoing time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
# PARAMETER PROBLEM ERROR MESSAGES
# ================================
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming parameter problem code 1 and 2 messages # for an existing session for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type \ unknown-header-type \ -j ACCEPT ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED \ --icmpv6-type unknown-option \ -j ACCEPT done fi
["$ state_enabled" -eq "1"]]の場合、$ inner_prefixの既存セッションの既存のセッションの場合は、$ inner_prefixesの既存のセッションの場合は、入力パラメーター問題コード1および2メッセージを許可します-a icmpv6 -filter -m state -p icmpv6 \ -d $inner_prefix \ - state確立、関連、関連-cmpv6 -type \ unking -header -type \ -jはip6tables -a icmpv6 -filter -m state -p icmpv6 \ -d $ inner_prefix \ - -state確立、関連\ - icmpv6-type nown option \ -jは完了したfiを受け入れます
# Allow outgoing parameter problem code 1 and code 2 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-header-type -j ACCEPT
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-option -j ACCEPT done
-icmpv6-type nown option -jは完了しました
#@POLICY@ # Allow incoming and outgoing parameter # problem code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 \ --icmpv6-type bad-header \ -j ACCEPT done
＃@ policy＃＃daul incoming and inoving parameter＃問題コード0 inner_prefixのinner_prefix do ip6tables -a icmpv6 -filter -p icmpv6 \ -icmpv6 -type bad -header \ -j Accect done
# NEIGHBOR DISCOVERY MESSAGES
# ===========================
# Drop NS/NA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-advertisement -j DROP
# Drop RS/RA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-advertisement -j DROP
# Drop Redirect messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP
# MLD MESSAGES
# ============
# Drop incoming and outgoing
# Multicast Listener queries (MLDv1 and MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP
# Drop incoming and outgoing Multicast Listener Done messages (MLDv1)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv2)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP
# ROUTER RENUMBERING MESSAGES
＃ルーターの変更メッセージ
# ===========================
# Drop router renumbering messages
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP
# NODE INFORMATION QUERIES
# ========================
# Drop node information queries (139) and replies (140)
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP
# MOBILE IPv6 MESSAGES
# ====================
# If there are mobile ipv6 home agents present on the
# trusted side allow
if [ "$HOME_AGENTS_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#incoming Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#outgoing Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#incoming Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#outgoing Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# If there are roaming mobile nodes present on the
# trusted side allow
if [ "$MOBILE_NODES_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#outgoing Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#incoming Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#outgoing Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#incoming Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# DROP EVERYTHING ELSE
# ====================
ip6tables -A icmpv6-filter -p icmpv6 -j DROP
Example Netfilter Configuration Script for ICMPv6 Filtering
ICMPV6フィルタリングのためのNetFilter構成スクリプトの例
Authors' Addresses
著者のアドレス
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B. DaviesコンサルタントSoham、Cambs UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Janos Mohacsi NIIF/HUNGARNET Victor Hugo u. 18-22 Budapest, H-1132 Hungary
Janos Mohacsi Niif/Hungarnet Victor Hugo U。18-22ブダペスト、H-1132ハンガリー
Phone: +36 1 4503070
EMail: mohacsi@niif.hu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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トラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。