Network Working Group P. Srisuresh
Request for Comments: 5508 Kazeon Systems
BCP: 148 B. Ford
Category: Best Current Practice MPI-SWS
S. Sivakumar
Cisco Systems
S. Guha
Cornell U.
April 2009
NAT Behavioral Requirements for ICMP
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols.
この文書は、インターネット制御メッセージプロトコル（ICMP）と連携して、ネットワークアドレス変換（NAT）デバイスで必要な行動のプロパティを指定します。このメモの目的は、NATデバイスは、より予測可能とデバイスを横断し、多様なアプリケーションプロトコルに対応することです。コンパニオン文書はTCP、UDP、およびその他のプロトコルに固有の行動の推奨事項を提供します。
Table of Contents
目次
1. Introduction and Scope ..........................................3
2. Terminology .....................................................4
3. ICMP Query Handling .............................................6
3.1. ICMP Query Mapping .........................................6
3.2. ICMP Query Session Timeouts ................................7
4. ICMP Error Forwarding ...........................................8
4.1. ICMP Error Payload Validation ..............................8
4.2. ICMP Error Packet Translation .............................10
4.2.1. ICMP Error Packet Received from the External Realm .11
4.2.2. ICMP Error Packet Received from the Private Realm ..13
4.3. NAT Sessions Pertaining to ICMP Error Payload .............15
5. Hairpinning Support for ICMP Packets ...........................16
6. Rejection of Outbound Flows Disallowed by NAT ..................17
7. Conformance to RFC 1812 ........................................17
7.1. IP Packet Fragmentation ...................................19
7.1.1. Generating "Packet Too Big" ICMP Error Message ....19
7.1.2. Forwarding "Packet Too Big" ICMP Error Message ....20
7.2. Time Exceeded Message .....................................20
7.3. Source Route Options ......................................20
7.4. Address Mask Request/Reply Messages .......................20
7.5. Parameter Problem Message .................................21
7.6. Router Advertisement and Solicitations ....................21
7.7. DS Field Usage ............................................21
8. Non-QueryError ICMP Messages ...................................22
9. Summary of Requirements ........................................22
10. Security Considerations .......................................25
11. Acknowledgements ..............................................26
12. References ....................................................27
12.1. Normative References .....................................27
12.2. Informative References ...................................27
As pointed out in RFC 3424 [UNSAF], NAT implementations vary widely in terms of how they handle different traffic. The purpose of this document is to define a specific set of requirements for NAT behavior with regard to ICMP messages. The objective is to reduce the unpredictability and brittleness the NAT devices (NATs) introduce. This document is an adjunct to [BEH-UDP], [BEH-TCP], and other protocol-specific BEHAVE document(s) in the future that define requirements for NATs when handling protocol-specific traffic.
[UNSAF] RFC 3424で指摘したように、NATの実装は、異なるトラフィックを処理する方法の面で大きく異なります。このドキュメントの目的は、ICMPメッセージに関してNAT行動のための要件の特定のセットを定義することです。目的は、NATデバイス（NATのが）を導入予測不可能性と脆弱性を軽減することです。この文書では、プロトコル固有のトラフィックを処理する際のNATのための要件を定義し、将来の[BEH-UDP]、[BEH-TCP]、及び他のプロトコル固有BEHAVE文書（複数可）の補助です。
The requirements of this specification apply to traditional NATs as described in [NAT-TRAD]. A traditional NAT has two variations, namely Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT is by far the most commonly deployed NAT device. NAPT allows multiple private hosts to share a single public IP address simultaneously.
[NAT-TRAD]に記載されているように、この仕様の要件は、従来のNATに適用されます。伝統的なNATは2つのバリエーション、つまり基本的なNATおよびネットワークアドレスポート翻訳（NAPT）を持っています。このうち、NAPTは、これまでで最も一般的に展開NATデバイスです。 NAPTは、複数のプライベートホストが同時に単一のパブリックIPアドレスを共有することができます。
This document only covers the ICMP aspects of NAT traversal, specifically the traversal of ICMP Query messages and ICMP Error messages. Traditional NAT inherently mandates firewall-like filtering behavior [BEH-UDP]. However, firewall functionality in general or any other middlebox functionality is out of the scope of this document.
この文書では、唯一のNATトラバーサル、ICMPクエリーメッセージとICMPエラーメッセージの具体的トラバーサルのICMPの側面をカバーしています。従来のNATは、本質的に、ファイアウォールのようなフィルタリングの挙動[BEH-UDP]を義務付け。しかし、一般的にファイアウォール機能やその他のミドルの機能は、この文書の範囲外です。
In some cases, ICMP message traversal behavior on a NAT device may be overridden by local administrative policies. Some administrators may choose to entirely prohibit forwarding of ICMP Error messages across a NAT device. Some others may choose to prohibit ICMP-Query-based applications across a NAT device. These are local policies and not within the scope of this document. For this reason, some of the ICMP requirements listed in the document are preceded with a constraint of local policy permitting.
いくつかのケースでは、NATデバイス上のICMPメッセージトラバーサルの動作は、ローカル管理ポリシーによって上書きすることができます。一部の管理者は完全にNATデバイス間でICMPエラーメッセージの転送を禁止することもできます。いくつかの他のものは、NATデバイス間でICMP-クエリベースのアプリケーションを禁止することもできます。これらは、この文書の範囲内のローカルポリシーとはありません。このため、文書に記載されているICMPの要件の一部を許可するローカルポリシーの制約で先行しています。
This document focuses strictly on the behavior of the NAT device, and not on the behavior of applications that traverse NATs. Application designers may refer to [BEH-APP] and [ICE] for recommendations and guidelines on how to make applications work robustly over NATs that follow the requirements specified here and the adjunct protocol-specific BEHAVE documents.
この文書では、厳密にNATデバイスの行動にではなく、NATのトラバースをアプリケーションの動作に焦点を当てています。アプリケーション設計者は、アプリケーションが、ここで指定された要件及び補助プロトコル固有BEHAVE文書に従ってNATを介して確実に動作させる方法に関する推奨事項とガイドラインのための[BEH-APP]および[ICE]を参照してもよいです。
Per [RFC1812], ICMP is a control protocol that is considered to be an integral part of IP, although it is architecturally layered upon IP -- it uses IP to carry its data end-to-end. As such, many of the ICMP behavioral requirements discussed in this document apply to all IP protocols.
それはIP上に層状アーキテクチャであるが[RFC1812]あたり、ICMPは、IPの不可欠な部分であると考えられている制御プロトコルである - それは、データのエンド・ツー・エンドを運ぶためにIPを使用します。そのため、このドキュメントで説明ICMP行動要件の多くは、すべてのIPプロトコルに適用されます。
In case a requirement in this document conflicts with protocol-specific BEHAVE requirement(s), protocol-specific BEHAVE documents will take precedence. The authors are not aware of any conflicts between this and any other IETF document at the time of this writing.
プロトコル固有のBEHAVE要件（S）と、この文書の競合における要件の場合には、プロトコル固有のBEHAVE文書が優先されます。著者は、この記事の執筆時点で、これと他のIETF文書との競合を認識していません。
Section 2 describes the terminology used throughout the document. Section 3 is focused on requirements concerning ICMP-Query-based applications traversing a NAT device. Sections 4 and 5 describe requirements concerning ICMP Error messages traversing a NAT device. Sections 6 describes requirements concerning ICMP Error messages generated by a NAT device. Section 7 reviews RFC 1812 conformance requirements and applicability to NATs when handling ICMP messages. Section 8 reviews a requirement for ICMP messages that are neither ICMP Query nor ICMP Error kind. Section 9 summarizes all the requirements in one place. Section 10 has a discussion on security considerations.
第2節では、文書全体で使用される用語について説明します。第3節では、NATデバイスを横断ICMP-クエリベースのアプリケーションに関する要件に焦点を当てています。セクション4および5は、NATデバイスを横断するICMPエラーメッセージに関する要件について説明します。セクション6は、NATデバイスによって生成されたICMPエラーメッセージに関する要件について説明します。 ICMPメッセージを処理するNATに第7件のRFC 1812の適合性要件と適用。第8節はどちらもICMPクエリやICMPエラーの一種であるICMPメッセージのための要件をレビュー。第9章は、一箇所ですべての要件をまとめたもの。セクション10には、セキュリティの考慮事項についての議論があります。
Definitions for the majority of the NAT terms used throughout the document may be found in [NAT-TERM] and [BEH-UDP].
文書全体を通して使用されるNAT用語の大部分の定義は、[NAT-TERM]と[BEH-UDP]に見出すことができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The term "Realm" is adapted from [NAT-TERM] and is defined as follows. "Realm" is often interchanged for "network domain" or simply "network" throughout the document.
「レルム」という用語は、[NAT-TERM]から適合されており、以下のように定義されます。 「レルム」は、多くの場合、文書全体で「ネットワークドメイン」または単に「ネットワーク」のために入れ替わっています。
Address realm or Realm - An address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. Note that this document is limited to describing NAT in the IPv4 environment and does not address the use of NAT in other types of environments (e.g., the IPV6 environment).
アドレスレルムまたはレルム - アドレスレルムは、ネットワークアドレスが一意のデータグラムがそれらにルーティングすることができるようなエンティティに割り当てられたネットワーク・ドメインです。ネットワークドメイン内で使用されるルーティングプロトコルは、ネットワークアドレス指定されたエンティティへのルートを見つけるための責任があります。この文書は、IPv4環境でNATを説明に限定されると環境の他のタイプ（例えば、IPv6環境）でNATを使用することに対処していないことに留意されたいです。
The term "NAT Session" is adapted from [NAT-MIB] and is defined as follows:
用語「NATセッションは、」[NAT-MIB]から適合されており、以下のように定義されます。
NAT Session - A NAT session is an association between a session as seen in the private realm and a session as seen in the public realm, by virtue of NAT translation. If a session in the private realm were to be represented as (PrivateSrcAddr, PrivateDstAddr, TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same session in the public realm were to be represented as (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the
NATセッション - NAT変換のおかげで、公共分野で見られるように、民間分野とのセッションで見られるようにNATのセッションは、セッションの間の関連付けです。民間分野でのセッションが（PrivateSrcAddr、PrivateDstAddr、TransportProtocol、PrivateSrcPort、PrivateDstPort）及び公共分野における同じセッションとして表現されるようにした場合（PublicSrcAddr、PublicDstAddr、TransportProtocol、PublicSrcPort、PublicDstPort）として表現されるようにして、
NAT session would provide the translation glue between the two session representations. NAT sessions in the document are restricted to sessions based on TCP, UDP, and ICMP. In the future, NAT sessions may be extended to be based on other transport protocols such as Stream Control Transmission Protocol (SCTP), UDP-lite, and Datagram Congestion Control Protocol (DCCP).
NATセッションは2つのセッション表現の間の変換接着剤を提供することになります。ドキュメント内のNATセッションはTCP、UDP、およびICMPに基づいてセッションに制限されています。将来的には、NATセッションは、ストリーム制御伝送プロトコル（SCTP）、UDP-Liteは、データグラム輻輳制御プロトコル（DCCP）などの他のトランスポートプロトコルに基づくように拡張することができます。
ICMP Message Classification - Section 3.2.2 of [RFC1122] and Section 4.3.1 of [RFC1812] broadly group ICMP messages into two main categories, namely "ICMP Query" messages and "ICMP Error" messages. All ICMP Error messages listed in RFC 1122 and RFC 1812 contain part of the Internet datagram that elicited the ICMP error. All the ICMP Query messages listed in RFC 1122 and RFC 1812 contain an "Identifier" field, which is referred to in this document as the "Query Identifier". There are however ICMP messages that do not fall into either of these two categories. We refer to them as "Non-QueryError ICMP Messages". All three ICMP message classes are described as follows:
ICMPメッセージ分類 - 2つの主なカテゴリ、即ち「ICMPクエリ」メッセージと「ICMPエラー」メッセージに[RFC1122]のセクション3.2.2及び[RFC1812]のセクション4.3.1広くグループICMPメッセージ。 RFC 1122およびRFC 1812に記載されているすべてのICMPエラーメッセージは、ICMPエラーを誘発し、インターネットデータグラムの一部が含まれています。 RFC 1122およびRFC 1812に記載されているすべてのICMPクエリメッセージは、「クエリ識別子」として、この文書で言及された「識別子」フィールドが含まれています。これらの二つのカテゴリーのいずれかに分類されないがICMPメッセージがあります。私たちは、「非QueryError ICMPメッセージ」としてそれらを参照してください。次のようにすべての3つのICMPメッセージクラスが説明されています。
o ICMP Query Messages - ICMP Query messages are characterized by an Identifier field in the ICMP header. The Identifier field used by the ICMP Query messages is also referred to as "Query Identifier" or "Query Id", for short throughout the document. A Query Id is used by Query senders and responders as the equivalent of a TCP/UDP port to identify an ICMP Query session. ICMP Query messages include ICMP messages defined after RFC 1122 or RFC 1812 (for example, Domain Name Request/Reply ICMP messages defined in RFC 1788), as they include request/response pairs and contain an "Identifier" field.
O ICMP Queryメッセージ - ICMPクエリーメッセージは、ICMPヘッダ内の識別子フィールドによって特徴付けられます。 ICMPクエリメッセージで使用される識別子フィールドは、文書全体に短いため、「問合せ識別子」または「クエリID」と呼ばれています。クエリIdはICMPクエリセッションを識別するために、TCP / UDPポートの同等のものとしてクエリーの送信者と対応者によって使用されます。これらは、要求/応答のペアを含み、「識別子」フィールドを含むようにICMP Queryメッセージは、（例えば、ドメイン名要求/ RFC 1788で定義されたICMPメッセージを返信）RFC 1122またはRFC 1812の後に定義されたICMPメッセージを含みます。
o ICMP Error Messages - ICMP Error messages provide signaling for IP. All ICMP Error messages are characterized by the fact that they embed the original datagram that triggered the ICMP Error message. The original datagram embedded within the ICMP Error payload is also referred to as the "Embedded packet" throughout the document. Unlike ICMP Query messages, ICMP Error messages do not have a Query Id in the ICMP header.
ICMPエラーメッセージ○ - ICMPエラーメッセージがIPのためのシグナリングを提供しています。すべてのICMPエラーメッセージは、それらがICMPエラーメッセージをトリガし、元のデータグラムを埋め込むことを特徴としています。 ICMPエラーペイロード内に埋め込まれたオリジナルのデータグラムは、文書全体を通じて「埋込みパケット」と呼ばれます。 ICMPクエリメッセージとは異なり、ICMPエラーメッセージは、ICMPヘッダ内のクエリIDを持っていません。
o Non-QueryError ICMP Messages - ICMP messages that do not fall under either of the above two classes are referred to as "Non-QueryError ICMP Messages" throughout the document. For example, Router Discovery ICMP messages [RFC1256] are "request/response" type ICMP messages. However, they are not characterized as ICMP Query messages in this document as they do not have an "Identifier" field within the messages. Likewise, there are other ICMP messages defined in [RFC4065] that do not fall in either of the ICMP Query or ICMP Error message categories, but will be referred to as Non-QueryError ICMP messages.
O非QueryError ICMPメッセージ - 上記二つのクラスのいずれかに該当しないICMPメッセージは、文書全体の「非QueryError ICMPメッセージ」と呼ばれています。例えば、Router DiscoveryのICMPメッセージ[RFC1256]は、 "要求/応答" タイプICMPメッセージです。彼らは、メッセージ内の「識別子」フィールドを持っていないしかし、彼らはこの文書のICMPクエリメッセージとして特徴付けられていません。同様に、ICMPクエリまたはICMPエラーメッセージのカテゴリのいずれにも該当しない[RFC4065]で定義された他のICMPメッセージはありますが、非QueryError ICMPメッセージと呼ぶことにします。
The reason for categorizing ICMP messages for NAT behavioral properties is that each category has different characteristics used for mapping (i.e., the Query Id and the Embedded datagram), which leaves the Non-QueryError ICMP messages in a separate, distinctive group.
NAT行動特性についてICMPメッセージを分類する理由は、各カテゴリは、別個の、独特のグループで非QueryError ICMPメッセージを残すマッピング（すなわち、クエリId及び埋め込みデータグラム）のために使用される異なる特性を有することです。
This section lists the behavioral requirements for a NAT device when processing ICMP Query packets. The following subsections discuss requirements specific to ICMP Query handling in detail.
ICMPクエリパケットを処理するときにこのセクションでは、NATデバイスのための行動の要件を示します。以下のサブセクションでは詳細に取り扱いICMPクエリに固有の要件を議論します。
Unless explicitly overridden by local policy, a NAT device MUST permit ICMP Queries and their associated responses, when the Query is initiated from a private host to the external hosts. ICMP Query mapping by NAT devices is necessary for current ICMP-Query-based applications to work. This entails a NAT device to transparently forward ICMP Query packets initiated from the nodes behind NAT, and the responses to these Query packets in the opposite direction. As specified in [NAT-TRAD], this requires translating the IP header. A NAPT device further translates the ICMP Query Id and the associated checksum in the ICMP header prior to forwarding.
明示的にローカルポリシーによって上書きされない限り、クエリは、外部のホストへのプライベートホストから開始された場合、NATデバイスは、ICMPクエリおよびそれらに関連する応答を許可する必要があります。現在のICMP-クエリベースのアプリケーションが動作するためにNATデバイスによって、ICMPクエリーマッピングが必要です。これは、ICMPクエリNATの背後にあるノードから開始されたパケット、および逆方向にこれらのクエリパケットへの応答透過的に転送するようにNATデバイスを必要とします。 [NAT-TRAD]で指定されるように、これは、IPヘッダを変換する必要があります。さらにNAPT装置は、ICMPクエリId及び転送する前にICMPヘッダ内の関連するチェックサムを変換します。
NAT mapping of ICMP Query Identifiers SHOULD be external-host independent. Say, an internal host A sent an ICMP Query out to an external host B using Query Id X. And, say, the NAT assigned this an external mapping of Query Id X' on the NAT's public address. If host A reused the Query Id X to send ICMP Queries to the same or different external host, the NAT device SHOULD reuse the same Query Id mapping (i.e., map the private host's Query Id X to Query Id X' on NAT's public IP address) instead of assigning a different mapping. This is similar to the "endpoint independent mapping" requirement specified in the TCP and UDP requirement documents [BEH-UDP], [BEH-TCP].
ICMPクエリ識別子のNATマッピングは、外部のホスト独立しているべきです。言って、内部ホストAは、クエリのId Xを使用して外部のホストBへ出ICMPクエリを送信し、たとえば、NATはNATのパブリックアドレスに「これにクエリ同上Xの外部のマッピングを割り当てました。ホストAは、同一または異なる外部ホストにICMPクエリを送信するために、クエリ同上Xを再利用する場合は、NATデバイスは、同じクエリIDマッピングを再利用すべきである（すなわち、NATのパブリックIPアドレスに同上X」を照会するためにプライベートホストのクエリ同上Xをマッピング）の代わりに異なるマッピングを割り当てます。これは、TCPとUDPの要件文書[BEH-UDP]、[BEH-TCP]に指定された「エンドポイントの独立したマッピング」の要件に似ています。
Below is justification for making the endpoint-independent mapping for ICMP Query Id a SHOULD [RFC2119] requirement. ICMP Ping [RFC1470] and ICMP traceroute [MS-TRCRT] are two most commonly known legacy applications built on top of ICMP Query messages. Neither of these applications require the ICMP Query Id to be retained across different sessions with external hosts. But, that may not be the case with future applications. In the future, when an end host application reuses the same Query Identifier in sessions with different target hosts, the end host application might require that the endpoint identity (i.e., the tuple of IP address and Query Identifier) appears the same across all its target hosts. In an IP network without NAT requirements, such a requirement will be valid.
以下ICMPクエリIDのエンドポイント非依存マッピングSHOULD [RFC2119]要件を製造するための正当化です。 ICMP Pingの[RFC1470]やICMPトレースルート[MS-TRCRT]はICMPクエリメッセージの上に構築された二つの最も一般的に知られているレガシーアプリケーションです。これらのアプリケーションのどちらも、外部のホストと異なるセッション間で保持されるようにICMPクエリIDが必要です。しかし、それは将来のアプリケーションの場合ではないかもしれません。エンドホストアプリケーションが異なるターゲットホストとのセッションで同じクエリ識別子を再利用し、将来、では、エンドホストアプリケーションは、エンドポイントのアイデンティティ（すなわち、IPアドレスおよびクエリ識別子のタプル）は、そのすべてのターゲットで同じ表示されていることを必要とするかもしれませんホスト。 NAT要件のないIPネットワークでは、そのような要件が有効になります。
In a world with NAT devices, the above assumption will be valid when NAT devices enforce endpoint mapping that is external-host independent. Given the dichotomy between legacy applications not requiring endpoint-independent mapping and future applications that might require it, the requirement level is kept at SHOULD [RFC2119].
NATデバイスは外部のホストに依存しないエンドポイントのマッピングを施行する場合、NATデバイスとの世界では、上記の仮定が有効となります。従来のエンドポイント非依存のマッピングを必要としないアプリケーションや、それを必要とするかもしれない将来のアプリケーション間の二分法を考えると、要求レベルがSHOULD [RFC2119]に保たれています。
REQ-1: Unless explicitly overridden by local policy, a NAT device MUST permit ICMP Queries and their associated responses, when the Query is initiated from a private host to the external hosts.
REQ-1：明示的にローカルポリシーによって上書きされない限り、クエリは、外部のホストへのプライベートホストから開始された場合、NATデバイスは、ICMPクエリおよびそれらに関連する応答を許可する必要があります。
a) NAT mapping of ICMP Query Identifiers SHOULD be external-
host independent.
NATs maintain a mapping timeout for the ICMP Queries that traverse them. The mapping timeout is the time a mapping will stay active without packets traversing the NAT. There is great variation in the values used by different NATs. The ICMP Query session timeout requirement is necessary for current ICMP Query applications to work. Query response times can vary. ICMP-Query-based applications are primarily request/response driven.
NATは、それらを通過するICMPクエリのマッピングのタイムアウトを維持します。マッピングのタイムアウトは、マッピングがNATを通過するパケットずにアクティブのままになる時間です。異なるNATので使用される値には大きなばらつきがあります。現在のICMPクエリアプリケーションが動作するためにICMPクエリーセッションタイムアウト要件が必要です。クエリの応答時間は変えることができます。 ICMP-クエリベースのアプリケーションは、主に、要求/応答を駆動しています。
Ideally, the timeout should be set to Maximum Round Trip Time (Maximum RTT). For the purposes of constraining the maximum RTT, the Maximum Segment Lifetime (MSL), defined in [RFC793], could be considered a guideline to set packet lifetime. Per [RFC793], MSL is the maximum amount of time a TCP segment can exist in a network before being delivered to the intended recipient. This is the maximum duration an IP packet can be assumed to take to reach the intended destination node before declaring that the packet will no longer be delivered. For an application initiating an ICMP Query message and waiting for a response for the Query, the Maximum RTT could in practice be constrained to be the sum total of MSL for the Query message and MSL for the response message. In other words, Maximum RTT could be constrained to no more than 2x MSL. The recommended value for MSL in [RFC793] is 120 seconds, even though several implementations set this to 60 seconds or 30 seconds. When MSL is 120 seconds, the Maximum RTT (2x MSL) would be 240 seconds.
理想的には、タイムアウトが最大ラウンドトリップ時間（RTT最大）に設定する必要があります。 [RFC793]で定義された最大RTT、最大セグメント寿命（MSL）を、拘束の目的のために、パケットの有効期間を設定するためのガイドラインと考えられます。 [RFC793]、MSLは、TCPセグメントが意図された受信者に配信される前に、ネットワーク内に存在することができる時間の最大量です。これは、IPパケットは、パケットが配信されなくなりますことを宣言する前に、目的の宛先ノードに到達するために取るように仮定することができる最大期間です。 ICMPクエリメッセージを開始し、クエリの応答を待っているアプリケーションの場合は、最大RTTは、実際には、応答メッセージのクエリメッセージとMSLのためのMSLの合計に制限することができます。言い換えれば、最大RTTは2倍MSLを超えないように制約することができます。 [RFC793]でMSLの推奨値は、いくつかの実装が60秒または30秒に設定しても、120秒です。 MSLは120秒である場合、最大RTT（2×MSL）は240秒であろう。
In practice, ICMP Ping [RFC1470] and ICMP traceroute [MS-TRCRT], the two most commonly known legacy applications built on top of ICMP Query messages, take less than 10 seconds to complete a round trip when the target node is operational on the network.
ターゲット・ノードがオン動作しているとき、実際には、ICMP Pingの[RFC1470]やICMPトレースルート[MS-TRCRT]、ICMPクエリーメッセージの上に構築された二つの最も一般的に知られているレガシーアプリケーションは、往復を完了するために10秒未満を取ります通信網。
Setting the ICMP NAT session timeout to a very large duration (say, 240 seconds) could potentially tie up precious NAT resources such as Query mappings and NAT Sessions for the whole duration. On the other hand, setting the timeout very low can result in premature freeing of NAT resources and applications failing to complete gracefully. The ICMP Query session timeout needs to be a balance between the two extremes. A 60-second timeout is a balance between the two extremes. An ICMP Query session timer MUST NOT expire in less than 60 seconds. It is RECOMMENDED that the ICMP Query session timer be made configurable.
非常に大規模な期間（たとえば、240秒）にICMP NATセッションタイムアウトを設定すると、潜在的に全期間のためにこのようなクエリのマッピングやNATのセッションなど、貴重なNATリソースをタイアップができます。一方、非常に低いタイムアウトを設定すると、正常に完了しなかっNATリソースとアプリケーションの早期解放をもたらす可能性があります。 ICMP問合せセッションタイムアウトは、両極端の間のバランスにする必要があります。 60秒のタイムアウトが両極端の間のバランスです。 ICMP問合せセッションタイマーは60秒未満で期限切れてはなりません。 ICMPクエリセッションタイマーが設定可能行われることが推奨されます。
REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 seconds.
REQ-2：ICMP問合せセッションタイマーは60秒未満で期限切れてはなりません。
a) It is RECOMMENDED that the ICMP Query session timer be made
configurable.
Many applications make use of ICMP Error messages from end hosts and intermediate devices to shorten application timeouts. Some applications will not operate correctly without the receipt of ICMP Error messages. The following sub-sections discuss the requirements a NAT device must conform to in order to ensure reliable forwarding.
多くのアプリケーションでは、アプリケーションのタイムアウトを短くするエンドホストとの中間デバイスからのICMPエラーメッセージを使用しています。一部のアプリケーションでは、ICMPエラーメッセージの受信せずに正常に動作しません。以下のサブセクションでは、NATデバイスが信頼できる転送を保証するためにに適合しなければならない要件を議論します。
An ICMP Error message checksum covers the entire ICMP message, including the payload. When an ICMP Error packet is received, if the ICMP checksum fails to validate, the NAT SHOULD silently drop the ICMP Error packet. This is because NAT uses the embedded IP and transport headers for forwarding and translating the ICMP Error message (described in Section 4.2). When the ICMP checksum is invalid, the embedded IP and transport headers, which are covered by the ICMP checksum, are also suspect.
ICMPエラーメッセージのチェックサムは、ペイロードを含む全体のICMPメッセージを、カバーしています。 ICMPエラーパケットを受信した場合、ICMPチェックサムが検証に失敗した場合、NATは静かにICMPエラーパケットを廃棄すべきです。 NATは、転送のために埋め込まれたIPとトランスポートヘッダを使用して（セクション4.2を参照）ICMPエラーメッセージを翻訳するためです。 ICMPチェックサムが無効である場合には、ICMPチェックサムでカバーされている埋め込まれたIPと輸送のヘッダーも、疑っています。
[RFC1812] and [RFC1122] require a router or an end host that receives an IP packet with an invalid IP header checksum to silently drop the IP packet. As such, end hosts and routers do not generate an ICMP Error message in response to IP packets with invalid IP header checksums. For this reason, if the IP checksum of the embedded packet within an ICMP Error message fails to validate, the NAT SHOULD silently drop the Error packet.
[RFC1812]及び[RFC1122]は静かにIPパケットをドロップするように無効なIPヘッダチェックサムとIPパケットを受信するルータまたはエンドホストを必要とします。このように、エンドホストとルータは無効なIPヘッダチェックサムとIPパケットに応答してICMPエラーメッセージを生成しません。 ICMPエラーメッセージ内に埋め込まれたパケットのIPチェックサムが検証に失敗した場合、このような理由から、NATは静かにエラーパケットを廃棄すべきです。
When the IP packet embedded within the ICMP Error message includes IP options, the NAT device must not assume that the transport header of the embedded packet is at a fixed offset (as would be the case when there are no IP options associated with the packet) from the start of the embedded packet. Specifically, if the embedded packet includes IP options, the NAT device MUST traverse past the IP options to locate the start of transport header for the embedded packet.
ICMPエラーメッセージ内に埋め込まれたIPパケットがIPオプションを含む場合、NATデバイスは、（パケットに関連付けられているIPオプションが存在しない場合場合のように）埋め込まれたパケットのトランスポートヘッダは固定オフセットであると仮定してはなりません埋め込まれたパケットの先頭から。埋め込まれたパケットは、IPオプションが含まれている場合、具体的に、NATデバイスは、埋め込まれたパケットのためにトランスポートヘッダの開始を見つけるためにIPオプションを越えて横断しなければなりません。
It is possible to compute the transport checksum of the embedded packet within an ICMP Error message when the ICMP Error message contains the entire transport segment. However, ICMP Error messages do not contain the entire transport segment in many cases. This is because [ICMP] stipulates that an ICMP Error message should embed an IP header and only a minimum of 64 bits of the IP payload. Even though Section 4.3.2.3 of [RFC1812] recommends an ICMP Error originator include as much of the original packet as possible in the payload, the length of the resulting ICMP datagram cannot exceed 576 bytes. ICMP Error originators truncate IP packets that do not fit within the stipulations.
ICMPエラーメッセージが全体輸送セグメントを含む場合には、ICMPエラーメッセージ内に埋め込まれたパケットの輸送チェックサムを計算することが可能です。しかし、ICMPエラーメッセージは、多くの場合、全体の輸送セグメントを含んでいません。 [ICMP]はICMPエラーメッセージは、IPヘッダとIPペイロードの64ビットの最低限を埋め込む必要があることを規定するからです。 [RFC1812]のセクション4.3.2.3は、ICMPエラー元を推奨していてもペイロードに可能な限り元のパケットの多くを含む、得られたICMPデータグラムの長さが576バイトを超えることはできません。 ICMPエラーオリジネーターは規定内に収まらないIPパケットを切り捨てます。
A NAT device SHOULD NOT validate the transport checksum of the embedded packet within an ICMP Error message, even when it is possible to do so. This is because a NAT dropping an ICMP Error message due to an invalid transport checksum will make it harder for end hosts to receive error reporting for certain types of corruption. End-to-end validation of ICMP Error messages is best left to end hosts. Many newer revision end host TCP/IP stacks implement the improvements in [TCP-SOFT] and do not accept ICMP Error messages with a mismatched IP or TCP checksum in the embedded packet, if the embedded datagram contains a full IP packet and the TCP checksum can be calculated.
NATデバイスは、そうすることが可能である場合でも、ICMPエラーメッセージの中に埋め込まれたパケットの転送チェックサムを検証すべきではありません。無効な輸送チェックサムにICMPエラーメッセージをドロップするNATは、それが困難エンドホストが破損の特定の種類のエラー報告を受信するために作るためです。 ICMPエラーメッセージのエンドツーエンドの検証では、最高のホストを終了するために残されています。多くの新しいリビジョンのエンドホストTCP / IPスタックは、[TCP-SOFT]の改善を実施し、埋め込まれたデータグラムが完全なIPパケットとTCPチェックサムが含まれている場合は、埋め込まれたパケット内の不一致IPやTCPチェックサムとICMPエラーメッセージを受け入れません計算することができます。
In the case that the ICMP Error payload includes ICMP extensions [ICMP-EXT], the NAT device MUST exclude the optional zero-padding and the ICMP extensions when evaluating transport checksum for the embedded packet. Readers are urged to refer to [ICMP-EXT] for information on identifying the presence of ICMP extensions in an ICMP message.
埋め込まれたパケットの転送チェックサムを評価する際にICMPエラーペイロードがICMP拡張[ICMP-EXT]を含む場合には、NATデバイスは、オプションのゼロパディングおよびICMP拡張を除外しなければなりません。読者は、ICMPメッセージにICMP拡張の存在を同定する方法については、[ICMP-EXT]を参照するように付勢されています。
REQ-3: When an ICMP Error packet is received, if the ICMP checksum fails to validate, the NAT SHOULD silently drop the ICMP Error packet. If the ICMP checksum is valid, do the following:
REQ-3：ICMPエラーパケットを受信した場合にICMPチェックサムが検証に失敗した場合、NATは静かにICMPエラーパケットを廃棄すべきです。 ICMPチェックサムが有効である場合は、次の手順を実行します。
a) If the IP checksum of the embedded packet fails to
validate, the NAT SHOULD silently drop the Error packet;
and
b) If the embedded packet includes IP options, the NAT device MUST traverse past the IP options to locate the start of the transport header for the embedded packet; and
埋め込まれたパケットは、IPオプションが含まれている場合b）は、NATデバイスは、埋め込まれたパケットのトランスポートヘッダの開始を見つけるためにIPオプションを越えて横断しなければなりません。そして
c) The NAT device SHOULD NOT validate the transport checksum of the embedded packet within an ICMP Error message, even when it is possible to do so; and
C）NATデバイスは、そうすることが可能である場合でも、ICMPエラーメッセージの中に埋め込まれたパケットの転送チェックサムを検証するべきではありません。そして
d) If the ICMP Error payload contains ICMP extensions [ICMP-EXT], the NAT device MUST exclude the optional zero-padding and the ICMP extensions when evaluating transport checksum for the embedded packet.
埋め込まれたパケットの転送チェックサムを評価するとき、D）ICMPエラーペイロードがICMP拡張[ICMP-EXT]を含んでいる場合、NATデバイスは、オプションのゼロパディングおよびICMP拡張を除外しなければなりません。
Section 4.3 of [NAT-TRAD] describes the fields of an ICMP Error message that a NAT device translates. In this section, we describe the requirements a NAT device must conform to while performing the translations. Requirements identified in this section are necessary for the current applications to work correctly.
[NAT-TRAD]のセクション4.3は、NATデバイスが変換ICMPエラーメッセージのフィールドについて説明します。このセクションでは、NATデバイスが変換を実行している間に適合しなければならない要件について説明します。現在のアプリケーションが正しく動作するために、このセクションで特定された要件が必要です。
Consider the following scenario in Figure 1. Say, NAT-xy is a NAT device connecting hosts in private and external networks. Router-x and Host-x are in the external network. Router-y and Host-y are in the private network. The subnets in the external network are routable from the private as well as the external domains. By contrast, the subnets in the private network are only routable within the private domain. When Host-y initiated a session to Host-x, let us say that the NAT device mapped the endpoint on Host-y into Host-y' in the external network. The following subsections describe the processing of ICMP Error messages on the NAT device(NAT-xy) when the NAT device receives an ICMP Error message in response to a packet pertaining to this session.
図1セイで次のシナリオを検討し、NAT-XYは、プライベートネットワークと外部ネットワーク内のホストを接続するNAT装置です。ルータ-xとホスト-xは、外部ネットワークです。ルータ-Yおよびホスト-yがプライベートネットワーク内にあります。外部ネットワーク内のサブネットは、プライベートだけでなく、外部ドメインからルーティング可能です。これとは対照的に、プライベートネットワーク内のサブネットはプライベートドメイン内でのみルーティング可能です。ホスト-yが-Xをホストするためにセッションを開始するとき、私たちはNATデバイスがホスト-Y」外部ネットワーク内にホストY上のエンドポイントをマッピングされたとしましょう。 NATデバイスは、このセッションに関連するパケットに応答してICMPエラーメッセージを受信した場合、次のサブセクションでは、NATデバイス（NAT-XY）上でICMPエラーメッセージの処理を記述する。
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
| ^
| | (Host-y', Host-x)
| |
+-------------+
| NAT-xy |
+-------------+
|
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
| ^
| | (Host-y, Host-x)
| |
Host-y
Figure 1. A Session from a Private Host Traversing a NAT Device
NATデバイスのトラバースプライベートホストから1. Aセッション図
Say, a packet from Host-y to Host-x triggered an ICMP Error message from one of Router-x or Host-x (both of which are in the external domain). Such an ICMP Error packet will have one of Router-x or Host-x as the source IP address and Host-y' as the destination IP address as described in Figure 2 below.
言い、-XをホストするホストYからのパケットは、（外部ドメインにある両方とも）ルータ-XまたはHost-Xの一方からICMPエラーメッセージをトリガー。以下の図2に記載されているようなICMPエラーパケットは、宛先IPアドレスと送信元IPアドレスとホスト-Y」としてルータ-XまたはHost-Xのいずれかを有することになります。
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
|
| | ICMP Error Packet to Host-y'
| v
+-------------+
| NAT-xy |
+-------------+
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
|
Host-y
Figure 2. ICMP Error Packet Received from External Network
図2. ICMPエラーパケットが外部ネットワークから受信しました
When the NAT device receives the ICMP Error packet, the NAT device uses the packet embedded within the ICMP Error message (i.e., the IP packet from Host-y' to Host-x) to look up the NAT Session to which the embedded packet belongs. If the NAT device does not have an active mapping for the embedded packet, the NAT SHOULD silently drop the ICMP Error packet. Otherwise, the NAT device MUST use the matching NAT Session to translate the embedded packet; that is, translate the source IP address of the embedded packet (e.g., Host-y' -> Host-y) and transport headers.
NATデバイスは、ICMPエラーパケットを受信すると、NATデバイスは、ICMPエラーメッセージの中に埋め込まれたパケットを使用しています（すなわち、からIPパケット-Xをホストするために「ホスト-Y）NATのセッションをルックアップするために埋め込まれたパケットが属します。 NATデバイスが組み込まれたパケットのためのアクティブ・マッピングを持っていない場合は、NATは静かにICMPエラーパケットを廃棄すべきです。それ以外の場合は、NATデバイスは、埋め込まれたパケットを変換するために一致するNATセッションを使用する必要があります。つまり、埋め込みパケットの送信元IPアドレスを変換する（例えば、ホスト-Y」 - >ホスト-y）及びトランスポート・ヘッダー。
The ICMP Error payload may contain ICMP extension objects [ICMP-EXT]. NATs are encouraged to support ICMP extension objects. At the time of this writing, the authors are not aware of any standard ICMP extension objects containing realm-specific information.
ICMPエラーペイロードはICMP拡張オブジェクト[ICMP-EXT]を含んでいてもよいです。 NATはICMP拡張オブジェクトをサポートすることをお勧めします。この記事の執筆時点では、著者は、レルム固有の情報を含む任意の標準的なICMP拡張オブジェクトを認識していません。
The NAT device MUST also use the matching NAT Session to translate the destination IP address in the outer IP header. In the outer header, the source IP address will remain unchanged because the originator of the ICMP Error message (Host-x or Router-x) is in an external domain and is routable from the private domain.
NATデバイスは、また、外側のIPヘッダ内の宛先IPアドレスを変換するために一致NATセッションを使用しなければなりません。 ICMPエラーメッセージ（ホストXまたはルータ-X）の発信者が外部ドメインにあり、プライベートドメインからルーティング可能であるので、外側のヘッダに、送信元IPアドレスが変更されないままであろう。
REQ-4: If a NAT device receives an ICMP Error packet from an external realm, and the NAT device does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy:
REQ-4：NATデバイスは、外部領域からICMPエラーパケットを受信し、NATデバイスは、埋め込みペイロードのアクティブ・マッピングがない場合、NATは静かICMPエラーパケットをドロップすべきです。 NATは、埋め込まれたペイロードのためのアクティブ・マッピングを持っている場合、NATの操作を行う必要があり、次の明示的にローカルポリシーによって上書きされない限り、パケットを転送する前に：
a) Revert the IP and transport headers of the embedded IP
packet to their original form, using the matching mapping;
and
b) Leave the ICMP Error type and code unchanged; and
b）は変わらないICMPエラーのタイプとコードを残します。そして
c) Modify the destination IP address of the outer IP header to be the same as the source IP address of the embedded packet after translation.
C）翻訳後の埋め込みパケットの送信元IPアドレスと同じになるように、外側IPヘッダの宛先IPアドレスを変更します。
Now, say, a packet from Host-x to Host-y triggered an ICMP Error message from one of Router-y or Host-y (both of which are in the private domain). Such an ICMP Error packet will have one of Router-y or Host-y as the source IP address and Host-x as the destination IP address as specified in Figure 3 below.
さて、-yとホスト間-Xからのパケットが（プライベートドメインにあるどちらも）ルータ-Yまたはホスト-YのいずれかからのICMPエラーメッセージをトリガし、言います。以下、図3で指定されるように、このようなICMPエラーパケットは、宛先IPアドレスと送信元IPアドレスとホストXとしてルータ-YまたはHost-Yのいずれかを有することになります。
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
|
|
+-------------+
| NAT-xy |
+-------------+
| ^
| | ICMP Error Packet to Host-x
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
|
Host-y
Figure 3. ICMP Error Packet Received from Private Network
図3. ICMPエラーパケットがプライベートネットワークから受信します
When the NAT device receives the ICMP Error packet, the NAT device MUST use the packet embedded within the ICMP Error message (i.e., the IP packet from Host-x to Host-y) to look up the NAT Session to which the embedded packet belongs. If the NAT device does not have an active mapping for the embedded packet, the NAT SHOULD silently drop the ICMP Error packet. Otherwise, the NAT device MUST use the matching NAT Session to translate the embedded packet.
NATデバイスは、ICMPエラーパケットを受信すると、NATデバイスは、埋め込まれたパケットが属するNATのセッションをルックアップするために（すなわち、ホスト-yとするホスト-XからのIPパケット）ICMPエラーメッセージの中に埋め込まれたパケットを使用しなければなりません。 NATデバイスが組み込まれたパケットのためのアクティブ・マッピングを持っていない場合は、NATは静かにICMPエラーパケットを廃棄すべきです。それ以外の場合は、NATデバイスは、埋め込まれたパケットを変換するために一致するNATセッションを使用する必要があります。
The ICMP Error payload may contain ICMP extension objects [ICMP-EXT]. NATs are encouraged to support ICMP extension objects. At the time of this writing, the authors are not aware of any standard ICMP extension objects containing realm-specific information.
ICMPエラーペイロードはICMP拡張オブジェクト[ICMP-EXT]を含んでいてもよいです。 NATはICMP拡張オブジェクトをサポートすることをお勧めします。この記事の執筆時点では、著者は、レルム固有の情報を含む任意の標準的なICMP拡張オブジェクトを認識していません。
In the outer header, the destination IP address will remain unchanged, as the IP address for Host-x is already in the external domain. If the ICMP Error message is generated by Host-y, the NAT device must simply use the NAT Session to translate the source IP address Host-y to Host-y'. If the ICMP Error message is originated by the intermediate node Router-y, translation of the source IP address varies depending on whether the Basic NAT or NAPT function [NAT-TRAD] is enforced by the NAT device. A NAT device enforcing the Basic NAT function has a pool of public IP addresses and enforces address mapping (which is different from the endpoint mapping enforced by NAPT) when a private node initiates an outgoing session via the NAT device. So, if the NAT device has active mapping for the IP address of the intermediate node Router-y, the NAT device MUST translate the source IP address of the ICMP Error packet with the public IP address in the mapping. In all other cases, the NAT device MUST simply use its own IP address in the external domain to translate the source IP address.
ホスト-xのIPアドレスが外部ドメインに既に存在するように、外側ヘッダに、宛先IPアドレスは、変更されないままであろう。 ICMPエラーメッセージがホストYによって生成されている場合は、NATデバイスは、単に「-yのホストへの送信元IPアドレス、ホスト-Yを変換するNATセッションを使用する必要があります。 ICMPエラーメッセージが中間ノードルータ-Yによって発信された場合に、送信元IPアドレスの変換は、基本的なNATまたはNAPT機能[NAT-TRAD]はNATデバイスによって実施されているかどうかに依存して変化します。基本的なNAT機能を強化NATデバイスは、パブリックIPアドレスのプールがあり、プライベート・ノードは、NATデバイスを介して、発信セッションを開始（NAPTによって強制エンドポイントマッピング異なる）アドレスマッピングを適用します。 NATデバイスは、中間ノードルータ-YのIPアドレスのアクティブ・マッピングを持っているのであれば、NATデバイスは、マッピング内のパブリックIPアドレスを持つICMPエラーパケットの送信元IPアドレスを変換する必要があります。他のすべての例では、NATデバイスは、単に元のIPアドレスを変換するために、外部ドメインに独自のIPアドレスを使用しなければなりません。
REQ-5: If a NAT device receives an ICMP Error packet from the private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy:
REQ-5：NATデバイスは、プライベート領域からのICMPエラーパケットを受信し、NATが埋め込まれたペイロードのアクティブ・マッピングを持っていない場合は、NATは静かにICMPエラーパケットを廃棄すべきです。 NATは、埋め込まれたペイロードのためのアクティブ・マッピングを持っている場合、NATの操作を行う必要があり、次の明示的にローカルポリシーによって上書きされない限り、パケットを転送する前に：
a) Revert the IP and transport headers of the embedded IP
packet to their original form, using the matching mapping;
and
b) Leave the ICMP Error type and code unchanged; and
b）は変わらないICMPエラーのタイプとコードを残します。そして
c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT has active mapping for the IP address that sent the ICMP Error, translate the source IP address of the ICMP Error packet with the public IP address in the mapping. In all other cases, translate the source IP address of the ICMP Error packet with its own public IP address.
C）NATはNATの基本的な機能（[NAT-TRAD]）施行、およびNATはでパブリックIPアドレスを持つICMPエラーパケットの送信元IPアドレスを変換し、ICMPエラーを送信されたIPアドレスのアクティブ・マッピングを持っている場合マッピング。他のすべてのケースでは、独自のパブリックIPアドレスを持つICMPエラーパケットの送信元IPアドレスを変換します。
While processing an ICMP Error packet pertaining to an ICMP Query or Query response message, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP Error packet. This is in spite of the fact that the NAT device uses the NAT Session to translate the embedded payload. This ensures that the NAT Session will not be modified if someone is able to spoof ICMP Error messages for the session. [ICMP-ATK] lists a number of potential ICMP attacks that may be attempted by malicious users on the network. This requirement is necessary for current applications to work correctly.
ICMPクエリまたはクエリ応答メッセージに関連するICMPエラーパケットを処理しながら、NATデバイスは、ICMPエラーパケット内に埋め込まれたペイロードに関連するNATのセッションを更新したり、削除してはなりません。これは、NATデバイスが組み込まれたペイロードを変換するNATセッションを使用しているという事実にもかかわらずです。これは、誰かがセッションのためにICMPエラーメッセージを偽装することができる場合NATのセッションは変更されないことを保証します。 [ICMP-ATK]は、ネットワーク上の悪意のあるユーザーによって試行される可能性がICMP攻撃の数が表示されます。現在のアプリケーションが正しく動作するためにこの要件が必要です。
REQ-6: While processing an ICMP Error packet pertaining to an ICMP Query or Query response message, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP Error packet.
REQ-6：ICMPクエリまたはクエリ応答メッセージに関連するICMPエラーパケットを処理しながら、NATデバイスは、ICMPエラーパケット内に埋め込まれたペイロードに関連するNATのセッションを更新したり、削除してはなりません。
[BEH-UDP] and [BEH-TCP] mandate support for hairpinning for UDP and TCP sessions, respectively, on NAT devices. A NAT device needs to support hairpinning for ICMP Query sessions as well. Specifically, NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the traversal of hairpinned ICMP Query sessions. Say, for example, individual private hosts register their NAT assigned external IP address with a rendezvous server. Other hosts that wish to initiate ICMP Query sessions to the registered hosts might do so using the public address registered with the rendezvous server. For this reason, Basic NAT devices are required to support the traversal of hairpinned ICMP Query sessions. This requirement is necessary for current applications to work correctly.
[BEH-UDP]やNATデバイス上で、それぞれ、UDPおよびTCPセッションのためにヘアピニングのための[BEH-TCP]任務をサポート。 NATデバイスは、同様にICMP問合せセッションのためのヘアピンをサポートする必要があります。具体的には、基本的なNAT [NAT-TRAD]を強制NATデバイスは、ヘアピンICMPクエリセッションのトラバーサルをサポートしなければなりません。例えば、個々のプライベートホストがランデブーサーバと彼らのNAT割り当てられた外部IPアドレスを登録し、言います。登録されたホストにICMPクエリセッションを開始することを希望する他のホストは、ランデブーサーバに登録されたパブリック・アドレスを使用して、そうかもしれません。このため、基本的なNATデバイスは、ヘアピンICMPクエリセッションのトラバースをサポートする必要があります。現在のアプリケーションが正しく動作するためにこの要件が必要です。
Packets belonging to any of the hairpinned sessions could, in turn, trigger ICMP Error messages directed to the source of hairpinned IP packets. Such hairpinned ICMP Error messages will traverse the NAT devices en route. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages. Specifically, the NAT device must translate not only the embedded hairpinned packet, but also the outer IP header that is hairpinned. This requirement is necessary for current applications to work correctly.
ヘアピンのセッションのいずれかに属するパケットは、順番に、ヘアピンIPパケットの送信元に向かうICMPエラーメッセージを引き起こす可能性があります。このようなヘアピンICMPエラーメッセージが途中でNATデバイスを横断します。すべてのNATデバイス（すなわち、基本NATと同様にNAPTデバイス）がヘアピンICMPエラーメッセージのトラバーサルをサポートしなければなりません。具体的には、NATデバイスは、埋め込まれたヘアピンパケットだけでなく、ヘアピン状である外側のIPヘッダだけでなく変換しなければなりません。現在のアプリケーションが正しく動作するためにこの要件が必要です。
A hairpinned ICMP Error message is received from a node in a private network. As such, the ICMP Error processing requirement specified in Req-5 is applicable in its entirety in processing the ICMP Error message. In addition, the NAT device MUST translate the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation.
ヘアピンICMPエラーメッセージは、プライベートネットワーク内のノードから受信されます。このように、REQ-5で指定されたICMPエラー処理要件は、ICMPエラーメッセージの処理中にその全体が適用可能です。また、NATデバイスは、外側IPヘッダの宛先IPアドレスが変換後の埋め込まれたIPパケットの送信元IPアドレスと同じになるように変換しなければなりません。
REQ-7: NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages:
REQ-7：基本的なNAT [NAT-TRAD]を強制NATデバイスはヘアピンICMPクエリセッションのトラバーサルをサポートしなければなりません。すべてのNATデバイス（すなわち、基本NATと同様にNAPTデバイス）がヘアピンICMPエラーメッセージのトラバーサルをサポートしなければなりません：
a) When forwarding a hairpinned ICMP Error message, the NAT
device MUST translate the destination IP address of the
outer IP header to be same as the source IP address of the
embedded IP packet after the translation.
A NAT device typically permits all outbound sessions. However, a NAT device may disallow some outbound sessions due to resource constraints or administration considerations. For example, a NAT device may not permit the first packet of a new outbound session if the NAT device is out of resources (out of addresses or TCP/UDP ports, or NAT Session resources) to set up a state for the session, or, if the specific session is administratively restricted by the NAT device.
NATデバイスは、典型的には、すべてのアウトバウンドセッションが可能になります。ただし、NATデバイスは、資源制約や行政の配慮のためにいくつかのアウトバウンドセッションを許可しないことがあります。例えば、NATデバイスは、NATデバイスがリソースのうちセッションの状態を設定する（アドレスやTCP / UDPポート、またはNATセッションリソース不足）であれば、新たなアウトバウンドセッションの最初のパケットを許可、またはしないことがあり、特定のセッションは管理NATデバイスによって制限されている場合。
When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet. This requirement is meant primarily for future use. Current applications do not require this for them to work correctly. The justification for using ICMP code 13 in the ICMP Error message is as follows: Section 5.2.7.1 of [RFC1812] recommends routers use ICMP code 13 (Communication administratively prohibited) when they administratively filter packets. ICMP code 13 is a soft error and is on par with other soft error codes generated in response to transient events such as "network unreachable" (ICMP type=3, code=0).
NATデバイスが新しいトランスポート層（TCP、UDP、ICMPなど）のためのNATのセッションを確立することができません場合は、コードで、NATデバイスは、ICMP宛先到達不能メッセージを送信する必要があります、原因資源の制約や管理の制約に流れます13の送信者に（通信が管理上禁止）、および元のパケットをドロップします。この要件は、主に、将来の使用のためのものです。それらが正しく動作するために、現在のアプリケーションでは、これを必要としません。次のようにICMPエラーメッセージにICMPコード13を使用するための正当化である：[RFC1812]のセクション5.2.7.1は、それらが管理パケットをフィルタリングするときにルータがICMPコード13（通信管理上禁止）を使用するお勧めします。 ICMPコード13は、ソフトエラーであり、そのような「ネットワーク到達不能」（ICMPタイプ= 3、コード= 0）のような過渡事象に応答して生成された他のソフトエラーコードと同等です。
Some NAT designers opt to never reject an outbound flow. When a NAT runs short of resources, they prefer to steal a resource from an existing NAT Session rather than reject the outbound flow. Such a design choice may appear conformant to REQ-8 below. However, the design choice is in violation of the spirit of both REQ-8 and REQ-2. Such a design choice is strongly discouraged.
いくつかのNATの設計者は、アウトバウンドフローを拒否したことがないことを選びます。 NATは、リソースの不足すると、彼らは既存のNATのセッションからリソースを盗むのではなく、アウトバウンドの流れを拒否することを好みます。このような設計上の選択は、REQ-8以下に準拠表示されることがあります。しかし、設計上の選択は、REQ-8とREQ-2の両方の精神に違反しています。このような設計上の選択を強くお勧めします。
REQ-8: When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet.
REQ-8：NATデバイスが新しいトランスポート層（TCP、UDP、ICMPなど）のためのNATのセッションを確立できない場合による資源の制約や管理の制約に流れ、NATデバイスは、ICMP宛先到達不能メッセージを送信する必要があります、13の符号を用いて送信者に（通信が管理上禁止）、および元のパケットをドロップします。
This document specifies NATs to have a behavior that is consistent with the way routers handle ICMP messages, as specified in Section 4.3 of [RFC1812]. However, since the publication of [RFC1812], some of its requirements are no longer best current practices. Thus, the following requirements are derived from [RFC1812] and apply to NATs compliant with this specification:
この文書では、[RFC1812]のセクション4.3で指定されたルータは、ICMPメッセージを処理する方法と一致して行動を持つようにするNATを指定します。ただし、[RFC1812]の出版以来、その要件のいくつかは、もはや現在のベストプラクティスではありません。したがって、以下の要件は[RFC1812]に由来し、この仕様に準拠のNATに適用されます。
REQ-9: A NAT device MAY implement a policy control that prevents ICMP messages being generated toward certain interface(s). Implementation of such a policy control overrides the MUSTs and SHOULDs in REQ-10.
REQ-9：NATデバイスは、特定のインタフェース（S）に向けて生成されたICMPメッセージを防止するポリシー・コントロールを実施することができます。そのようなポリシー制御の実装はREQ-10にマストとSHOULDsを上書きします。
REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to support ICMP messages as below, some conforming to Section 4.3 of [RFC1812] and some superseding the requirements of Section 4.3 of [RFC1812]:
REQ-10：REQ-9のポリシーによって上書きされない限り、NATデバイスは、いくつかは、[RFC1812]のセクション4.3に準拠し、いくつかは、[RFC1812]のセクション4.3の要件に取って代わる、以下のようにICMPメッセージをサポートする必要があります。
a. MUST support:
A。サポートしなければなりません：
1. Destination Unreachable Message, as described in Section 7.1 of this document.
このドキュメントのセクション7.1で説明したように1宛先到達不能メッセージ、。
2. Time Exceeded Message, as described in Section 7.2 of this document.
このドキュメントのセクション7.2で説明したように2時間は、メッセージを超えています。
b. MAY support:
B。サポートしてもよい（MAY）：
1. Redirect Message, as described in Section 4.3.3.2 of [RFC1812].
[RFC1812]のセクション4.3.3.2に記載されているように1、メッセージをリダイレクトします。
2. Timestamp and Timestamp Reply Messages, as described in Section 4.3.3.8 of [RFC1812].
[RFC1812]のセクション4.3.3.8に記載されるように前記タイムスタンプ及びタイムスタンプは、メッセージ返信。
3. Source Route Options, as described in Section 7.3 of this document.
3.ソースルートオプション、このドキュメントのセクション7.3で説明したように。
4. Address Mask Request/Reply Message, as described in Section 7.4 of this document.
このドキュメントのセクション7.4で説明したように4アドレスマスク要求/、メッセージを返信します。
5. Parameter Problem Message, as described in Section 7.5 of this document.
5.パラメータ問題メッセージを、このドキュメントのセクション7.5に記載されているように。
6. Router Advertisement and Solicitations, as described in Section 7.6 of this document.
前記ルータ広告と要請、このドキュメントのセクション7.6に記載されているように。
c. SHOULD NOT support:
C。サポートしないでください。
1. Source Quench Message, as described in Section 4.3.3.3 of [RFC1812].
1.ソースクエンチメッセージ、[RFC1812]のセクション4.3.3.3に記載されているように。
2. Information Request/reply, as described in Section 4.3.3.7 of [RFC1812].
2.情報要求/ [RFC1812]のセクション4.3.3.7に記載されているように、返信。
In addition, a NAT device is RECOMMENDED to conform to the following implementation considerations:
また、NATデバイスは、次の実装上の考慮事項に適合することをお勧めします。
d. DS Field Usage, as described in Section 7.7 of this document.
D。 DSフィールドの使用方法、このドキュメントのセクション7.7で説明したように。
e. When Not to Send ICMP Errors, as described in Section 4.3.2.7 of [RFC1812].
電子。 [RFC1812]のセクション4.3.2.7で説明したように、ICMPエラーを送信しないとき。
f. Rate Limiting, as described in Section 4.3.2.8 of [RFC1812].
F。 [RFC1812]のセクション4.3.2.8で説明したようにレート制限、。
Many networking applications (which include TCP- as well as UDP-based applications) depend on ICMP Error messages from the network to perform end-to-end path MTU discovery [PMTU]. Once the path MTU is discovered, an application that chooses to avoid fragmentation may do so by originating IP packets that fit within the path MTU en route and setting the DF (Don't Fragment) bit in the IP header, so the intermediate nodes en route do not fragment the IP packets. The following sub-sections discuss the need for NAT devices to honor the DF bit in the IP header and be able to generate "Packet Too Big" ICMP Error message when they cannot forward the IP packet without fragmentation. Also discussed is the need to seamlessly forward ICMP Error messages generated by other intermediate devices.
（TCP-ならびにUDPベースのアプリケーションを含む）多くのネットワークアプリケーションは、[PMTU]エンドツーエンドパスMTU探索を行うために、ネットワークからICMPエラーメッセージに依存します。パスMTUが発見されると、断片化を回避することを選択したアプリケーションは、専用の途中経路MTUに収まるようIPパケットを発信し、DF IPヘッダ内の（不フラグメントをDO）ビットので、中間ノードを設定することによってこれを行うことができますルートは、IPパケットを断片化していません。以下のサブセクションでは、NATデバイスは、IPヘッダにDFビットを尊重し、それらが断片化せずにIPパケットを転送することができないとき「パケット過大」ICMPエラーメッセージを生成することができるようにするための必要性を議論します。また、シームレスに他の中間デバイスによって生成されたICMPエラーメッセージを転送する必要性がある議論します。
When a router is unable to forward a datagram because it exceeds the MTU of the next-hop network and its Don't Fragment (DF) bit is set, the router is required by [RFC1812] to return an ICMP Destination Unreachable message to the source of the datagram, with the code indicating "fragmentation needed and DF set". Further, [PMTU] states that the router MUST include the MTU of that next-hop network in the low-order 16 bits of the ICMP header field that is labeled "unused" in the ICMP specification [ICMP].
それは次ホップネットワークのMTUを超え、そのないでくださいフラグメント（DF）ビットが設定され、ルータがにICMP宛先到達不能メッセージを返すために[RFC1812]によって必要とされるので、ルータは、データグラムを転送することができない場合「必要に応じて断片化とDFセット」を示すコードでデータグラムのソース、。さらに、[PMTU]ルータは、ICMP仕様で「未使用」とラベル付けされているICMPヘッダフィールドの下位16ビットにその次ホップネットワークのMTU [ICMP]を含まなければならないと述べています。
A NAT device MUST honor the DF bit in the IP header of the packets that transit the device. The NAT device may not be able to forward an IP packet without fragmentation if the MTU on the forwarding interface of the NAT device is not adequate for the IP packet. If the DF bit is set on a transit IP packet and the NAT device cannot forward the packet without fragmentation, the NAT device MUST send a "Packet Too Big" ICMP message (ICMP type 3, code 4) with the next-hop MTU back to the sender and drop the original IP packet. The sender will usually resend after taking the appropriate corrective action.
NATデバイスは、その中継装置のパケットのIPヘッダのDFビットを尊重しなければなりません。 NATデバイスの転送インターフェースのMTUは、IPパケットの適切でない場合、NATデバイスは、断片化せずにIPパケットを転送することができないかもしれません。 DFビットが通過IPパケットに設定され、NATデバイスは、断片化なしでパケットを転送することができない場合、NATデバイスは、ネクストホップMTUバックと「パケット過大」ICMPメッセージ（ICMPタイプ3、コード4）を送信しなければなりません送信者に、元のIPパケットをドロップします。送信者は通常、適切な是正措置を取った後再送信します。
If the DF bit is not set and the MTU on the forwarding interface of the NAT device mandates fragmentation, the NAT device MUST fragment the packet and forward the fragments [RFC1812].
DFビットがNATデバイス義務付け断片の転送インタフェース上に設定し、MTUされていない場合は、NATデバイスは、パケットを断片化し、断片[RFC1812]を転送する必要があります。
This is the flip side of the argument for the above section. By virtue of the address translation NAT performs, NAT may end up being the recipient of "Packet Too Big" messages.
これは、上記のセクションの引数のフリップ側です。 NATが実行するアドレス変換のおかげで、NATは「パケット過大」メッセージの受信者になってしまうことがあります。
When the NAT device is the recipient of a "Packet Too Big" ICMP message from the network, the NAT device MUST forward the ICMP message back to the intended recipient, pursuant to the previously stated requirements (REQ-3, REQ-4, and REQ-5).
NATデバイスは、ネットワークから「パケット過大」ICMPメッセージの受信者である場合、NATデバイスは、前述の要求（REQ-3、REQ-4に基づき、バック意図された受信者へICMPメッセージを転送しなければならない、そしてREQ-5）。
A NAT device MUST generate a "Time Exceeded" ICMP Error message when it discards a packet due to an expired Time to Live (TTL) field. A NAT device MAY have a per-interface option to disable origination of these messages on that interface, but that option MUST default to allowing the messages to be originated.
NATデバイスが原因Live（TTL）分野に有効期限が切れた時に、それは、パケットを破棄ICMPエラーメッセージを「超過時間」を発生させなければなりません。 NATデバイスは、そのインターフェイス上で、これらのメッセージの発信を無効にするインターフェイス単位のオプションを持っているかもしれませんが、そのオプションは、メッセージが発信できるようにすることをデフォルトとしなければなりません。
When a NAT device conforms to the above requirement, it ensures that legacy applications such as Traceroute [RFC1470], [MS-TRCRT], which depend upon the "Time Exceeded" ICMP Error message, will continue to operate even as NAT devices are en route.
NATデバイスは、上記の要件に適合するとき、このようなICMPエラーメッセージは、NATデバイスは、ENてもとして動作し続ける「時間超過」に依存するトレースルート[RFC1470]、[MS-TRCRT]、としてそのレガシーアプリケーションを確実にルート。
A NAT device MAY support modifying IP addresses in the source route option so the IP addresses in the source route option are realm relevant. If a NAT device does not support forwarding packets with the source route option, the NAT device SHOULD NOT forward outbound ICMP messages that contain the source route option in the outer or inner IP header. This is because such messages could reveal private IP addresses to the external realm.
NATデバイスは、ソースルートオプションでIPアドレス、レルム関連しているので、ソースルートオプションでIPアドレスを変更をサポートするかもしれません。 NATデバイスは、ソースルートオプションを使用してパケット転送をサポートしていない場合、NATデバイスは、外側又は内側のIPヘッダ内の送信元経路オプションを含むアウトバウンドICMPメッセージを転送すべきではありません。このようなメッセージは、外部のレルムにプライベートIPアドレスを明らかにする可能性があるためです。
Section 4.3.3.9 of [RFC1812] says an IP router MUST implement support for receiving ICMP Address Mask Request messages and responding with ICMP Address Mask Reply messages. However, several years (more than 13 years at the time of this document) have elapsed since the text in RFC 1812 was written. In the intervening time, DHCP [DHCP] has replaced the use of address mask request/reply. At the current time, there is rarely any host that does not meet host requirements [RFC1122] and needs a NAT device to support address mask request/reply.
[RFC1812]のセクション4.3.3.9は述べているIPルータはICMPアドレスマスク要求メッセージを受信し、ICMPアドレスマスク応答メッセージで応答するためのサポートを実装しなければなりません。しかし、数年（この文書の時点で13年以上）は、RFC 1812でテキストが書かれてから経過しました。介入時には、DHCP [DHCP]は、アドレスマスク要求/応答の使用を交換しました。現在の時点では、めったにホスト要件[RFC1122]に合致し、アドレスマスク要求/応答をサポートするNATデバイスを必要としない任意のホストはありません。
For this reason, a NAT device is not required to support this ICMP message.
このため、NATデバイスは、このICMPメッセージをサポートする必要はありません。
A NAT device MAY support address mask request/reply messages.
NATデバイスは、アドレスマスク要求/返信メッセージをサポートするかもしれません。
Section 4.3.3.5 of [RFC1812] says an IP router MUST generate a Parameter Problem message for any error not specifically covered by another ICMP message. However, this message is rarely used in practice in networks where IPv4 NATs are deployed.
[RFC1812]のセクション4.3.3.5は、IPルータは、特に別のICMPメッセージによってカバーされていないエラーのためのパラメータ問題メッセージを生成しなければならないと言います。しかし、このメッセージはほとんどのIPv4 NATのが配備されているネットワークで実際に使用されていません。
For this reason, a NAT device is not required to support this ICMP message.
このため、NATデバイスは、このICMPメッセージをサポートする必要はありません。
A NAT device MAY support parameter problem messages.
NATデバイスは、パラメータ問題メッセージをサポートするかもしれません。
Section 4.3.3.10 of [RFC1812] says an IP router MUST support the router part of the ICMP Router Discovery Protocol on all connected networks on which the router supports either IP multicast or IP broadcast addressing. However, this message is rarely used in practice in networks where IPv4 NATs are deployed.
[RFC1812]のセクション4.3.3.10は、IPルータは、ルータがIPアドレス指定マルチキャストまたはIPブロードキャストのいずれかをサポートしているすべての接続されたネットワーク上でICMPルーター検出プロトコルのルーターの一部をサポートしなければならないと言います。しかし、このメッセージはほとんどのIPv4 NATのが配備されているネットワークで実際に使用されていません。
For this reason, a NAT device is not required to support this ICMP message.
このため、NATデバイスは、このICMPメッセージをサポートする必要はありません。
A NAT device MAY support Router Advertisement and Solicitations.
NATデバイスは、ルータ広告や要請をサポートするかもしれません。
[RFC1812] refers to the Type of Service (TOS) octet in the IP header, which contains the TOS and IP precedence fields. However, the TOS and IP precedence fields are no longer in use today. [RFC2474] renamed the TOS octet as the DS field and defined diffserv classes within the DS field.
[RFC1812]はTOSとIP優先順位フィールドを含むIPヘッダ内のサービス（TOS）オクテットのタイプを指します。しかし、TOSおよびIP precedenceフィールドは使用されなくなっ今日ではありません。 [RFC2474]はDSフィールドとしてTOSオクテットの名前を変更し、DSフィールド内のDiffServクラスを定義しました。
When generating an ICMP message, a NAT device SHOULD copy the diffserv class of the message that causes the sending of the ICMP error message. A NAT device MAY allow configuration of the diffserv class to be used for the different types of ICMP messages.
ICMPメッセージを生成するとき、NATデバイスは、ICMPエラーメッセージの送信原因となるメッセージのDiffServクラスをコピーする必要があります。 NATデバイスは、DiffServクラスの構成はICMPメッセージの異なるタイプに使用されることを可能にします。
In the preceding sections, ICMP requirements were identified for NAT devices, with a primary focus on ICMP Query and ICMP Error messages, as defined in the Terminology Section (see Section 2). This document provides no guidance on the handling of Non-QueryError ICMP messages by the NAT devices. A NAT MAY drop or appropriately handle Non-QueryError ICMP messages.
用語セクション（セクション2を参照）で定義されるように前のセクションでは、ICMP要求は、ICMPクエリおよびICMPエラーメッセージの主な焦点と、NATデバイスのために同定されました。この文書では、NATデバイスによる非QueryError ICMPメッセージの取り扱いに関する一切のガイダンスを提供していません。 NATは、落としたり、適切に非QueryError ICMPメッセージを処理することができます。
REQ-11: A NAT MAY drop or appropriately handle Non-QueryError
ICMP messages. The semantics of Non-QueryError ICMP messages
is defined in Section 2.
Below is a summary of all the requirements.
下記のすべての要件の概要です。
REQ-1: Unless explicitly overridden by local policy, a NAT device MUST permit ICMP Queries and their associated responses, when the Query is initiated from a private host to the external hosts.
REQ-1：明示的にローカルポリシーによって上書きされない限り、クエリは、外部のホストへのプライベートホストから開始された場合、NATデバイスは、ICMPクエリおよびそれらに関連する応答を許可する必要があります。
a) NAT mapping of ICMP Query Identifiers SHOULD be external
host independent.
REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 seconds.
REQ-2：ICMP問合せセッションタイマーは60秒未満で期限切れてはなりません。
a) It is RECOMMENDED that the ICMP Query session timer be made
configurable.
REQ-3: When an ICMP Error packet is received, if the ICMP checksum fails to validate, the NAT SHOULD silently drop the ICMP Error packet. If the ICMP checksum is valid, do the following:
REQ-3：ICMPエラーパケットを受信した場合にICMPチェックサムが検証に失敗した場合、NATは静かにICMPエラーパケットを廃棄すべきです。 ICMPチェックサムが有効である場合は、次の手順を実行します。
a) If the IP checksum of the embedded packet fails to
validate, the NAT SHOULD silently drop the Error packet;
and
b) If the embedded packet includes IP options, the NAT device MUST traverse past the IP options to locate the start of the transport header for the embedded packet; and
埋め込まれたパケットは、IPオプションが含まれている場合b）は、NATデバイスは、埋め込まれたパケットのトランスポートヘッダの開始を見つけるためにIPオプションを越えて横断しなければなりません。そして
c) The NAT device SHOULD NOT validate the transport checksum of the embedded packet within an ICMP Error message, even when it is possible to do so; and
C）NATデバイスは、そうすることが可能である場合でも、ICMPエラーメッセージの中に埋め込まれたパケットの転送チェックサムを検証するべきではありません。そして
d) If the ICMP Error payload contains ICMP extensions [ICMP-EXT], the NAT device MUST exclude the optional zero-padding and the ICMP extensions when evaluating transport checksum for the embedded packet.
埋め込まれたパケットの転送チェックサムを評価するとき、D）ICMPエラーペイロードがICMP拡張[ICMP-EXT]を含んでいる場合、NATデバイスは、オプションのゼロパディングおよびICMP拡張を除外しなければなりません。
REQ-4: If a NAT device receives an ICMP Error packet from an external realm, and the NAT device does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy:
REQ-4：NATデバイスは、外部領域からICMPエラーパケットを受信し、NATデバイスは、埋め込みペイロードのアクティブ・マッピングがない場合、NATは静かICMPエラーパケットをドロップすべきです。 NATは、埋め込まれたペイロードのためのアクティブ・マッピングを持っている場合、NATの操作を行う必要があり、次の明示的にローカルポリシーによって上書きされない限り、パケットを転送する前に：
a) Revert the IP and transport headers of the embedded IP
packet to their original form, using the matching mapping;
and
b) Leave the ICMP Error type and code unchanged; and
b）は変わらないICMPエラーのタイプとコードを残します。そして
c) Modify the destination IP address of the outer IP header to be same as the source IP address of the embedded packet after translation.
C）外側のIPヘッダの宛先IPアドレスが変換後の埋め込みパケットの送信元IPアドレスと同じになるように変更します。
REQ-5: If a NAT device receives an ICMP Error packet from the private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy.
REQ-5：NATデバイスは、プライベート領域からのICMPエラーパケットを受信し、NATが埋め込まれたペイロードのアクティブ・マッピングを持っていない場合は、NATは静かにICMPエラーパケットを廃棄すべきです。 NATは、埋め込まれたペイロードのアクティブ・マッピングを持っている場合は、明示的にローカルポリシーによって上書きされない限り、その後、NATは、パケットを転送する前に、以下を行う必要があります。
a) Revert the IP and transport headers of the embedded IP
packet to their original form, using the matching mapping;
and
b) Leave the ICMP Error type and code unchanged; and
b）は変わらないICMPエラーのタイプとコードを残します。そして
c) If the NAT enforces Basic NAT function [NAT-TRAD], and the NAT has active mapping for the IP address that sent the ICMP Error, translate the source IP address of the ICMP Error packet with the public IP address in the mapping. In all other cases, translate the source IP address of the ICMP Error packet with its own public IP address.
NATはNATの基本的な関数[NAT-TRAD]を強制し、NATはICMPエラーを送信されたIPアドレスのアクティブ・マッピングを持っている場合c）に、マッピング内のパブリックIPアドレスを持つICMPエラーパケットの送信元IPアドレスを変換します。他のすべてのケースでは、独自のパブリックIPアドレスを持つICMPエラーパケットの送信元IPアドレスを変換します。
REQ-6: While processing an ICMP Error packet pertaining to an ICMP Query or Query response message, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP Error packet.
REQ-6：ICMPクエリまたはクエリ応答メッセージに関連するICMPエラーパケットを処理しながら、NATデバイスは、ICMPエラーパケット内に埋め込まれたペイロードに関連するNATのセッションを更新したり、削除してはなりません。
REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages.
REQ-7：基本NAT（[NAT-TRAD]）を強制NATデバイスはヘアピンICMPクエリセッションのトラバーサルをサポートしなければなりません。すべてのNATデバイス（すなわち、基本NATと同様にNAPTデバイス）がヘアピンICMPエラーメッセージのトラバーサルをサポートしなければなりません。
a) When forwarding a hairpinned ICMP Error message, the NAT
device MUST translate the destination IP address of the
outer IP header to be same as the source IP address of the
embedded IP packet after the translation.
REQ-8: When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet.
REQ-8：NATデバイスが新しいトランスポート層（TCP、UDP、ICMPなど）のためのNATのセッションを確立できない場合による資源の制約や管理の制約に流れ、NATデバイスは、ICMP宛先到達不能メッセージを送信する必要があります、13の符号を用いて送信者に（通信が管理上禁止）、および元のパケットをドロップします。
REQ-9: A NAT device MAY implement a policy control that prevents ICMP messages being generated toward certain interface(s). Implementation of such a policy control overrides the MUSTs and SHOULDs in REQ-10.
REQ-9：NATデバイスは、特定のインタフェース（S）に向けて生成されたICMPメッセージを防止するポリシー・コントロールを実施することができます。そのようなポリシー制御の実装はREQ-10にマストとSHOULDsを上書きします。
REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to support ICMP messages as below, some conforming to Section 4.3 of [RFC1812] and some superseding the requirements of Section 4.3 of [RFC1812]:
REQ-10：REQ-9のポリシーによって上書きされない限り、NATデバイスは、いくつかは、[RFC1812]のセクション4.3に準拠し、いくつかは、[RFC1812]のセクション4.3の要件に取って代わる、以下のようにICMPメッセージをサポートする必要があります。
a. MUST support:
A。サポートしなければなりません：
1. Destination Unreachable Message, as described in Section 7.1 of this document.
このドキュメントのセクション7.1で説明したように1宛先到達不能メッセージ、。
2. Time Exceeded Message, as described in Section 7.2 of this document.
このドキュメントのセクション7.2で説明したように2時間は、メッセージを超えています。
b. MAY support:
B。サポートしてもよい（MAY）：
1. Redirect Message, as described in Section 4.3.3.2 of [RFC1812].
[RFC1812]のセクション4.3.3.2に記載されているように1、メッセージをリダイレクトします。
2. Timestamp and Timestamp Reply Messages, as described in Section 4.3.3.8 of [RFC1812].
[RFC1812]のセクション4.3.3.8に記載されるように前記タイムスタンプ及びタイムスタンプは、メッセージ返信。
3. Source Route Options, as described in Section 7.3 of this document.
3.ソースルートオプション、このドキュメントのセクション7.3で説明したように。
4. Address Mask Request/Reply Message, as described in Section 7.4 of this document.
このドキュメントのセクション7.4で説明したように4アドレスマスク要求/、メッセージを返信します。
5. Parameter Problem Message, as described in Section 7.5 of this document.
5.パラメータ問題メッセージを、このドキュメントのセクション7.5に記載されているように。
6. Router Advertisement and Solicitations, as described in Section 7.6 of this document.
前記ルータ広告と要請、このドキュメントのセクション7.6に記載されているように。
c. SHOULD NOT support:
C。サポートしないでください。
1. Source Quench Message, as described in Section 4.3.3.3 of [RFC1812].
1.ソースクエンチメッセージ、[RFC1812]のセクション4.3.3.3に記載されているように。
2. Information Request/reply, as described in Section 4.3.3.7 of [RFC1812].
2.情報要求/ [RFC1812]のセクション4.3.3.7に記載されているように、返信。
In addition, a NAT device is RECOMMENDED to conform to the following implementation considerations:
また、NATデバイスは、次の実装上の考慮事項に適合することをお勧めします。
d. DS Field Usage, as described in Section 7.7 of this document.
D。 DSフィールドの使用方法、このドキュメントのセクション7.7で説明したように。
e. When Not to Send ICMP Errors, as described in Section 4.3.2.7 of [RFC1812].
電子。 [RFC1812]のセクション4.3.2.7で説明したように、ICMPエラーを送信しないとき。
f. Rate Limiting, as described in Section 4.3.2.8 of [RFC1812].
F。 [RFC1812]のセクション4.3.2.8で説明したようにレート制限、。
REQ-11: A NAT MAY drop or appropriately handle Non-QueryError ICMP messages. The semantics of Non-QueryError ICMP messages is defined in Section 2.
REQ-11：NATは、落としたり、適切に非QueryError ICMPメッセージを処理することができます。非QueryError ICMPメッセージの意味は、第2節で定義されています。
This document does not introduce any new security concerns related to ICMP message handling in the NAT devices. However, the requirements in the document do mitigate some security concerns known to exist with ICMP messages.
この文書では、NATデバイスの取り扱いICMPメッセージに関連する新しいセキュリティの懸念を導入しません。しかし、文書の要件は、ICMPメッセージで存在することが知られているいくつかのセキュリティ上の懸念を軽減します。
[ICMP-ATK] lists a number of ICMP attacks that can be directed against end host TCP stacks. For example, a rogue entity could bombard the NAT device with a large number of ICMP Errors. If the NAT device did not validate the legitimacy of the ICMP Error packets, the ICMP Errors would be forwarded directly to the end nodes. End hosts not capable of defending themselves against such bogus ICMP Error attacks could be adversely impacted by such attacks. Req-3 recommends validating the ICMP checksum and the IP checksum of the embedded payload prior to forwarding. These checksum validations by themselves do not protect end hosts from attacks. However, checksum validation mitigates end hosts from malformed ICMP Error attacks. Req-4 and Req-5 further mandate that when a NAT device does not find a mapping selection for the embedded payload, the NAT should drop the ICMP Error packets, without forwarding.
[ICMP-ATK]は、エンドホストTCPスタックに対して向けることができるICMP攻撃の数が表示されます。例えば、不正なエンティティは、ICMPエラーの数が多いNATデバイスに衝突可能性があります。 NATデバイスは、ICMPエラーパケットの正当性を検証していない場合は、ICMPエラーは、エンドノードに直接転送されます。そのような偽のICMPエラー攻撃から身を守ることができないエンドホストに悪影響ような攻撃の影響を受ける可能性があります。 REQ-3は、ICMPチェックサムと転送する前に埋め込まれたペイロードのIPチェックサムを検証することをお勧めします。それだけでこれらのチェックサムの検証が攻撃からエンドホストを保護しません。しかし、チェックサムの検証が不正なICMPエラー攻撃からエンドホストを軽減します。 REQ-4及びNAT装置が埋め込まれたペイロードのマッピングの選択が見つからない場合、NATは転送せずに、ICMPエラーパケットをドロップする必要があることをREQ-5さらに委任。
A rogue source could also try to send bogus ICMP Error messages for the active NAT sessions, with intent to destroy the sessions. Req-6 averts such an attack by ensuring that an ICMP Error message does not affect the state of a session on the NAT device.
不正なソースも、セッションを破壊する目的で、アクティブなNATセッションのために偽のICMPエラーメッセージを送信しようとすることができます。 REQ-6は、ICMPエラーメッセージがNATデバイス上のセッションの状態には影響しないことを確実にすることによって、このような攻撃をaverts。
Req-8 recommends a NAT device sending an ICMP Error message when the NAT device is unable to create a NAT session due to lack of resources. Some administrators may choose not to have the NAT device send an ICMP Error message, as doing so could confirm to a malicious attacker that the attack has succeeded. For this reason, sending of the specific ICMP Error message stated in REQ-8 is left to the discretion of the NAT device administrator.
REQ-8は、NATデバイスがリソース不足のためNATセッションを作成することができないとき、ICMPエラーメッセージを送信するNATデバイスを推奨しています。一部の管理者は、NATデバイスは、攻撃が成功したことを、悪意のある攻撃者に確認することができそうとして、ICMPエラーメッセージを送信していないのを選ぶかもしれません。このため、特定のICMPエラーメッセージの送信は、NATデバイスの管理者の裁量に任されているREQ-8で述べました。
Unfortunately, ICMP messages are sometimes blocked at network boundaries due to local security policy. Thus, some of the requirements in this document allow local policy to override the recommendations of this document. Blocking such ICMP messages is known to break some protocol features (most notably path MTU Discovery) and some applications (e.g., ping, traceroute), and such blocking is NOT RECOMMENDED.
残念ながら、ICMPメッセージは時々ローカルセキュリティポリシーによるネットワーク境界でブロックされています。したがって、この文書の要件の一部は、ローカルポリシーは、この文書の勧告を上書きすることができます。このようなICMPメッセージをブロックすることは、いくつかのプロトコル機能（特にパスMTUディスカバリ）およびいくつかのアプリケーション（例えば、ピング、トレースルート）を破壊することが知られており、このようなブロッキングは推奨されません。
The authors wish to thank Fernando Gont, Dan Wing, Carlos Pignataro, Philip Matthews, and members of the BEHAVE working group for doing a thorough review of early versions of the document and providing valuable input and offering generous amounts of their time in shaping the ICMP requirements. Their valuable feedback made this document a better read. Dan Wing and Fernando Gont were a steady source of encouragement. Fernando Gont spent many hours preparing slides and presenting the document in an IETF meeting on behalf of the authors. The authors wish to thank Carlos Pignataro and Dan Tappan, authors of the [ICMP-EXT] document, for their feedback concerning ICMP extensions. The authors wish to thank Philip Matthews for agreeing to be a technical reviewer for the document. Lastly, the authors highly appreciate the rigorous feedback from the IESG members.
著者は、ICMPを形成する上で、文書の初期バージョンの徹底的な見直しを行うと、貴重な入力を提供し、彼らの時間の寛大な量を提供するためのフェルナンドGont、ダン・ウィング、カルロスPignataro、フィリップ・マシューズ、およびBEHAVEワーキンググループのメンバーに感謝したいです要件。彼らの貴重なフィードバックは、この文書をより良い読み取りを行いました。ダン・ウィングとフェルナンドGontは励ましの安定した供給源でした。フェルナンドGontは、スライドを準備し、著者に代わってIETF会議で文書を提示する多くの時間を費やしました。著者は、ICMPの拡張に関する彼らのフィードバックのために、カルロス・Pignataroとダンタッパン、[ICMP-EXT]文書の作成者に感謝したいです。著者は、文書のための技術的審査することに同意するためにフィリップ・マシューズに感謝したいです。最後に、著者は非常にIESGメンバーから厳しいフィードバックを感謝しています。
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[BEH-UDP] Audet、F.、エド。、およびC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[ICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMP]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[ICMP-EXT] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[ICMP-EXT] Bonica、R.、ガン、D.、タッパン、D.、およびC. Pignataro、RFC 4884、2007年4月 "拡張ICMPマルチパートメッセージをサポートするために"。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[BEH-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
[BEH-APP]フォード、B.、Srisuresh、P.、およびD.ケーゲル、 "トラバーサルのためのアプリケーション設計ガイドラインネットワークを介して、翻訳者住所"、進歩、2007年3月に仕事を。
[BEH-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[BEH-TCP]グハ、S.編、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNAT行動要件"、BCP 142、RFC 5382、2008年10月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書」、進歩、2007年10月の作業。
[ICMP-ATK] Gont, F., "ICMP Attacks against TCP", Work in Progress, October 2008.
[ICMP-ATK] Gont、F.、 "TCPに対するICMP攻撃"、進歩、2008年10月の作業。
[MS-TRCRT] Microsoft Support, "How to use the Tracert command-line utility to troubleshoot TCP/IP problems in Windows", http://support.microsoft.com/kb/162326, October, 2006.
[MS-TRCRT]マイクロソフトのサポート、http://support.microsoft.com/kb/162326、2006年10月の "WindowsでのTCP / IPの問題をトラブルシューティングするためにtracertのコマンドラインユーティリティを使用する方法"。
[NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
[NAT-MIB]のRohit、R.、Srisuresh、P.、Raghunarayan、R.、パイ、N.、およびC.王、2005年3月、RFC 4008 "ネットワークのための管理オブジェクトの定義は、翻訳者（NAT）をアドレス"。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[PMTU]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]デアリング、S.、エド。、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", FYI 2, RFC 1470, June 1993.
"ネットワーク管理ツールカタログ上のFYI：監視するためのツールおよびデバッグTCP / IPインターネットおよび相互接続されたデバイス" [RFC1470]エンガー、R.とJ.レイノルズ、FYI 2、RFC 1470、1993年6月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4065]ケンプ、J.、RFC 4065、2005年7月 "Seamobyと実験モビリティプロトコルのIANAの割り当てのための手順"。
[TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[TCP-SOFT] Gont、F.、 "ソフトエラーへのTCPの反応"、RFC 5461、2009年2月。
[UNSAF] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF] Daigle氏、L.、エド。、およびIAB、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定（UNSAF）のためのIABの考慮事項"、RFC 3424、2002年11月。
Authors' Addresses
著者のアドレス
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A.
Pyda Srisuresh Kazeon Systems、Inc.の1161年サンアントニオRdを。マウンテンビュー、CA 94043 U.S.A.
Phone: +1 408 836 4773 EMail: srisuresh@yahoo.com
電話：+1 408 836 4773 Eメール：srisuresh@yahoo.com
Bryan Ford Max Planck Institute for Software Systems Campus Building E1 4 D-66123 Saarbruecken Germany
ソフトウェアシステムのブライアン・フォードマックスプランク研究所キャンパスビルE1 4 D-66123ザールブリュッケンドイツ
Phone: +49-681-9325657 EMail: baford@mpi-sws.org
電話：+ 49-681-9325657 Eメール：baford@mpi-sws.org
Senthil Sivakumar Cisco Systems, Inc. 7100-8 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709-4987 U.S.A.
Senthilさんシバクマーシスコ・システムズ・インク7100から8キットクリーク道路私書箱14987リサーチトライアングルパーク、ノースカロライナ州27709から4987 U.S.A.
Phone: +1 919 392 5158 EMail: ssenthil@cisco.com
電話：+1 919 392 5158 Eメール：ssenthil@cisco.com
Saikat Guha Cornell University 331 Upson Hall Ithaca, NY 14853 U.S.A.
Saikatグハコーネル大学331アップソンホールイサカ、NY 14853 U.S.A.
Phone: +1 607 255 1008 EMail: saikat@cs.cornell.edu
電話：+1 607 255 1008 Eメール：saikat@cs.cornell.edu