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
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）IETFトラスト（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
すべてのICMPv6メッセージは、サイト内で発信または終端するエンドサイトO、または
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.
第4節で推奨フィルタリングルールにスキップすることができたICMPv6に精通読者と付録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].
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].
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].
* 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].
*ネイバーが最初の発見（近隣到達不能ディスカバリー - NUD）後に同じIPとリンク層アドレスを使用して到達可能なままであることの確認とリンク層アドレスに変更の隣人に通知します。 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
リンクに接続ルータを認証するために、安全な近隣探索（SEND）を使用する場合は*、[RFC3971]で指定された証明書パスの勧誘や広告メッセージは、証明書を取得するためにホストが使用されています
documenting the trust chain between a trust anchor and the router from the router.
トラストアンカーとルータからルータ間の信頼チェーンを文書化します。
* 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アドレスを与えられました。二つのメッセージ、逆近隣探索要請し、広告メッセージは、[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].
*マルチキャストグループがリンクに接続されたマルチキャスト対応ルータへのリンクをリスナーを持っている通信。マルチキャストリスナ発見の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].
* 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].
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].
* 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のメッセージ未満または127に等しいとの間の整数として解釈8ビットのタイプフィールドを含むエラーメッセージです。残りは情報メッセージです。一般的な用語で、（標準）は、周知でのエラーメッセージは、値を入力し、通常に送信されるか、またはファイアウォールを通過することを許可することが期待される、通信の確立および維持に不可欠であってもよい（セクション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送信元アドレスとしてリンクローカルアドレスに送信されます。 :) 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.
宛先アドレスは、このような要請ノードマルチキャストアドレス、エニーキャストアドレス、またはユニキャストアドレスとしてよく知られているマルチキャストアドレス、生成されたマルチキャストアドレスのいずれかとすることができます。多くのICMPv6メッセージは、ほとんどの時間をマルチキャストアドレスを使用していますが、いくつかはまた、ユニキャストアドレスを使用します。場合迷惑例えば、ルータ広告メッセージは、すべてのノードマルチキャストアドレスに送信され、これはめったに現在の実装では見られなかったが、また、特定のルータ要請に応じて、ユニキャストアドレスに送信することができます。
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.
ローカル通信は、多くの場合、リンクローカルアドレスを使用しますが、グローバルアドレスを設定する際にも、例えば、グローバルユニキャストアドレスを使用することができます。また、ローカル通信で使用されるいくつかの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通信のセキュリティを向上させるための手段として指定されています。 SENDは、IPsecを使用した場合に生じるセキュリティアソシエーションのブートストラップの問題を回避し。 SENDはリンクローカルメッセージに影響を与え、ファイアウォールが適用できるフィルタリングを限定するものではなく、セキュリティにおけるその役割は、したがって、本書で詳しく説明されていません。
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のアドレスは簡単に推測可能な方法で割り当てられていないことを提供すると比較して、あまり効果的な武器を探査することができます。この主題は、[SCAN-IMP]においてより深く探求されています。
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.
リダイレクト攻撃は、man-in-the-middle攻撃を実行するかのどちらか悪意のあるモニターにパケットをそらすまたはパケットをブラックホール化により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
ICMPv6のトラフィックのルールがためにいくつかのマイナーなバリエーションで、ファイアウォールを通過するO
* 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 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).
管理者は、ドロップ（例えば、ICMPノード情報名前検索クエリ）を考慮すべきであるOメッセージ。
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メッセージは、メッセージおよびタイプ（ユニキャスト、マルチキャスト、等）及び範囲（リンクローカル、グローバルユニキャストのICMPv6のタイプに基づいてフィルタリングされなければなりません、送信元アドレスと宛先アドレスのなど）。いくつかのケースでは、ICMPv6エラーメッセージのCodeフィールドにフィルタを適用することが望ましい場合があります。
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メッセージは、彼らがサイト上またはいくつかの他のノードにノードに宛てているかどうかに応じて異なる方法で処理することができます。エンドサイトでは、パケットがないサイト上のノードにアドレスドロップする必要がありますが、一般的にトランジットサイト上のファイアウォールによって転送されるだろう。
4.2. Interaction of Link-Local Messages with Firewall/Routers and Firewall/Bridges
4.2. ファイアウォール/ルータとファイアウォール/ブリッジとのリンクローカルメッセージの相互作用
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層に対して透過的リンク層ブリッジ（例えば、イーサネット・ブリッジ）の両方として実装することができます。
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:
ローカルリンク上の通信の確立と維持のために使用されるメッセージの多くは、送信元と送信先の少なくとも一つのリンクローカルアドレスに送信されます。 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.
IPv6ヘッダーのホップ制限は、送信時に255に設定されていることを要求O。受信機は、パケットがルータを通過していないことを確認するために、ホップ制限がまだ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のすべてのコードの時間が超過O（タイプ2）（タイプ3） - コード0のみパラメータ問題O（タイプ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)
エコー応答（タイプ129）O Oエコー要求（タイプ128）
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ホームエージェントは、モバイルプレフィックス広告（タイプ147）Oモバイルプレフィックス要請（タイプ146）OディスカバリーReplyを（145種類）アドレスホームエージェントoを発見要求（タイプ144）のアドレス
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で説明したように、より選択的なルールを適用することを望むかもしれません。
4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed
4.3.3. とにかく削除されます交通 - 不要特別な注意
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逆近隣探索要請（タイプ141）OリダイレクトO近隣広告O近隣要請（タイプ135）（タイプ136）Oルータ広告（タイプ134）（タイプ137）（タイプO Oルータ要請（タイプ133） 142）
Link-local multicast receiver notification messages (must have link-local source address):
リンクローカルマルチキャストレシーバ通知メッセージ（リンクローカル送信元アドレスを持っている必要があります）：
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143)
OリスナクエリリスナーOリスナーレポート（タイプ131）O（タイプ130）リスナーレポートV2（タイプ143）O（タイプ132）を完了します
SEND Certificate Path notification messages (must be received with hop limit = 255):
証明書パスの通知メッセージを送信する（= 255ホップ制限を受けなければなりません）：
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
証明書パス広告（タイプ149）〇〇証明書パス要請（タイプ148）
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マルチキャストルータ要請（タイプ152）O（タイプ151）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)
Seamoby実験（タイプ150）O
Error messages not currently defined by IANA: o Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
エラーメッセージは、現在、IANAによって定義されていない：未割り当てエラーメッセージ（タイプ5-99包括的かつ包括的102-126）O
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ノード情報クエリノード情報応答O（タイプ139）（タイプ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のすべてのコードの時間が超過O（タイプ2）（タイプ3） - コード0のみパラメータ問題O（タイプ4） - コード1と2のみ
Connectivity checking messages:
接続性チェックのメッセージ：
o Echo Request (Type 128) o Echo Response (Type 129)
エコー応答（タイプ129）O Oエコー要求（タイプ128）
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項を参照）を講じる必要のあるRedirectメッセージです。
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)
逆近隣探索広告O近隣広告O近隣要請（タイプ135）逆近隣探索要請O（タイプ136）（タイプ141）Oルータ広告（タイプ134）O Oルータ要請（タイプ133）（タイプ142）
Link-Local Multicast Receiver Notification messages:
リンクローカルマルチキャスト受信通知メッセージ：
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143)
OリスナクエリリスナーOリスナーレポート（タイプ131）O（タイプ130）リスナーレポートV2（タイプ143）O（タイプ132）を完了します
SEND Certificate Path Notification messages:
証明書パスの通知メッセージを送信：
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
証明書パス広告（タイプ149）〇〇証明書パス要請（タイプ148）
Multicast Router Discovery messages:
マルチキャストルータ発見メッセージ：
o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153)
マルチキャストルータ広告マルチキャストルータ終了Oマルチキャストルータ要請（タイプ152）O（タイプ151）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
4.4.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed
4.4.3. とにかく削除されます交通 - 不要特別な注意
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ホームエージェントは、モバイルプレフィックス広告（タイプ147）Oモバイルプレフィックス要請（タイプ146）OディスカバリーReplyを（145種類）アドレスホームエージェントoを発見要求（タイプ144）のアドレス
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)
Seamoby実験（タイプ150）O
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ノード情報クエリノード情報応答O（タイプ139）（タイプ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.
ペッカSavolaは、ICMPv6のフィルターのセットアップのための提案が含まれ、元のIPv6セキュリティの概要文書を作成しました。この情報は、本文書に組み込まれています。彼はまた、重要なコメントを提供しています。 ICMPv6メッセージの分類と「どんなツーエンドの」用語のいくつかの分析は、ICMPv6のとIKEに関連する文書でヤリArkkoで使用されました。
The Netfilter configuration script in Appendix B was contributed by Suresh Krishnan.
付録BでNetfilterの構成スクリプトがあるSureshクリシュナンによって寄贈されました。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見（MLD）"、RFC 2710、1999年10月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894]クロフォード、M.、 "IPv6のルータリナンバリング"、RFC 2894、2000年8月。
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3122]コンタ、A.、RFC 3122、2001年6月 "インバース・ディスカバリー仕様のIPv6近隣探索への拡張"。
[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC3590]ハーバーマン、B.、 "Multicast Listener Discovery（MLD）プロトコルのためのソースアドレス選択"、RFC 3590、2003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、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.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4065]ケンプ、J.、RFC 4065、2005年7月 "Seamobyと実験モビリティプロトコルのIANAの割り当てのための手順"。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]ハーバーマン、B.及びJ.マーチン、 "マルチキャストルータ発見"、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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006.
[RFC4620]クロフォード、M.とB.ハーバーマン、 "IPv6のノード情報問合せ"、RFC 4620、2006年8月。
[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[ICMP攻撃] 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におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、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、 "netfilter.orgプロジェクト"、Linuxでは、2006年のファイアウォー、NATやパケットマングリング、<http://www.netfilter.org/>。
Appendix A. Notes on Individual ICMPv6 Messages
付録A.には、個々のICMPv6メッセージについての注意事項
A.1. Destination Unreachable Error Message
A.1。宛先到達不能エラーメッセージ
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宛先到達不能メッセージの生成を可能にした場合、それは、のいずれかのノードが正しい理由コードを提供することが重要である：目的地までのルートは、管理上、送信元アドレス、到達不能アドレス、到達不能ポートの範囲を超えて、禁止され、送信元アドレスが失敗したイングレス/出力ポリシー、または目的地までのルートを拒否。
A.2. Packet Too Big Error Message
A.2。パケット過大エラーメッセージ
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には大きすぎるため、ノードはパケットを転送することができない場合、パケットが経路に横断する任意のノードから生成することができます。このメッセージは、パス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を、パケット過大メッセージはファイアウォールで期待すべきではないと、彼らが到着した場合にドロップすることができているよりも大きくないパケットを生成することを選択した場合。
A.3. Time Exceeded Error Message
A.3。時間超過エラーメッセージ
Time Exceeded (Type 3) error messages [RFC4443] can occur in two contexts:
時間超過（タイプ3）のエラーメッセージは、[RFC4443]は二つのコンテキストで発生する可能性があります。
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つのメッセージは、一般的にのみネットワークの輻輳からなり、そしてこれらのメッセージを伝播するあまり必要不可欠です。
A.4. Parameter Problem Error Message
A.4。パラメータ問題エラーメッセージ
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節を参照してください）。
A.5. ICMPv6 Echo Request and Echo Response
A.5。 ICMPv6エコー要求とエコー応答
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.
エコー要求（タイプ128）は、ソースアドレスとしてユニキャストアドレスを使用するが、マルチキャストおよびエニーキャストアドレス[RFC4443]を含む任意の法的なIPv6アドレスに送信されてもよいです。エコー要求は、エンドツーエンドの旅行します。同様に、エコー応答（タイプ129）は、エンド・ツー・エンドを移動し、ソース、宛先及びユニキャストまたはエニーキャストアドレスのいずれかのようなユニキャストアドレスを有することになります。これらは主に、監視とデバッグ接続のための組み合わせで使用されています。通信の確立に彼らの唯一の役割は、Teredoのトンネル[RFC4380]を通じて接続性を検証する際にそれらが必要なことである。これらのメッセージがブロックされている場合は、サイト上のIPv6ノードへのTeredoトンネリングはできません。 （3.2節を参照）うまく設計されたIPv6ネットワーク上の攻撃をスキャンからの重大なリスクがあることが考えられていない、ので、接続性チェックはデフォルトで許可されなければなりません。
A.6. Neighbor Solicitation and Neighbor Advertisement Messages
A.6。近隣要請と近隣広告メッセージ
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アドレスを設定するために使用されるメカニズムに依存します。
A.7. Router Solicitation and Router Advertisement Messages
A.7。ルータ要請およびルータ広告メッセージ
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）のメッセージは、ローカルリンク上の通信の確立と維持に不可欠です。ファイアウォールは、（ファイアウォールは、一般的にルータとして動作することになるので）を生成し、それらを確立し、その接続されたリンクの上のインターフェイスを維持することができるように、これらのメッセージに同意する必要があります。
A.8. Redirect Messages
A.8。メッセージのリダイレクト
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）は、ノードが実際にリンクローカルであり、通信はルータを経由、またはより適切なファーストホップルータを示すために必要がないことを示すために、ローカルリンク上で使用されています。彼らはコミュニケーションをより効率的にするために使用することができますが、彼らはコミュニケーションの確立に不可欠なものではなく、リンクが物理的に確保されていない場合は特に、セキュリティ上の脆弱性があることがあります。準拠ノードはリダイレクトメッセージの発生を抑える構成制御を提供し、それらは、受信時には無視されることを可能にするために必要とされます。リンクは盗聴とパケットインジェクションに開いているためにリダイレクトメッセージを使用して、例えば、リンクレベルの暗号化/認証なしで無線リンクは特に危険です。
A.9. SEND Certificate Path Messages
A.9。証明書パスメッセージを送信
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]は二つのメッセージ（タイプ148と149証明書パスの勧誘や広告）を使用する送信特定の接頭辞。ファイアウォール/ルータに接続されたリンクを送る使用している場合、ファイアウォールはそのルーティング・サービスを使用するリンク上のノードと、これらのメッセージを交換することができなければなりません。
A.10. Multicast Listener Discovery Messages
A.10。マルチキャストリスナ発見メッセージ
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）メッセージは、特定のマルチキャストグループに参加したり、残したいマルチキャスト対応ルータおよびノード間で通信するためにローカルリンク上で送られます。ファイアウォールは、通信を確立するために、リスナーのメッセージを生成できるようにする必要があり、彼らはまた、マルチキャストルーティングサービスを提供する場合、すべてのメッセージを生成することがあります。
A.11. Multicast Router Discovery Messages
A.11。マルチキャストルータ検出メッセージ
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）メッセージは、リンク上でマルチキャスト対応ルータを発見するために、ローカルリンク上のノードによって送信され、マルチキャスト対応ルータによって彼らの存在や状態の変化の他のノードに通知します。また、マルチキャストルータとして動作するファイアウォールは、そのインターフェイス上で、これらのメッセージを処理する必要があります。
A.12. Router Renumbering Messages
A.12。ルータリナンバリングメッセージ
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認証によって保護される必要があります。リナンバリングメッセージは、一般的にこのような理由のためのサイトに限定されなければなりません。
A.13. Node Information Query and Reply
A.13。ノード情報の照会および返信
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.
ICMPv6のノード情報クエリと[RFC4620]で定義された応答（タイプ139および140）メッセージは、エンドツーエンドのユニキャスト・アドレスとの間で送信され、それらはまた、リンクローカルマルチキャストアドレスに送信することができます。彼らは、理論的には、他に任意のノードから送信することができますが、それは一般的に、サイト内のノードにクエリを送信できるようにするには、ローカル・サイト外のノードのために望ましいことではないでしょう。また、これらのメッセージは認証される必要はありません。
A.14. Mobile IPv6 Messages
A.14。モバイルIPv6メッセージ
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
モバイルIPv6 [RFC3775]は、移動操作をサポートするために使用される4つのICMPv6メッセージを定義：ホームエージェントを発見要求アドレス、ホームエージェントアドレス探索応答、モバイルプレフィックス要請、およびICMPモバイルプレフィックス広告（タイプ144、145、146、および147）メッセージ。これらのメッセージは、ユニキャスト、モバイルノードのアドレスとそのホームエージェントとの間のエンドツーエンドに送信されます。彼らは、サイト外から送信されると予想されなければならないとモバイルIPv6が機能するためには、ホームエージェントに到達するために、サイト境界ファイアウォールを通過しなければなりません。二つ
Mobile prefix messages should be protected by the use of IPsec authentication.
モバイルプレフィックスメッセージは、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.15. Unused and Experimental Messages
A.15。未使用と実験のメッセージ
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エラーメッセージは、中継ネットワークを通過させるべきです。エンドサイト境界でファイアウォールが認識していないとなっているすべての着信ICMPv6エラーメッセージは、上位層プロトコルプロセスに不明なエラーメッセージの配信を要求する、[RFC4443]での指定に合わせて、ファイアウォールの通過を許可することができます。ただし、管理者は、潜在的なセキュリティリスクとしてこれらの受信メッセージの転送を禁止することを望むかもしれません。管理者がサイト上で生成することができ、すべてのメッセージに注意する必要がありますよう不明な送信エラーメッセージは廃棄されなければなりません。
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）を有していました。このメッセージは、エンドツーエンドに送信され、実験的なプロトコルをサポートしているサイト上のファイアウォールを通過する必要があるかもしれません。
Appendix B. Example Script to Configure ICMPv6 Firewall Rules
付録B.スクリプト例は、ICMPv6のファイアウォールルールを設定します
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のパケットフィルタリングシステムを使用している場合、この文書で提案されたルールのほとんどを実装するためのサンプルスクリプトが含まれています。 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
＃！/ binに/ファイアウォールの輸出INNER_PREFIXES =の信頼された（「内側」）側のプレフィックスのバッシュ＃セット「2001：DB8は：85 :: / 60」サービスを提供するホストの＃セット、彼らが行うことができるようにping可能輸出PINGABLE_HOSTS =「2001：DB8：85 :: / 64」＃設定オプション：だけ＃既存のセッションのために許容されるエラーがSTATE_ENABLED = 0＃コンフィギュレーションオプションをエクスポートする場合、これを1に変更します。メッセージへ/リンク＃ローカルアドレスからの場合は1に変更しフィルタ処理されなければなりません。 ＃ファイアウォールがブリッジである場合は、これを使用しないでください。 ＃ルータであるファイアウォールのためのオプション。輸出FILTER_LINK_LOCAL_ADDRS = 0＃設定オプション：サイトは＃モバイルIPv6ホームエージェントをサポートしていない場合は0に変更してください - 付録A.14輸出HOME_AGENTS_PRESENT = 1＃コンフィギュレーションオプションを参照してください。サイトは＃モバイルIPv6をサポートしていない場合は0に変更しモバイルノードは、サイト上に存在する - ＃は見付録A.14輸出MOBILE_NODES_PRESENT = 1
ip6tables -N icmpv6-filter ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
ip6tablesを-N ICMPv6のフィルタip6tablesを-A FORWARD -p ICMPv6の-jのICMPv6フィルタ
# 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@
srcと拒否し、他のdest＃の＃マッチ範囲は、この機能は、基本ip6tablesを機能＃でのためにそれをサポートすることが存在する拡張子（AGR）を提供されていません。 ＃@ 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にinner_prefixのためのサイトに属しているプレフィックスからのアウトバウンドエコー要求がip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型エコー要求が完了ACCEPT -jん許可
# 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フィルタ-p ICMPv6の-d $ pingable_host \ --icmpv6型エコー要求が完了ACCEPT -jで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"]であれば、その後＃のみ、既存のセッションは、ip6tablesを-AのICMPv6フィルタ-m状態-pのICMPv6 \ --state ESTABLISHED、RELATED --icmpv6型の着信と発信のエコー応答メッセージ＃を許可します\エコー応答は他の＃$ PINGABLE_HOSTSでpingable_hostのための着信と発信の両方のエコー応答がping可能ホストから＃発信エコー応答を行う許可ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ pingable_host \ --icmpv6型echo-をACCEPT -j ＃着信エコーが行わFiを提供してACCEPT -j $ INNER_PREFIXES DO ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-d $ inner_prefix \ --icmpv6型エコー応答でinner_prefixのためのサイトに属している接頭辞に返信-j返信を行ってACCEPT
# 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
ファイアウォールは、ルータがある場合は＃リンクローカルアドレス＃へ/からのICMPを拒否：ルータがなく、前方＃リンクローカルアドレスを確認する必要があるとして＃これらの規則は冗長でなければなりません...＃はこれらのルールを有効にしないファイアウォールがある場合[ "$ FILTER_LINK_LOCAL_ADDRS" -eq "1"]もし橋その後、ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-d FE80 :: / 10 -j DROP ip6tablesを-AのICMPv6フィルタ-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
DROP -j＃先ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-d FF00 :: / 8 \ --icmpv6型エコー応答として、マルチキャストアドレスを持つ＃ドロップエコー応答
# 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のための既存のセッションのために行うip6tablesを-AのICMPv6フィルタ-m状態-pのICMPv6 \ -d $ inner_prefix \ - 状態は、ESTABLISHED --icmpv6型\宛先到達不能に関連-j＃$ INNER_PREFIXES DO ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-d $ inner_prefix \ --icmpv6型先でinner_prefixの着信先到達不能メッセージを許可する他に行ってACCEPT -unreachable -j行わFiがACCEPT
# 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 DO ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型宛先到達不能にinner_prefixのために、発信先到達不能メッセージを許可する-j ACCEPT済
# 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」]の場合＃許可のみ行うip6tablesを-AのICMPv6フィルタ-m状態-pのICMPv6 \ $ INNER_PREFIXESで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 \ --state ESTABLISHED、RELATED \ --icmpv6型パケット余りに大きい\ -J $ INNER_PREFIXES DO ip6tablesを-AのICMPv6フィルタ-p ICMPv6の中inner_prefixのための＃許可の着信パケット過大メッセージ他に行わACCEPT -d $ inner_prefix \ --icmpv6型パケット余りに大きい-j Fiが行わACCEPT
# 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フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型パケット余りに大きいでinner_prefixのために、発信パケット過大メッセージを許可する-j ACCEPT済
# 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_PREFIXESでinner_prefixのための既存のセッションのためのコード0メッセージ＃行うip6tablesを-AのICMPv6フィルタ-m状態-pのICMPv6 \ -d $ inner_prefix \ ESTABLISHED、RELATED --icmpv6型パケット余りに大きい\を--state -j＃許可し、着信時には$ INNER_PREFIXES DO ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-d $ inner_prefix \にinner_prefixための0メッセージコードを超え、他で行わACCEPT --icmpv6型TTL-ゼロ時のトランジットは、Fiが行わACCEPT -j
#@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
＃@ POLICY @＃許可し、着信時には、$ INNER_PREFIXESでinner_prefixのための1つのメッセージは、ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-d $ inner_prefix \ --icmpv6型TTL-ゼロの間に、再組み立て完了ACCEPT -jないコードを上回りました
# 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 DO ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型TTL-ゼロ時の-トランジットが完了ACCEPT -jにinner_prefixための0メッセージコードを上回りました
#@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
＃@ POLICY @＃許可する送信時間は$ INNER_PREFIXESでinner_prefixのための1つのメッセージは、ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型TTL-ゼロの間に、再組み立て完了ACCEPT -jないコードを上回りました
# 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_PREFIXESでinner_prefixのための既存のセッションの着信パラメータ問題のコード1と2つのメッセージを＃行うip6tablesを-AのICMPv6フィルタ-m状態-pのICMPv6 \ -d $ inner_prefix \ --state ESTABLISHED、RELATED --icmpv6型未知のヘッダタイプが\ ip6tablesを-AのICMPv6フィルタ-m状態-pのICMPv6 \ -d $ inner_prefix \ --state ESTABLISHED、RELATEDをACCEPT -J \ \ - ICMPv6の型未知のオプションは\ Fiが行わACCEPT -j
# 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 \
＃送信パラメータ問題のコード1とコード$ INNER_PREFIXES DO ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型未知のヘッダタイプでinner_prefixのための2つのメッセージを許可する-j ip6tablesを-AのICMPv6フィルタをACCEPT -p ICMPv6の-s $ inner_prefix \
--icmpv6-type unknown-option -j ACCEPT done
--icmpv6型不明-オプションが行わACCEPT -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
＃@＃@政策は、ip6tablesをに-AのICMPv6フィルタ-p ICMPv6の\ --icmpv6型不良ヘッダー\ -J完了をACCEPTん着信と発信のパラメータ＃の問題のコードに$ INNER_PREFIXESでinner_prefixのための0メッセージを許可します
# 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
＃ドロップNS / NAメッセージの両方の着信および発信ip6tablesを-AのICMPv6フィルタ-p ICMPv6の\ --icmpv6型近隣勧誘-j DROP ip6tablesを-AのICMPv6フィルタ-p ICMPv6の\ --icmpv6型隣人 - 広告 - 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
＃ドロップRS / RAメッセージの着信と発信の両方ip6tablesを-AのICMPv6フィルタ-p ICMPv6の\ --icmpv6型ルータ勧誘-j DROP ip6tablesを-AのICMPv6フィルタ-p ICMPv6の\ --icmpv6型ルータ - 広告 - jはDROP
# Drop Redirect messages both incoming and outgoing ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP
＃ドロップリダイレクトメッセージの着信および発信の両方ip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型リダイレクト-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
＃ドロップ着信および発信＃マルチキャストリスナクエリ（のMLDv1とのMLDv2）ip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型130 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv1) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP
＃ドロップ着信および発信マルチキャストリスナレポート（のMLDv1）ip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型131 -j DROP
# Drop incoming and outgoing Multicast Listener Done messages (MLDv1) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP
＃着信および発信マルチキャストリスナーを削除完了メッセージ（のMLDv1）ip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型132 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv2) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP
＃ドロップ着信および発信マルチキャストリスナーレポート（MLDv2の）ip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型143 -j DROP
# ROUTER RENUMBERING MESSAGES
＃ルータリナンバリングMESSAGES
# ===========================
# Drop router renumbering messages ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP
＃ドロップルータリナンバリングメッセージip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型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
＃ドロップノード情報クエリ（139）と応答（140）ip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型139 -j DROP ip6tablesを-AのICMPv6フィルタ-p ICMPv6の--icmpv6型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
＃信頼される側に存在するモバイルIPv6ホームエージェントがある場合は＃$ INNER_PREFIXESでinner_prefixのために[「$のHOME_AGENTS_PRESENT」-eq「1」]場合、許可は、ホームエージェントアドレス発見要求が-AのICMPv6フィルタ-pのICMPv6をip6tablesを#incomingありませんモバイルプレフィックス要請ip6tablesをを#incoming ACCEPT -j #outgoingホームエージェントアドレス探索応答ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型145をACCEPT -j -d $ inner_prefix \ --icmpv6型144 -A ICMPv6のフィルタ-p ICMPv6の-d $ inner_prefix \ --icmpv6型146モバイルプレフィックスを#outgoing ACCEPT -j広告ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型147 ACCEPT -j行わ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 \
##信頼できる側に存在ローミング中の移動ノードがある場合は$ INNER_PREFIXESでinner_prefixのために[「$ MOBILE_NODES_PRESENT」-eq「1」]場合は、許可がホームエージェントアドレス発見要求を#outgoingんが-AのICMPv6フィルタ-pのICMPv6をip6tablesを - ホームエージェントアドレス探索応答ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-d $ inner_prefixを#incoming ACCEPT -j S $ inner_prefix \ --icmpv6型144 \
--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
モバイルプレフィックス広告ip6tablesを-AのICMPv6フィルタ-pを#incoming ACCEPT -jモバイルプレフィックス要請ip6tablesを-AのICMPv6フィルタ-p ICMPv6の-s $ inner_prefix \ --icmpv6型146を#outgoing ACCEPT -j --icmpv6型145 ICMPv6の-d $ inner_prefix \ --icmpv6型147完了Fiを提供してACCEPT -j
# DROP EVERYTHING ELSE
# ====================
ip6tables -A icmpv6-filter -p icmpv6 -j DROP
ip6tablesを-A ICMPv6のフィルタ-p ICMPv6の-j DROP
Example Netfilter Configuration Script for ICMPv6 Filtering
ICMPv6のフィルタリングのための例Netfilterの設定スクリプト
Authors' Addresses
著者のアドレス
Elwyn B. Davies Consultant Soham, Cambs UK
エルウィンB.デイヴィスコンサルタントソーハム、Cambsの英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Janos Mohacsi NIIF/HUNGARNET Victor Hugo u. 18-22 Budapest, H-1132 Hungary
ヤーノシュMohacsi NIIF / HUNGARNETヴィクトル・ユーゴーのu。 18-22ブダペスト、H-1132ハンガリー
Phone: +36 1 4503070 EMail: mohacsi@niif.hu
電話：+36 1 4503070 Eメール：mohacsi@niif.hu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。