[要約] RFC 5508は、ICMPのNATの動作要件に関するガイドラインです。その目的は、NAT環境で正確なICMPメッセージの処理と転送を確保することです。
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
ICMPのNAT行動要件
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
RFC 3424 [UNSAF]で指摘されているように、NATの実装は、さまざまなトラフィックをどのように処理するかという点で大きく異なります。このドキュメントの目的は、ICMPメッセージに関するNATの動作の特定の要件セットを定義することです。目的は、NATデバイス（NAT）が導入する予測不可能性と脆性を減らすことです。このドキュメントは、プロトコル固有のトラフィックを処理する際にNATの要件を定義する将来、[Beh-udp]、[beh-tcp]、およびその他のプロトコル固有の行動ドキュメントの補助です。
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には、基本的なNATとネットワークアドレスポート翻訳者（NAPT）の2つのバリエーションがあります。これらのうち、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デバイスの動作に厳密に焦点を当てています。アプリケーション設計者は、ここで指定された要件と補助プロトコル固有の行動文書に従う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.
[RFC1812]によると、ICMPはIPの不可欠な部分と見なされるコントロールプロトコルですが、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.
このドキュメントの要件がプロトコル固有の行動要件と競合する場合、プロトコル固有の行動ドキュメントが優先されます。著者は、この執筆時点で、これと他の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エラーメッセージに関する要件について説明します。セクション7では、RFC 1812 ICMPメッセージを処理する際のNATへの適合要件と適用性を確認します。セクション8では、ICMPクエリでもICMPエラーの種類でもないICMPメッセージの要件を確認します。セクション9では、すべての要件を1つの場所にまとめます。セクション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 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セッション - NATセッションは、プライベートレルムで見られるセッションと、NAT翻訳のおかげで公共の領域で見られるセッションとの関連です。プライベートレルムのセッションが（privateRcaddr、privatedStaddr、transportprotocol、privatesrcport、privatedstport）として表され、公共領域の同じセッションが（publicsrcaddr、publicdstaddr、TransportProtocol、publicsrcport、publicdstport）として表現される場合。セッションは、2つのセッション表現間の翻訳接着剤を提供します。ドキュメントのNATセッションは、TCP、UDP、およびICMPに基づくセッションに制限されています。将来的には、NATセッションは、ストリーム制御伝送プロトコル（SCTP）、UDP-LITE、およびDatagram輻輳制御プロトコル（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メッセージ分類 - [RFC1122]のセクション3.2.2および[RFC1812]のセクション4.3.1は、ICMPメッセージを2つの主要なカテゴリ、つまり「ICMPクエリ」メッセージと「ICMPエラー」メッセージに広くグループ化します。RFC 1122およびRFC 1812にリストされているすべてのICMPエラーメッセージには、ICMPエラーを誘発するインターネットデータグラムの一部が含まれています。RFC 1122およびRFC 1812にリストされているすべてのICMPクエリメッセージには、このドキュメントで「クエリ識別子」と呼ばれる「識別子」フィールドが含まれています。ただし、これら2つのカテゴリのいずれにも分かれない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クエリメッセージ-ICMPクエリメッセージは、ICMPヘッダーの識別子フィールドによって特徴付けられます。ICMPクエリメッセージで使用される識別子フィールドは、ドキュメント全体で略して「クエリ識別子」または「クエリID」とも呼ばれます。クエリIDは、クエリ送信者とレスポンダーがTCP/UDPポートに相当するものとして使用して、ICMPクエリセッションを識別します。ICMPクエリメッセージには、RFC 1122またはRFC 1812の後に定義されたICMPメッセージ（たとえば、ドメイン名要求/RFC 1788で定義された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.
o 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メッセージ-上記の2つのクラスのいずれかに該当しないICMPメッセージは、ドキュメント全体で「QueryError ICMPメッセージ以外のICMPメッセージ」と呼ばれます。たとえば、ルーター発見ICMPメッセージ[RFC1256]は「リクエスト/応答」タイプICMPメッセージです。ただし、メッセージ内に「識別子」フィールドがないため、このドキュメントのICMPクエリメッセージとして特徴付けられていません。同様に、[RFC4065]で定義されている他のICMPメッセージがあり、ICMPクエリまたは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メッセージを分類する理由は、各カテゴリがマッピングに使用される異なる特性（つまり、クエリ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クエリとそれに関連する応答を許可する必要があります。NATデバイスによるICMPクエリマッピングは、現在のICMPクエリベースのアプリケーションが機能するために必要です。これには、NATデバイスがNATの背後にあるノードから開始されたICMPクエリパケットと、これらのクエリパケットへの応答を反対方向に透過的に転送する必要があります。[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を使用してICMPクエリを外部ホストBに送信しました。たとえば、NATはこれにNATのパブリックアドレスにクエリID X 'の外部マッピングを割り当てました。ホストAがクエリID Xを再利用してICMPクエリを同じまたは異なる外部ホストに送信する場合、NATデバイスは同じクエリIDマッピングを再利用する必要があります（つまり、プライベートホストのクエリID Xをマッピングして、NATのパブリックIPアドレスにQuery ID X 'にマップします）別のマッピングを割り当てる代わりに。これは、TCPおよびUDP要件ドキュメントで指定された「Endpoint Independent Mapping」要件に類似しています[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 aのエンドポイント非依存マッピング[RFC2119]要件を作成するための正当化です。ICMP Ping [RFC1470]およびICMP Traceroute [MS-TRCRT]は、ICMPクエリメッセージの上に構築された2つの最も一般的に知られているレガシーアプリケーションです。これらのアプリケーションのいずれも、外部ホストとのさまざまなセッション全体で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デバイスが外部ホストに依存しないエンドポイントマッピングを実施する場合、上記の仮定が有効になります。エンドポイントに依存しないマッピングを必要としないレガシーアプリケーションとそれを必要とする可能性のある将来のアプリケーション間の二分法を考えると、要件レベルは[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.
a) ICMPクエリ識別子のNATマッピングは、外部ホストに依存する必要があります。
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）に設定する必要があります。最大RTTを制約する目的で、[RFC793]で定義されている最大セグメント寿命（MSL）は、パケット寿命を設定するためのガイドラインと見なすことができます。[RFC793]に従って、MSLは、目的の受信者に配信される前に、TCPセグメントがネットワークに存在できる最大時間です。これは、パケットが配信されなくなることを宣言する前に、意図した宛先ノードに到達するために取ると想定できる最大期間です。ICMPクエリメッセージを開始し、クエリの応答を待つアプリケーションの場合、最大RTTは、クエリメッセージのMSLの合計と応答メッセージのMSLの合計となるように制約される可能性があります。言い換えれば、最大RTTは2xMSL以下に制約される可能性があります。[RFC793]のMSLの推奨値は120秒です。MSLが120秒の場合、最大RTT（2x 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ピン[RFC1470]およびICMP Traceroute [MS-TRCRT]であるICMP Traceroute [MS-TRCRT]は、ICMPクエリメッセージの上に構築された2つの最も一般的に既知のレガシーアプリケーションで、ターゲットノードが動作している場合に往復を完了するには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.
ICMP NATセッションのタイムアウトを非常に大きな期間（たとえば、240秒）に設定すると、クエリマッピングや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.
a) ICMPクエリセッションタイマーを構成可能にすることをお勧めします。
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がICMPエラーメッセージを転送および翻訳するために埋め込まれたIPおよびトランスポートヘッダーを使用しているためです（セクション4.2で説明）。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ヘッダーを埋め込み、最低64ビットのIPペイロードしか埋め込む必要があるためです。[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エラーメッセージ内の埋め込みパケットのトランスポートチェックサムを検証してはなりません。これは、NATが無効な輸送チェックサムのためにICMPエラーメッセージをドロップすると、エンドホストが特定の種類の腐敗のエラーレポートを受信することを難しくするためです。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
a) 組み込みパケットのIPチェックサムが検証に失敗した場合、NATは静かにエラーパケットをドロップするはずです。と
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
b) 組み込みパケットにIPオプションが含まれている場合、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デバイスです。Router-XとHost-Xは外部ネットワークにあります。Router-YとHost-Yはプライベートネットワークにあります。外部ネットワークのサブネットは、プライベートおよび外部ドメインからルーティング可能です。対照的に、プライベートネットワーク内のサブネットは、プライベートドメイン内でのみルーティング可能です。Host-YがHost-Xのセッションを開始したら、NATデバイスがHost-Yのエンドポイントを外部ネットワークでHost-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
図1. NATデバイスを横断するプライベートホストからのセッション
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.
たとえば、Host-YからHost-Xへのパケットは、Router-XまたはHost-XのいずれかからのICMPエラーメッセージをトリガーしました（どちらも外部ドメインにあります）。このようなICMPエラーパケットは、下の図2に記載されているように、ソースIPアドレスとしてRouter-XまたはHost-Xのいずれかを、宛先IPアドレスとしてHOST-Y 'の1つを搭載します。
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エラーメッセージ（つまり、Host-Y 'からHost-XへのIPパケット）に埋め込まれたパケットを使用して、埋め込みパケットが属するNATセッションを検索します。。NATデバイスに埋め込みパケットのアクティブマッピングがない場合、NATはICMPエラーパケットを静かにドロップするはずです。それ以外の場合、NATデバイスは、一致するNATセッションを使用して、組み込みパケットを翻訳する必要があります。つまり、組み込みパケットのソースIPアドレス（例：HOST-Y ' - > HOST-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デバイスは、一致するNATセッションを使用して、外部IPヘッダーの宛先IPアドレスを翻訳する必要があります。外側のヘッダーでは、ICMPエラーメッセージ（Host-XまたはRouter-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
a) 埋め込みマッピングを使用して、埋め込まれたIPパケットのIPおよび輸送ヘッダーを元のフォームに戻します。と
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.
さて、たとえば、Host-XからHost-Yへのパケットは、Router-YまたはHost-YのICMPエラーメッセージをトリガーしました（どちらもプライベートドメインにあります）。このようなICMPエラーパケットは、下の図3に指定されているように、ソースIPアドレスとしてRouter-YまたはHOST-Yの1つ、宛先IPアドレスとしてHOST-Xの1つを搭載します。
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デバイスは、ICMPエラーメッセージ（つまり、Host-XからHost-YへのIPパケット）に埋め込まれたパケットを使用して、埋め込みパケットが属するNATセッションを検索する必要があります。。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.
外側のヘッダーでは、Host-XのIPアドレスがすでに外部ドメインにあるため、宛先IPアドレスは変更されません。ICMPエラーメッセージがHost-Yによって生成された場合、NATデバイスはNATセッションを使用して、ソースIPアドレスHOST-Yをホスト-Yに変換する必要があります。ICMPエラーメッセージが中間ノードRouter-Yによって発信される場合、ソースIPアドレスの変換は、基本的なNAT関数[NATトラッド]がNATデバイスによって施行されるかによって異なります。基本的なNAT関数を強制するNATデバイスには、パブリックIPアドレスのプールがあり、プライベートノードがNATデバイスを介して発信セッションを開始するときに、アドレスアドレスマッピング（NAPTが施行するエンドポイントマッピングとは異なります）。したがって、NATデバイスに中間ノードRouter-YのIPアドレスのアクティブマッピングがある場合、NATデバイスは、ICMPエラーパケットのソースIPアドレスをマッピング内のパブリック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
a) 埋め込みマッピングを使用して、埋め込まれたIPパケットのIPおよび輸送ヘッダーを元のフォームに戻します。と
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がBasic NAT関数（[NAT-Trad]）を強制し、NATにICMPエラーを送信したIPアドレスのアクティブマッピングがある場合、ICMPエラーパケットのソースIPアドレスをマッピング内のパブリックIPアドレスで変換します。他のすべての場合、ICMPエラーパケットのソースIPアドレスを独自のパブリック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]および[beh-tcp]は、それぞれNATデバイスでのUDPおよびTCPセッションのヘアピニングのサポートを義務付けています。NATデバイスは、ICMPクエリセッションのヘアピニングもサポートする必要があります。具体的には、基本的なNAT [NAT-Trad]を強制するNATデバイスは、ヘアピンされたICMPクエリセッションのトラバーサルをサポートする必要があります。たとえば、個々のプライベートホストは、NATが割り当てられた外部IPアドレスをRendezvousサーバーに登録します。登録されたホストにICMPクエリセッションを開始したい他のホストは、Rendezvousサーバーに登録されたパブリックアドレスを使用してそうする場合があります。このため、ヘアピンされたICMPクエリセッションのトラバーサルをサポートするには、基本的なNATデバイスが必要です。この要件は、現在のアプリケーションが正しく機能するために必要です。
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) ヘアピンされたICMPエラーメッセージを転送する場合、NATデバイスは、翻訳後に埋め込まれたIPパケットのソースIPアドレスと同じように外側IPヘッダーの宛先IPアドレスを翻訳する必要があります。
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タイプ= 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: 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.
このドキュメントは、[RFC1812]のセクション4.3で指定されているように、ルーターがICMPメッセージを処理する方法と一致する動作をNATSに指定します。ただし、[RFC1812]の公開以来、その要件の一部はもはや最良の現在のプラクティスではありません。したがって、次の要件は[RFC1812]から導出され、この仕様に準拠したNATに適用されます。REQ-9：NATデバイスは、特定のインターフェイスに向けてICMPメッセージが生成されるのを防ぐポリシーコントロールを実装できます。このようなポリシーコントロールの実装は、REQ-10の必需品と肩をオーバーライドします。
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デバイスは以下のようにICMPメッセージをサポートする必要があります。
a. MUST support:
a. サポートする必要があります：
1. Destination Unreachable Message, as described in Section 7.1 of this document.
1. このドキュメントのセクション7.1で説明されているように、宛先の到達不可能なメッセージ。
2. Time Exceeded Message, as described in Section 7.2 of this document.
2. このドキュメントのセクション7.2で説明されているように、時間はメッセージを超えました。
3. Echo Request/Reply Messages, as described in REQ-1.
3. Req-1で説明されているように、エコーリクエスト/返信メッセージ。
b. MAY support:
b. サポートするかもしれません：
1. Redirect Message, as described in Section 4.3.3.2 of [RFC1812].
1. [RFC1812]のセクション4.3.3.2で説明されているように、メッセージをリダイレクトします。
2. Timestamp and Timestamp Reply Messages, as described in Section 4.3.3.8 of [RFC1812].
2. [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.
4. このドキュメントのセクション7.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.
6. このドキュメントのセクション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. このドキュメントのセクション7.7で説明されているように、DSフィールド使用。
e. When Not to Send ICMP Errors, as described in Section 4.3.2.7 of [RFC1812].
e. [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ベースのアプリケーションを含む）は、ネットワークからのICMPエラーメッセージに依存して、エンドツーエンドパスMTU発見[PMTU]を実行します。パスMTUが発見されると、断片化を回避することを選択するアプリケーションは、途中でパスMTU内に適合するIPパケットを発信し、DF（フラグメントしないでください）をIPヘッダーに設定することにより、それを行うことができます。ルートはIPパケットをフラグメントしないでください。次のサブセクションでは、IPヘッダーのDFビットを尊重し、「大きすぎる」ICMPエラーメッセージを断片化なしではIPパケットを転送できない場合に「大きすぎる」ICMPエラーメッセージを生成できるようにするNATデバイスの必要性について説明しています。また、他の中間デバイスによって生成された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）ビットが設定されていないため、データグラムを転送できない場合、ルーターは[RFC1812]によって必要とされます。データグラムのソース。「断片化が必要とDFセット」を示すコード。さらに、[PMTU]は、ルーターに、ICMP仕様[ICMP]に「未使用」とラベル付けされたICMPヘッダーフィールドの低次の16ビットに、そのネクストホップネットワークのMTUを含める必要があると述べています。
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デバイスは、NATデバイスの転送インターフェイス上のMTUがIPパケットに適していない場合、フラグメンテーションなしでIPパケットを転送できない場合があります。DFビットがトランジットIPパケットで設定されており、NATデバイスがフラグメンテーションなしでパケットを転送できない場合、NATデバイスは「パケットが大きすぎる」ICMPメッセージ（ICMPタイプ3、コード4）をNext-Hop MTUバックで送信する必要があります。送信者に、元の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デバイスは、以前に記載された要件に従って、ICMPメッセージを意図した受信者に転送する必要があります（REQ-3、REQ-4、およびREQ-4、および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エラーメッセージに依存するTraceroute [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アドレスマスクの応答メッセージで応答するためのサポートを実装する必要があると述べています。ただし、RFC 1812のテキストが書かれて以来、数年（このドキュメントの時点で13年以上）が経過しています。介入時に、DHCP [DHCP]はアドレスマスクリクエスト/返信の使用に取って代わりました。現時点では、ホスト要件を満たしていないホスト[RFC1122]があり、アドレスマスクリクエスト/返信をサポートするためにNATデバイスが必要なホストはめったにありません。
For this reason, a NAT device is not required to support this ICMP message.
このため、このICMPメッセージをサポートするためにNATデバイスは必要ありません。
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.
このため、このICMPメッセージをサポートするためにNATデバイスは必要ありません。
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.
このため、このICMPメッセージをサポートするためにNATデバイスは必要ありません。
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）Octetのタイプ（TOS）Octetを指します。ただし、TOSおよびIPの優先フィールドは、今日使用されていません。[RFC2474]は、TOS OctetをDSフィールドと改名し、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.
前のセクションでは、NATデバイスでICMP要件が特定され、用語セクションで定義されているように、ICMPクエリとICMPエラーメッセージに主な焦点を当てています（セクション2を参照）。このドキュメントは、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.
REQ-11：NATは、非QueryError ICMPメッセージを落とすか、適切に処理する場合があります。非QueryError ICMPメッセージのセマンティクスは、セクション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.
a) ICMPクエリ識別子のNATマッピングは、外部ホストに依存する必要があります。
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.
a) ICMPクエリセッションタイマーを構成可能にすることをお勧めします。
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
a) 組み込みパケットのIPチェックサムが検証に失敗した場合、NATは静かにエラーパケットをドロップするはずです。と
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
b) 組み込みパケットにIPオプションが含まれている場合、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
a) 埋め込みマッピングを使用して、埋め込まれたIPパケットのIPおよび輸送ヘッダーを元のフォームに戻します。と
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
a) 埋め込みマッピングを使用して、埋め込まれたIPパケットのIPおよび輸送ヘッダーを元のフォームに戻します。と
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にICMPエラーを送信したIPアドレスのアクティブマッピングがある場合、ICMPエラーパケットのソースIPアドレスをマッピング内のパブリックIPアドレスで変換します。他のすべての場合、ICMPエラーパケットのソースIPアドレスを独自のパブリック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：Basic 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) ヘアピンされたICMPエラーメッセージを転送する場合、NATデバイスは、翻訳後に埋め込まれたIPパケットのソースIPアドレスと同じように外側IPヘッダーの宛先IPアドレスを翻訳する必要があります。
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デバイスは、特定のインターフェイスに向けてICMPメッセージが生成されるのを防ぐポリシーコントロールを実装する場合があります。このようなポリシーコントロールの実装は、REQ-10の必需品と肩をオーバーライドします。
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デバイスは以下のようにICMPメッセージをサポートする必要があります。
a. MUST support:
a. サポートする必要があります：
1. Destination Unreachable Message, as described in Section 7.1 of this document.
1. このドキュメントのセクション7.1で説明されているように、宛先の到達不可能なメッセージ。
2. Time Exceeded Message, as described in Section 7.2 of this document.
2. このドキュメントのセクション7.2で説明されているように、時間はメッセージを超えました。
3. Echo Request/Reply Messages, as described in REQ-1.
3. Req-1で説明されているように、エコーリクエスト/返信メッセージ。
b. MAY support:
b. サポートするかもしれません：
1. Redirect Message, as described in Section 4.3.3.2 of [RFC1812].
1. [RFC1812]のセクション4.3.3.2で説明されているように、メッセージをリダイレクトします。
2. Timestamp and Timestamp Reply Messages, as described in Section 4.3.3.8 of [RFC1812].
2. [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.
4. このドキュメントのセクション7.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.
6. このドキュメントのセクション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. このドキュメントのセクション7.7で説明されているように、DSフィールド使用。
e. When Not to Send ICMP Errors, as described in Section 4.3.2.7 of [RFC1812].
e. [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チェックサムを検証することをお勧めします。これらのチェックサムの検証自体は、攻撃からエンドホストを保護しません。ただし、CheCksumの検証により、不正なICMPエラー攻撃からのエンドホストが緩和されます。REQ-4およびREQ-5は、NATデバイスが組み込みペイロードのマッピング選択が見つからない場合、NATは転送せずにICMPエラーパケットをドロップすることを義務付けています。
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.
Rogueソースは、セッションを破壊する意図で、アクティブなNATセッションにBogus ICMPエラーメッセージを送信しようとすることもできます。REQ-6は、ICMPエラーメッセージがNATデバイスのセッションの状態に影響を与えないことを確認することにより、このような攻撃を回避します。
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エラーメッセージを送信させないことを選択する場合があります。このため、REQ-8に記載されている特定のICMPエラーメッセージの送信は、NATデバイス管理者の裁量に任されています。
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メッセージのブロックは、一部のプロトコル機能（最も顕著なPath MTU発見）といくつかのアプリケーション（Ping、Tracerouteなど）を破ることが知られており、そのようなブロッキングは推奨されません。
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.
著者は、Fernando Gont、Dan Wing、Carlos Pignataro、Philip Matthews、およびBeave Working Groupのメンバーに、ドキュメントの初期バージョンを徹底的にレビューし、貴重なインプットを提供し、ICMPの形成において寛大な時間を提供してくれたことに感謝します。要件。彼らの貴重なフィードバックにより、このドキュメントはよりよく読まれました。ダン・ウィングとフェルナンド・ゴントは、着実な励ましの源でした。Fernando Gontは、著者に代わってSlideを準備し、IETF会議でドキュメントを提示するのに何時間も費やしました。著者は、ICMP拡張に関するフィードバックについて、[ICMP-Ext]文書の著者であるCarlos PignataroとDan Tappanに感謝したいと考えています。著者は、この文書の技術的なレビュー担当者になることに同意してくれたフィリップ・マシューズに感謝したいと考えています。最後に、著者は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.、ed。、およびC. Jennings、「ユニキャストUDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[ICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMP] Postel、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.、Gan、D.、Tappan、D.、およびC. Pignataro、「マルチパートメッセージをサポートするためにICMPを拡張」、RFC 4884、2007年4月。
[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] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F.、ed。、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Ford、B.、Srisuresh、P。、およびD. Kegel、「ネットワークアドレス翻訳者を介したトラバーサルのアプリケーション設計ガイドライン」、2007年3月、ProgressのWork。
[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] Guha、S.、Ed。、Biswas、K.、Ford、B.、Sivakumar、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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Microsoft Support、「Tracertコマンドラインユーティリティを使用してWindowsのTCP/IP問題のトラブルシューティング方法」、http：//support.microsoft.com/kb/162326、2006年10月。
[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.、Pai、N。、およびC. Wang、「ネットワークアドレス翻訳者の管理オブジェクトの定義（NAT）、RFC 4008、2005年3月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-Term] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[PMTU] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、S.、ed。、「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.
[RFC1470] Enger、R。およびJ. Reynolds、「Network Management ToolカタログのFYI：TCP/IPインターネットと相互接続されたデバイスの監視とデバッグのツール」、1993年6月、FYI 2、RFC 1470。
[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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4065] Kempf、J。、「Seamoby and Experimental Mobility Protocol Ianaの割り当ての指示」、RFC 4065、2005年7月。
[TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[TCPソフト] 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.、ed。、および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 San Antonio Rd。マウンテンビュー、CA 94043 U.S.A.
Phone: +1 408 836 4773
EMail: srisuresh@yahoo.com
Bryan Ford Max Planck Institute for Software Systems Campus Building E1 4 D-66123 Saarbruecken Germany
ブライアンフォードマックスプランクソフトウェアシステムキャンパスビルディングE1 4 D-66123 Saarbrueckenドイツ
Phone: +49-681-9325657
EMail: 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 Sivakumar Cisco Systems、Inc。7100-8 Kit Creek Road PO Box 14987 Research Triangle Park、NC 27709-4987 U.S.A.
Phone: +1 919 392 5158
EMail: ssenthil@cisco.com
Saikat Guha Cornell University 331 Upson Hall Ithaca, NY 14853 U.S.A.
Saikat Guha Cornell University 331 Upson Hall Ithaca、NY 14853 U.S.A.
Phone: +1 607 255 1008
EMail: saikat@cs.cornell.edu