[要約] RFC 3022は、従来のIPネットワークアドレス変換（Traditional NAT）に関する規格です。その目的は、プライベートIPアドレスをパブリックIPアドレスに変換することで、ネットワークのアドレス空間を効果的に利用することです。
Network Working Group P. Srisuresh
Request for Comments: 3022 Jasmine Networks
Obsoletes: 1631 K. Egevang
Category: Informational Intel Corporation
January 2001
Traditional IP Network Address Translator (Traditional NAT)
従来のIPネットワークアドレス翻訳者（従来のNAT）
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。全著作権所有。
Preface
序文
The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail.
このドキュメントで説明されているNAT操作は、RFC 1631で導入されたアドレス変換を拡張し、新しいタイプのネットワークアドレスとTCP/UDPポート翻訳を含んでいます。さらに、このドキュメントは、RFC 1631で公開されているチェックサム調整アルゴリズムを修正し、NATの操作と制限を詳細に議論しようとします。
Abstract
概要
Basic Network Address Translation or Basic NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses.
基本的なネットワークアドレスの変換または基本NATは、IPアドレスがあるグループから別のグループにマッピングされ、エンドユーザーに透明になる方法です。ネットワークアドレスポート変換、またはNAPTは、多くのネットワークアドレスとそのTCP/UDP（伝送制御プロトコル/ユーザーデータグラムプロトコル）ポートが単一のネットワークアドレスとそのTCP/UDPポートに変換される方法です。一緒に、従来のNATと呼ばれるこれら2つの操作は、グローバルに一意の登録アドレスを持つ外部領域にプライベートアドレスを持つ領域を接続するメカニズムを提供します。
The need for IP Address translation arises when a network's internal IP addresses cannot be used outside the network either for privacy reasons or because they are invalid for use outside the network.
IPアドレス変換の必要性は、ネットワークの内部IPアドレスをネットワークの外部で使用できない場合に発生します。プライバシーの理由で、またはネットワーク外で使用するために無効であるためです。
Network topology outside a local domain can change in many ways. Customers may change providers, company backbones may be reorganized, or providers may merge or split. Whenever external topology changes
ローカルドメイン外のネットワークトポロジは、多くの点で変化する可能性があります。顧客はプロバイダーを変更したり、会社のバックボーンを再編成したり、プロバイダーがマージまたは分割したりする場合があります。外部トポロジが変更されるたびに
with time, address assignment for nodes within the local domain must also change to reflect the external changes. Changes of this type can be hidden from users within the domain by centralizing changes to a single address translation router.
時間がある場合、ローカルドメイン内のノードのアドレス割り当ても、外部の変更を反映するために変更する必要があります。このタイプの変更は、変更を単一のアドレス変換ルーターに集中化することにより、ドメイン内のユーザーから隠すことができます。
Basic Address translation would (in many cases, except as noted in [NAT-TERM] and section 6 of this document) allow hosts in a private network to transparently access the external network and enable access to selective local hosts from the outside. Organizations with a network setup predominantly for internal use, with a need for occasional external access are good candidates for this scheme.
基本的なアドレス変換は（多くの場合、このドキュメントの[NAT-Term]とセクション6に記載されている場合を除きます）、プライベートネットワークのホストが外部ネットワークに透過的にアクセスし、外部から選択的なローカルホストへのアクセスを可能にすることができます。主に内部使用のためにネットワークをセットアップする組織は、時折外部アクセスを必要とするために、このスキームの良い候補です。
Many Small Office, Home Office (SOHO) users and telecommuting employees have multiple Network nodes in their office, running TCP/UDP applications, but have a single IP address assigned to their remote access router by their service provider to access remote networks. This ever increasing community of remote access users would be benefited by NAPT, which would permit multiple nodes in a local network to simultaneously access remote networks using the single IP address assigned to their router.
多くの小さなオフィス、ホームオフィス（SOHO）ユーザー、およびテレコミューティングの従業員は、オフィスに複数のネットワークノードを持っています。TCP/UDPアプリケーションを実行していますが、リモートネットワークにアクセスするためにサービスプロバイダーによってリモートアクセスルーターに単一のIPアドレスが割り当てられています。リモートアクセスユーザーのこの増加するコミュニティは、NAPTの恩恵を受けることができます。これにより、ローカルネットワーク内の複数のノードが、ルーターに割り当てられた単一のIPアドレスを使用してリモートネットワークに同時にアクセスできます。
There are limitations to using the translation method. It is mandatory that all requests and responses pertaining to a session be routed via the same NAT router. One way to ascertain this would be to have NAT based on a border router that is unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. There are other ways to ensure this with multiple NAT devices. For example, a private domain could have two distinct exit points to different providers and the session flow from the hosts in a private network could traverse through whichever NAT device has the best metric for an external host. When one of the NAT routers fail, the other could route traffic for all the connections. There is however a caveat with this approach, in that, rerouted flows could fail at the time of switchover to the new NAT router. A way to overcome this potential problem is that the routers share the same NAT configuration and exchange state information to ensure a fail-safe backup for each other.
翻訳方法を使用することには制限があります。セッションに関連するすべてのリクエストと応答が、同じNATルーターを介してルーティングされることは必須です。これを確認する1つの方法は、すべてのIPパケットがドメインから発信されるかドメインに導かれるスタブドメインに固有の境界ルーターに基づいてNATを持つことです。複数のNATデバイスでこれを確保する他の方法があります。たとえば、プライベートドメインは異なるプロバイダーに2つの異なる出口ポイントを持つことができ、プライベートネットワークのホストからのセッションフローは、NATデバイスが外部ホストに最適なメトリックを持っている場合でも通過できます。 NATルーターの1つが失敗すると、もう1つはすべての接続のトラフィックをルーティングできます。ただし、このアプローチには警告があります。そのため、新しいNATルーターへのスイッチオーバー時に再ルーティングされたフローが故障する可能性があります。この潜在的な問題を克服する方法は、ルーターが同じNAT構成を共有し、状態情報を交換して、互いにフェイルセーフバックアップを確保することです。
Address translation is application independent and often accompanied by application specific gateways (ALGs) to perform payload monitoring and alterations. FTP is the most popular ALG resident on NAT devices. Applications requiring ALG intervention must not have their payload encoded, as doing that would effectively disables the ALG, unless the ALG has the key to decrypt the payload.
アドレス変換はアプリケーションに依存しないものであり、多くの場合、アプリケーション固有のゲートウェイ（ALG）を伴い、ペイロードの監視と変更を実行します。FTPは、NATデバイスで最も人気のあるアルグ居住者です。ALG介入を必要とするアプリケーションは、ペイロードを効果的に無効にするため、ALGにペイロードを復号化するキーがない限り、ALGを効果的に無効にするため、ペイロードをエンコードしてはなりません。
This solution has the disadvantage of taking away the end-to-end significance of an IP address, and making up for it with increased state in the network. As a result, end-to-end IP network level
このソリューションには、IPアドレスのエンドツーエンドの重要性を奪い、ネットワーク内の状態を増やしてそれを補うという欠点があります。その結果、エンドツーエンドのIPネットワークレベル
security assured by IPSec cannot be assumed to end hosts, with a NAT device enroute. The advantage of this approach however is that it can be installed without changes to hosts or routers.
IPSECによって保証されたセキュリティは、NATデバイスが途中でホストを終了すると想定することはできません。ただし、このアプローチの利点は、ホストやルーターを変更せずにインストールできることです。
Definition of terms such as "Address Realm", "Transparent Routing", "TU Ports", "ALG" and others, used throughout the document, may be found in [NAT-TERM].
「アドレスレルム」、「透明ルーティング」、「TUポート」、「アルグ」などの用語の定義は、ドキュメント全体で使用されるものが[NAT-Term]にあることがあります。
The Address Translation operation presented in this document is referred to as "Traditional NAT". There are other variations of NAT that will not be explored in this document. Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network. Sessions in the opposite direction may be allowed on an exceptional basis using static address maps for pre-selected hosts. Basic NAT and NAPT are two variations of traditional NAT, in that translation in Basic NAT is limited to IP addresses alone, whereas translation in NAPT is extended to include IP address and Transport identifier (such as TCP/UDP port or ICMP query ID).
このドキュメントに示されているアドレス変換操作は、「従来のNAT」と呼ばれます。このドキュメントでは調査されないNATの他のバリエーションがあります。従来のNATにより、プライベートネットワーク内のホストは、ほとんどの場合、外部ネットワーク内のホストに透過的にアクセスできます。従来のNATでは、セッションは一方向であり、プライベートネットワークからのアウトバウンドです。反対方向のセッションは、事前に選択されたホストの静的アドレスマップを使用して、例外的に許可される場合があります。基本的なNATとNAPTは従来のNATの2つのバリエーションです。基本NATの翻訳はIPアドレスのみに限定されているのに対し、NAPTの翻訳はIPアドレスと輸送識別子（TCP/UDPポートまたはICMPクエリIDなど）を含むように拡張されています。
Unless mentioned otherwise, Address Translation or NAT throughout this document will pertain to traditional NAT, namely Basic NAT as well as NAPT. Only the stub border routers as described in figure 1 below may be configured to perform address translation.
特に言及されていない限り、このドキュメント全体のアドレス翻訳またはNATは、従来のNAT、つまり基本的なNATとNAPTに関係します。以下の図1に記載されているスタブボーダールーターのみを、アドレス変換を実行するように構成できます。
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
Figure 1: Traditional NAT Configuration
図1：従来のNAT構成
Basic NAT operation is as follows. A stub domain with a set of private network addresses could be enabled to communicate with external network by dynamically mapping the set of private addresses to a set of globally valid network addresses. If the number of local nodes are less than or equal to addresses in the global set, each local address is guaranteed a global address to map to. Otherwise, nodes allowed to have simultaneous access to external network are
基本的なNAT操作は次のとおりです。プライベートネットワークアドレスのセットを備えたスタブドメインは、プライベートアドレスのセットをグローバルに有効なネットワークアドレスのセットに動的にマッピングすることにより、外部ネットワークと通信できるようにすることができます。ローカルノードの数がグローバルセットのアドレスよりも低い場合、各ローカルアドレスには、マップするグローバルアドレスが保証されます。それ以外の場合、ノードは外部ネットワークへの同時アクセスを持つことができます
limited by the number of addresses in global set. Individual local addresses may be statically mapped to specific global addresses to ensure guaranteed access to the outside or to allow access to the local host from external hosts via a fixed public address. Multiple simultaneous sessions may be initiated from a local node, using the same address mapping.
グローバルセットのアドレスの数によって制限されます。個々のローカルアドレスは、特定のグローバルアドレスに静的にマッピングされ、外部へのアクセスが保証されていることを保証するか、固定されたパブリックアドレスを介して外部ホストからローカルホストへのアクセスを許可する場合があります。同じアドレスマッピングを使用して、ローカルノードから複数の同時セッションを開始できます。
Addresses inside a stub domain are local to that domain and not valid outside the domain. Thus, addresses inside a stub domain can be reused by any other stub domain. For instance, a single Class A address could be used by many stub domains. At each exit point between a stub domain and backbone, NAT is installed. If there is more than one exit point it is of great importance that each NAT has the same translation table.
スタブドメイン内のアドレスは、そのドメインにローカルであり、ドメインの外側では有効ではありません。したがって、スタブドメイン内のアドレスは、他のスタブドメインによって再利用できます。たとえば、多くのスタブドメインでは、単一のクラスAアドレスを使用できます。スタブドメインとバックボーンの間の各出口ポイントで、NATがインストールされます。複数の出口ポイントがある場合、各NATが同じ翻訳テーブルを持っていることが非常に重要です。
For instance, in the example of figure 2, both stubs A and B internally use class A private address block 10.0.0.0/8 [RFC 1918]. Stub A's NAT is assigned the class C address block 198.76.29.0/24, and Stub B's NAT is assigned the class C address block 198.76.28.0/24. The class C addresses are globally unique no other NAT boxes can use them.
たとえば、図2の例では、両方のスタブAとBの両方がクラスAプライベートアドレスブロック10.0.0.0/8 [RFC 1918]を内部的に使用しています。スタブAのNATには、クラスCアドレスブロック198.76.29.0/24が割り当てられ、スタブBのNATにはクラスCアドレスブロック198.76.28.0/24が割り当てられます。クラスCアドレスはグローバルに一意です。他のNATボックスはそれらを使用できません。
\ | /
+---------------+
|Regional Router|
+---------------+
WAN | | WAN
| |
Stub A .............|.... ....|............ Stub B
| |
{s=198.76.29.7,^ | | v{s=198.76.29.7,
d=198.76.28.4}^ | | v d=198.76.28.4}
+-----------------+ +-----------------+
|Stub Router w/NAT| |Stub Router w/NAT|
+-----------------+ +-----------------+
| |
| LAN LAN |
------------- -------------
| |
{s=10.33.96.5, ^ | | v{s=198.76.29.7,
d=198.76.28.4}^ +--+ +--+ v d=10.81.13.22}
|--| |--|
/____\ /____\
10.33.96.5 10.81.13.22
Figure 2: Basic NAT Operation
図2：基本NAT操作
When stub A host 10.33.96.5 wishes to send a packet to stub B host 10.81.13.22, it uses the globally unique address 198.76.28.4 as destination, and sends the packet to its primary router. The stub router has a static route for net 198.76.0.0 so the packet is forwarded to the WAN-link. However, NAT translates the source address 10.33.96.5 of the IP header to the globally unique 198.76.29.7 before the packet is forwarded. Likewise, IP packets on the return path go through similar address translations.
ホスト10.33.96.5がスタブBホスト10.81.13.22にパケットを送信したい場合、グローバルに一意のアドレス198.76.28.4を宛先として使用し、パケットをプライマリルーターに送信します。スタブルーターには、ネット198.76.0.0の静的ルートがあるため、パケットはWANリンクに転送されます。ただし、NATは、パケットが転送される前に、IPヘッダーのソースアドレス10.33.96.5をグローバルに198.76.29.7に翻訳します。同様に、リターンパス上のIPパケットは、同様のアドレス翻訳を通過します。
Notice that this requires no changes to hosts or routers. For instance, as far as the stub A host is concerned, 198.76.28.4 is the address used by the host in stub B. The address translations are transparent to end hosts in most cases. Of course, this is just a simple example. There are numerous issues to be explored.
これには、ホストまたはルーターに変更が必要ではないことに注意してください。たとえば、スタブAホストに関する限り、198.76.28.4はスタブBでホストが使用するアドレスです。ほとんどの場合、アドレスの翻訳はエンドホストに対して透明です。もちろん、これは単なる簡単な例です。調査すべき多くの問題があります。
Say, an organization has a private IP network and a WAN link to a service provider. The private network's stub router is assigned a globally valid address on the WAN link and the remaining nodes in the organization have IP addresses that have only local significance. In such a case, nodes on the private network could be allowed simultaneous access to the external network, using the single registered IP address with the aid of NAPT. NAPT would allow mapping of tuples of the type (local IP addresses, local TU port number) to tuples of the type (registered IP address, assigned TU port number).
たとえば、組織にはプライベートIPネットワークとサービスプロバイダーへのWANリンクがあります。プライベートネットワークのスタブルーターには、WANリンクにグローバルに有効なアドレスが割り当てられ、組織内の残りのノードには、局所的な重要性しか持たないIPアドレスがあります。このような場合、プライベートネットワーク上のノードは、NAPTの助けを借りて単一の登録IPアドレスを使用して、外部ネットワークへの同時アクセスを許可することができます。NAPTでは、タイプのタプル（ローカルIPアドレス、ローカルTUポート番号）のタイプ（登録IPアドレス、割り当てられたTUポート番号）にマッピングできます。
This model fits the requirements of most Small Office Home Office (SOHO) groups to access external network using a single service provider assigned IP address. This model could be extended to allow inbound access by statically mapping a local node per each service TU port of the registered IP address.
このモデルは、単一のサービスプロバイダーが割り当てられたIPアドレスを使用して外部ネットワークにアクセスするために、ほとんどの小オフィスホームオフィス（SOHO）グループの要件に適合します。このモデルは、登録されたIPアドレスの各サービスTUポートごとにローカルノードを静的にマッピングすることにより、インバウンドアクセスを可能にするために拡張できます。
In the example of figure 3 below, stub A internally uses class A address block 10.0.0.0/8. The stub router's WAN interface is assigned an IP address 138.76.28.4 by the service provider.
以下の図3の例では、Stub AはクラスAアドレスブロック10.0.0.0/8を内部で使用しています。スタブルーターのWANインターフェイスには、サービスプロバイダーによってIPアドレス138.76.28.4が割り当てられています。
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
|
Stub A .............|....
|
^{s=138.76.28.4,sport=1024, | v{s=138.76.29.7, sport = 23,
^ d=138.76.29.7,dport=23} | v d=138.76.28.4, dport = 1024}
+------------------+
|Stub Router w/NAPT|
+------------------+
|
| LAN
--------------------------------------------
| ^{s=10.0.0.10,sport=3017, | v{s=138.76.29.7, sport=23,
| ^ d=138.76.29.7,dport=23} | v d=10.0.0.10, dport=3017}
| |
+--+ +--+ +--+
|--| |--| |--|
/____\ /____\ /____\
10.0.0.1 10.0.0.2 ..... 10.0.0.10
Figure 3: Network Address Port Translation (NAPT) Operation
図3：ネットワークアドレスポート翻訳（NAPT）操作
When stub A host 10.0.0.10 sends a telnet packet to host 138.76.29.7, it uses the globally unique address 138.76.29.7 as destination, and sends the packet to it's primary router. The stub router has a static route for the subnet 138.76.0.0/16 so the packet is forwarded to the WAN-link. However, NAPT translates the tuple of source address 10.0.0.10 and source TCP port 3017 in the IP and TCP headers into the globally unique 138.76.28.4 and a uniquely assigned TCP port, say 1024, before the packet is forwarded. Packets on the return path go through similar address and TCP port translations for the target IP address and target TCP port. Once again, notice that this requires no changes to hosts or routers. The translation is completely transparent.
ホスト10.0.0.10のスタブがTelnetパケットをホスト138.76.29.7に送信すると、グローバルにユニークなアドレス138.76.29.7を宛先として使用し、パケットをプライマリルーターに送信します。スタブルーターには、サブネット138.76.0.0/16の静的ルートがあるため、パケットはWANリンクに転送されます。ただし、NAPTは、IPのソースアドレス10.0.0.10およびソースTCPポート3017のタプルをIPおよびTCPヘッダーのグローバルに一意の138.76.28.4に翻訳し、パケットが転送される前に138.76.28.4、たとえば1024に割り当てられたTCPポートに翻訳されます。リターンパス上のパケットは、ターゲットIPアドレスとターゲットTCPポートの同様のアドレスとTCPポート翻訳を通過します。繰り返しになりますが、これにはホストまたはルーターに変更が不要になることに注意してください。翻訳は完全に透明です。
In this setup, only TCP/UDP sessions are allowed and must originate from the local network. However, there are services such as DNS that demand inbound access. There may be other services for which an organization wishes to allow inbound session access. It is possible to statically configure a well known TU port service [RFC 1700] on the stub router to be directed to a specific node in the private network.
このセットアップでは、TCP/UDPセッションのみが許可されており、ローカルネットワークから発生する必要があります。ただし、インバウンドアクセスを要求するDNSなどのサービスがあります。組織がインバウンドセッションアクセスを許可したい他のサービスがある場合があります。スタブルーターでよく知られているTUポートサービス[RFC 1700]を静的に構成することができ、プライベートネットワークの特定のノードに向けられます。
In addition to TCP/UDP sessions, ICMP messages, with the exception of REDIRECT message type may also be monitored by NAPT router. ICMP query type packets are translated similar to that of TCP/UDP packets, in that the identifier field in ICMP message header will be uniquely mapped to a query identifier of the registered IP address. The identifier field in ICMP query messages is set by Query sender and returned unchanged in response message from the Query responder. So, the tuple of (Local IP address, local ICMP query identifier) is mapped to a tuple of (registered IP address, assigned ICMP query Identifier) by the NAPT router to uniquely identify ICMP queries of all types from any of the local hosts. Modifications to ICMP error messages are discussed in a later section, as that involves modifications to ICMP payload as well as the IP and ICMP headers.
TCP/UDPセッションに加えて、リダイレクトメッセージタイプを除き、ICMPメッセージもNAPTルーターで監視できます。ICMPクエリタイプのパケットは、ICMPメッセージヘッダーの識別子フィールドが登録されたIPアドレスのクエリ識別子に一意にマッピングされるという点で、TCP/UDPパケットのパケットと同様に翻訳されます。ICMPクエリメッセージの識別子フィールドは、クエリ送信者によって設定され、クエリレスポンダーからの応答メッセージで変更されていません。したがって、NAPTルーターによって（ローカルIPアドレス、ローカルICMPクエリ識別子）のタプル（登録IPアドレス、割り当てられたICMPクエリ識別子）のタプルにマッピングされ、ローカルホストのあらゆるタイプのICMPクエリを一意に識別します。ICMPエラーメッセージの変更については、IPMPペイロードとIPおよびICMPヘッダーの変更が含まれるため、後のセクションで説明します。
In NAPT setup, where the registered IP address is the same as the IP address of the stub router WAN interface, the router has to be sure to make distinction between TCP, UDP or ICMP query sessions originated from itself versus those originated from the nodes on local network. All inbound sessions (including TCP, UDP and ICMP query sessions) are assumed to be directed to the NAT router as the end node, unless the target service port is statically mapped to a different node in the local network.
登録されたIPアドレスがスタブルーターWANインターフェイスのIPアドレスと同じNAPTセットアップでは、ルーターは、TCP、UDP、またはICMPクエリセッションとは、ノードのノードから生じるものとは区別する必要があります。ローカルネットワーク。すべてのインバウンドセッション（TCP、UDP、およびICMPクエリセッションを含む）は、ターゲットサービスポートがローカルネットワークの別のノードに静的にマッピングされない限り、エンドノードとしてNATルーターに向けられると想定されています。
Sessions other than TCP, UDP and ICMP query type are simply not permitted from local nodes, serviced by a NAPT router.
TCP、UDP、およびICMPクエリタイプ以外のセッションは、NAPTルーターでサービスを提供するローカルノードから単に許可されていません。
3.0. Translation phases of a session.
3.0. セッションの翻訳フェーズ。
The translation phases with traditional NAT are same as described in [NAT-TERM]. The following sub-sections identify items that are specific to traditional NAT.
従来のNATを使用した翻訳フェーズは、[NAT-Term]で説明されていると同じです。次のサブセクションは、従来のNATに固有のアイテムを識別します。
3.1. Address binding:
3.1. アドレスバインディング：
With Basic NAT, a private address is bound to an external address, when the first outgoing session is initiated from the private host. Subsequent to that, all other outgoing sessions originating from the same private address will use the same address binding for packet translation.
BASIC NATを使用すると、プライベートアドレスが外部アドレスにバインドされています。これは、最初の発信セッションがプライベートホストから開始されます。それに続いて、同じプライベートアドレスから発信される他のすべての発信セッションは、パケット翻訳に同じアドレスバインディングを使用します。
In the case of NAPT, where many private addresses are mapped to a single globally unique address, the binding would be from the tuple of (private address, private TU port) to the tuple of (assigned address, assigned TU port). As with Basic NAT, this binding is determined when the first outgoing session is initiated by the tuple of (private address, private TU port) on the private host. While not a common practice, it is possible to have an application on private host establish multiple simultaneous sessions originating from the
多くのプライベートアドレスが単一のグローバルに一意の住所にマッピングされているNAPTの場合、バインディングは（プライベートアドレス、プライベートTUポート）のタプルから（割り当てられたアドレス、割り当てられたTUポート）のタプルになります。Basic NATと同様に、このバインディングは、最初の発信セッションがプライベートホストの（プライベートアドレス、プライベートTUポート）のタプルによって開始されるときに決定されます。一般的な慣行ではありませんが、プライベートホストにアプリケーションを、次の複数の同時セッションを確立することができます。
same tuple of (private address, private TU port). In such a case, a single binding for the tuple of (private address, private TU port) may be used for translation of packets pertaining to all sessions originating from the same tuple on a host.
同じタプル（プライベートアドレス、プライベートTUポート）。そのような場合、（プライベートアドレス、プライベートTUポート）のタプルに対する単一のバインディングを使用すると、ホストの同じタプルから発生するすべてのセッションに関連するパケットの翻訳に使用できます。
3.2. Address lookup and translation:
3.2. アドレスルックアップと翻訳：
After an address binding or (address, TU port) tuple binding in case of NAPT is established, a soft state may be maintained for each of the connections using the binding. Packets belonging to the same session will be subject to session lookup for translation purposes. The exact nature of translation is discussed in the follow-on section.
NAPTの場合のアドレスバインディングまたは（アドレス、TUポート）タプルバインディングが確立された後、結合を使用して各接続に対してソフト状態を維持できます。同じセッションに属するパケットは、翻訳目的でセッション検索の対象となります。翻訳の正確な性質については、次のセクションで説明します。
3.3. Address unbinding:
3.3. アドレスアンバインディング：
When the last session based on an address or (address, TU port) tuple binding is terminated, the binding itself may be terminated.
アドレスまたは（アドレス、TUポート）タプルバインディングに基づく最後のセッションが終了すると、バインディング自体が終了する場合があります。
Packets pertaining to NAT managed sessions undergo translation in either direction. Individual packet translation issues are covered in detail in the following sub-sections.
NATマネージドセッションに関連するパケットは、いずれかの方向に翻訳を受けます。個々のパケット翻訳の問題は、次のサブセクションで詳細にカバーされています。
In Basic NAT model, the IP header of every packet must be modified. This modification includes IP address (source IP address for outbound packets and destination IP address for inbound packets) and the IP checksum.
Basic NATモデルでは、すべてのパケットのIPヘッダーを変更する必要があります。この変更には、IPアドレス（アウトバウンドパケットのソースIPアドレスとインバウンドパケットの宛先IPアドレス）とIPチェックサムが含まれます。
For TCP ([TCP]) and UDP ([UDP]) sessions, modifications must include update of checksum in the TCP/UDP headers. This is because TCP/UDP checksum also covers a pseudo header which contains the source and destination IP addresses. As an exception, UDP headers with 0 checksum should not be modified. As for ICMP Query packets ([ICMP]), no further changes in ICMP header are required as the checksum in ICMP header does not cover IP addresses.
TCP（[TCP]）およびUDP（[UDP]）セッションの場合、変更にはTCP/UDPヘッダーのチェックサムの更新を含める必要があります。これは、TCP/UDPチェックサムがソースおよび宛先IPアドレスを含む擬似ヘッダーもカバーしているためです。例外として、0チェックサムを持つUDPヘッダーを変更しないでください。ICMPクエリパケット（[ICMP]）については、ICMPヘッダーのチェックサムがIPアドレスをカバーしていないため、ICMPヘッダーのさらなる変更は必要ありません。
In NAPT model, modifications to IP header are similar to that of Basic NAT. For TCP/UDP sessions, modifications must be extended to include translation of TU port (source TU port for outbound packets and destination TU port for inbound packets) in the TCP/UDP header. ICMP header in ICMP Query packets must also be modified to replace the query ID and ICMP header checksum. Private host query ID must be
NAPTモデルでは、IPヘッダーの変更はBasic NATの変更に似ています。TCP/UDPセッションの場合、TCP/UDPヘッダーのTUポート（アウトバウンドパケット用のソースTUポートおよびインバウンドパケット用の宛先TUポート）の翻訳を含めるように変更を拡張する必要があります。ICMPクエリパケットのICMPヘッダーも変更して、クエリIDおよびICMPヘッダーチェックサムを置き換える必要があります。プライベートホストクエリIDは必要です
translated into assigned ID on the outbound and the exact reverse on the inbound. ICMP header checksum must be corrected to account for Query ID translation.
アウトバウンド上の割り当てられたIDに変換され、インバウンドの正確な逆に変換されます。ICMPヘッダーチェックサムは、クエリID翻訳を考慮して修正する必要があります。
NAT modifications are per packet based and can be very compute intensive, as they involve one or more checksum modifications in addition to simple field translations. Luckily, we have an algorithm below, which makes checksum adjustment to IP, TCP, UDP and ICMP headers very simple and efficient. Since all these headers use a one's complement sum, it is sufficient to calculate the arithmetic difference between the before-translation and after-translation addresses and add this to the checksum. The algorithm below is applicable only for even offsets (i.e., optr below must be at an even offset from start of header) and even lengths (i.e., olen and nlen below must be even). Sample code (in C) for this is as follows.
NATの変更はパケットベースごとにあり、単純なフィールド翻訳に加えて1つ以上のチェックサムの変更を伴うため、非常に計算される可能性があります。幸いなことに、以下にアルゴリズムがあります。これにより、IP、TCP、UDP、ICMPヘッダーへのチェックサムの調整が非常にシンプルで効率的になります。これらのヘッダーはすべて補完合計を使用しているため、翻訳前と翻訳後のアドレスの算術の違いを計算し、これをチェックサムに追加するだけで十分です。以下のアルゴリズムは、偶数オフセット（つまり、以下のOPTRはヘッダーの開始から均等にオフセットする必要があります）にのみ適用され、偶数の長さ（つまり、以下のOlenとNlenは偶数でなければなりません）。これについては、サンプルコード（c）は次のとおりです。
void checksumadjust(unsigned char *chksum, unsigned char *optr,
int olen, unsigned char *nptr, int nlen)
/* assuming: unsigned char is 8 bits, long is 32 bits.
- chksum points to the chksum in the packet
- optr points to the old data in the packet
- nptr points to the new data in the packet
*/
{
long x, old, new;
x=chksum[0]*256+chksum[1];
x=~x & 0xFFFF;
while (olen)
{
old=optr[0]*256+optr[1]; optr+=2;
x-=old & 0xffff;
if (x<=0) { x--; x&=0xffff; }
olen-=2;
}
while (nlen)
{
new=nptr[0]*256+nptr[1]; nptr+=2;
x+=new & 0xffff;
if (x & 0x10000) { x++; x&=0xffff; }
nlen-=2;
}
x=~x & 0xFFFF;
chksum[0]=x/256; chksum[1]=x & 0xff;
}
Changes to ICMP error message ([ICMP]) will include changes to IP and ICMP headers on the outer layer as well as changes to headers of the packet embedded within the ICMP-error message payload.
ICMPエラーメッセージ（[ICMP]）の変更には、外側層のIPおよびICMPヘッダーの変更と、ICMPエラーメッセージペイロード内に埋め込まれたパケットのヘッダーの変更が含まれます。
In order for NAT to be transparent to end-host, the IP address of the IP header embedded within the payload of ICMP-Error message must be modified, the checksum field of the embedded IP header must be modified, and lastly, the ICMP header checksum must also be modified to reflect changes to payload.
NATを透明にするには、ICMP-Errorメッセージのペイロード内に埋め込まれたIPヘッダーのIPアドレスを変更する必要があり、埋め込まれたIPヘッダーのチェックサムフィールドを変更する必要があり、最後にICMPヘッダーを変更する必要があります。また、ペイロードの変更を反映するためにチェックサムを変更する必要があります。
In a NAPT setup, if the IP message embedded within ICMP happens to be a TCP, UDP or ICMP Query packet, you will also need to modify the appropriate TU port number within the TCP/UDP header or the Query Identifier field in the ICMP Query header.
NAPTセットアップでは、ICMPに埋め込まれたIPメッセージがたまたまTCP、UDP、またはICMPクエリパケットである場合、TCP/UDPヘッダー内の適切なTUポート番号またはICMPクエリ内のクエリ識別子フィールドを変更する必要があります。ヘッダ。
Lastly, the IP header of the ICMP packet must also be modified.
最後に、ICMPパケットのIPヘッダーも変更する必要があります。
One of the most popular applications, "FTP" ([FTP]) would require an ALG to monitor the control session payload to determine the ensuing data session parameters. FTP ALG is an integral part of most NAT implementations.
最も人気のあるアプリケーションの1つである「FTP」（[FTP]）は、コントロールセッションのペイロードを監視して、次のデータセッションパラメーターを決定するためのALGを必要とします。FTPアルグは、ほとんどのNAT実装の不可欠な部分です。
The FTP ALG would require a special table to correct the TCP sequence and acknowledge numbers with source port FTP or destination port FTP. The table entries should have source address, destination address, source port, destination port, delta for sequence numbers and a timestamp. New entries are created only when FTP PORT commands or PASV responses are seen. The sequence number delta may be increased or decreased for every FTP PORT command or PASV response. Sequence numbers are incremented on the outbound and acknowledge numbers are decremented on the inbound by this delta.
FTP ALGは、TCPシーケンスを修正し、ソースポートFTPまたは宛先ポートFTPで数値を確認するための特別なテーブルが必要です。テーブルエントリには、ソースアドレス、宛先アドレス、ソースポート、宛先ポート、シーケンス番号、タイムスタンプ用のデルタが必要です。新しいエントリは、FTPポートコマンドまたはPASV応答が見られた場合にのみ作成されます。シーケンス番号Deltaは、FTPポートコマンドまたはPASV応答ごとに増加または減少する場合があります。シーケンス番号はアウトバウンドで増加し、このデルタによってインバウンドで減少することを確認します。
FTP payload translations are limited to private addresses and their assigned external addresses (encoded as individual octets in ASCII) for Basic NAT. For NAPT setup, however, the translations must be extended to include the TCP port octets (in ASCII) following the address octets.
FTPペイロード翻訳は、基本NATのために、プライベートアドレスと割り当てられた外部アドレス（ASCIIの個々のオクテットとしてエンコード）に限定されています。ただし、NAPTセットアップの場合、アドレスオクテットに続いてTCPポートオクテット（ASCII）を含めるように翻訳を拡張する必要があります。
Considering that sessions in a traditional NAT are predominantly outbound from a private domain, DNS ALG may be obviated from use in conjunction with traditional NAT as follows. DNS server(s) internal to the private domain maintain mapping of names to IP addresses for
従来のNATのセッションが主にプライベートドメインからのアウトバウンドであることを考慮すると、DNSアルグは、従来のNATとの使用から次のように除外される可能性があります。プライベートドメインの内部のDNSサーバーは、名前のマッピングをIPアドレスに維持します
internal hosts and possibly some external hosts. External DNS servers maintain name mapping for external hosts alone and not for any of the internal hosts. If the private network does not have an internal DNS server, all DNS requests may be directed to external DNS server to find address mapping for the external hosts.
内部ホストおよび場合によっては一部の外部ホスト。外部DNSサーバーは、外部ホストのみの名前マッピングを維持し、内部ホストのいずれでもありません。プライベートネットワークに内部DNSサーバーがない場合、すべてのDNS要求を外部DNSサーバーに向けて、外部ホストのアドレスマッピングを見つけることができます。
An IP datagram with any of the IP options Record Route, Strict Source Route or Loose Source Route would involve recording or using IP addresses of intermediate routers. A NAT intermediate router may choose not to support these options or leave the addresses untranslated while processing the options. The result of leaving the addresses untranslated would be that private addresses along the source route are exposed end to end. This should not jeopardize the traversal path of the packet, per se, as each router is supposed to look at the next hop router only.
IPオプションレコードルート、厳密なソースルート、またはルーズソースルートのいずれかのIPデータグラムには、中間ルーターのIPアドレスの記録または使用が含まれます。NAT中間ルーターは、これらのオプションをサポートしないか、オプションの処理中に翻訳されていないアドレスのままにすることを選択できます。翻訳されていないアドレスを残した結果は、ソースルートに沿ったプライベートアドレスが端から端まで公開されていることです。各ルーターは次のホップルーターのみを見ることになっているため、パケットのトラバーサルパス自体を危険にさらすことはありません。
For NAT to operate as described in this document, it is necessary to partition the IP address space into two parts - the private addresses used internal to stub domain, and the globally unique addresses. Any given address must either be a private address or a global address. There is no overlap.
このドキュメントで説明されているようにNATが動作するには、IPアドレススペースを2つの部分に分割する必要があります。特定の住所は、プライベートアドレスまたはグローバルアドレスでなければなりません。オーバーラップはありません。
The problem with overlap is the following. Say a host in stub A wished to send packets to a host in stub B, but the global addresses of stub B overlapped the private addressees of stub A. In this case, the routers in stub A would not be able to distinguish the global address of stub B from its own private addresses.
オーバーラップの問題は次のとおりです。スタブAのホストがスタブBのホストにパケットを送信したいと言いますが、スタブBのグローバルアドレスはスタブAのプライベートアドレスに重なりました。この場合、スタブAのルーターはグローバルアドレスを区別することができません。独自のプライベートアドレスからのスタブBの。
[RFC 1918] has recommendations on address space allocation for private networks. Internet Assigned Numbers Authority (IANA) has three blocks of IP address space, namely 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private internets. In pre-CIDR notation, the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B networks, and the third block is a set of 256 contiguous class C networks.
[RFC 1918]は、プライベートネットワークの住所スペース割り当てに関する推奨事項があります。インターネットが割り当てられた番号当局（IANA）には、3つのブロックのIPアドレススペースがあります。つまり、プライベートインターネットの場合、10.0.0.0/8、172.16.0.0/12、および192.168.0.0/16があります。Pre-CIDR表記では、最初のブロックは単一のクラスAネットワーク番号にすぎませんが、2番目のブロックは16の連続したクラスBネットワークのセットであり、3番目のブロックは256連続クラスCネットワークのセットです。
An organization that decides to use IP addresses in the address space defined above can do so without any coordination with IANA or an Internet registry. The address space can thus be used privately by
上記のアドレススペースでIPアドレスを使用することを決定した組織は、IANAやインターネットレジストリとの調整なしにそうすることができます。したがって、アドレススペースは個人的に使用できます
many independent organizations at the same time, with NAT operation enabled on their border routers.
同時に多くの独立した組織と、NATの操作が国境ルーターで有効になっています。
The router running NAT should not advertise the private networks to the backbone. Only the networks with global addresses may be known outside the stub. However, global information that NAT receives from the stub border router can be advertised in the stub the usual way.
NATを実行しているルーターは、バックボーンにプライベートネットワークを宣伝しないでください。グローバルアドレスを持つネットワークのみが、スタブの外側で知られる場合があります。ただし、Stub Border RouterからNATが受け取るグローバルな情報は、通常の方法でスタブで宣伝することができます。
Typically, the NAT stub router will have a static route configured to forward all external traffic to service provider router over WAN link, and the service provider router will have a static route configured to forward NAT packets (i.e., those whose destination IP address fall within the range of NAT managed global address list) to NAT router over WAN link.
通常、NATスタブルーターには、すべての外部トラフィックをWANリンク上のサービスプロバイダールーターに転送するように構成された静的ルートがあり、サービスプロバイダールーターには、NATパケットを転送する静的ルートが構成されています（つまり、宛先IPアドレスが該当するものがあります。NATマネージドグローバルアドレスリストの範囲）は、WANリンク上のNATルーターへ。
In Basic NAT setup, when private network nodes outnumber global addresses available for mapping (say, a class B private network mapped to a class C global address block), external network access to some of the local nodes is abruptly cut off after the last global address from the address list is used up. This is very inconvenient and constraining. Such an incident can be safely avoided by optionally allowing the Basic NAT router to switch over to NAPT setup for the last global address in the address list. Doing this will ensure that hosts on private network will have continued, uninterrupted access to the external nodes and services for most applications. Note, however, it could be confusing if some of the applications that used to work with Basic NAT suddenly break due to the switch-over to NAPT.
基本NATセットアップでは、プライベートネットワークノードがマッピングに利用できるグローバルアドレスを上回ると（たとえば、クラスCグローバルアドレスブロックにマッピングされたクラスBプライベートネットワーク）、ローカルノードの一部への外部ネットワークアクセスは、最後のグローバルの後に突然遮断されますアドレスリストからのアドレスが使い果たされます。これは非常に不便で制約です。このようなインシデントは、オプションで基本的なNATルーターがアドレスリストの最後のグローバルアドレスのNAPTセットアップに切り替えることができることにより、安全に回避できます。これを行うことで、プライベートネットワーク上のホストが、ほとんどのアプリケーションの外部ノードとサービスへの継続的で途切れないアクセスを保証します。ただし、NAPTへの切り替えのためにBasic NATを使用していたアプリケーションの一部が突然破損した場合、混乱する可能性があります。
[NAT-TERM] covers the limitations of all flavors of NAT, broadly speaking. The following sub-sections identify limitations specific to traditional NAT.
[NAT-Term]は、大まかに言えば、NATのすべてのフレーバーの制限をカバーしています。次のサブセクションは、従来のNATに固有の制限を特定します。
Traditional NAT can be viewed as providing a privacy mechanism as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts.
従来のNATは、プライバシーメカニズムを提供すると見なすことができます。セッションはプライベートホストからの一方向であり、プライベートホストの実際のアドレスは外部ホストには見えません。
The same characteristic that enhances privacy potentially makes debugging problems (including security violations) more difficult. If a host in private network is abusing the Internet in some way (such
プライバシーを強化するのと同じ特性により、デバッグの問題（セキュリティ違反を含む）がより困難になります。プライベートネットワークのホストが何らかの方法でインターネットを乱用している場合（そのような
as trying to attack another machine or even sending large amounts of spam) it is more difficult to track the actual source of trouble because the IP address of the host is hidden in a NAT router.
別のマシンを攻撃しようとしたり、大量のスパムを送信しようとしているため）ホストのIPアドレスがNATルーターに隠されているため、実際のトラブルの原因を追跡することがより困難です。
NAT must be enabled only on border routers of a stub domain. The examples provided in the document to illustrate Basic NAT and NAPT have maintained a WAN link for connection to external router (i.e., service provider router) from NAT router. However, if the WAN link were to be replaced by a LAN connection and if part or all of the global address space used for NAT mapping belongs to the same IP subnet as the LAN segment, the NAT router would be expected to provide ARP support for the address range that belongs to the same subnet. Responding to ARP requests for the NAT mapped global addresses with its own MAC address is a must in such a situation with Basic NAT setup. If the NAT router did not respond to these requests, there is no other node in the network that has ownership to these addresses and hence will go unresponded.
NATは、スタブドメインの境界ルーターでのみ有効にする必要があります。基本的なNATとNAPTを説明するためにドキュメントで提供されている例は、NATルーターの外部ルーター（つまり、サービスプロバイダールーター）への接続のためのWANリンクを維持しています。ただし、WANリンクがLAN接続に置き換えられ、NATマッピングに使用されるグローバルアドレススペースの一部またはすべてがLANセグメントと同じIPサブネットに属している場合、NATルーターはARPサポートを提供すると予想されます。同じサブネットに属するアドレス範囲。基本的なNATセットアップを備えたこのような状況では、独自のMACアドレスを使用して、NATマッピングされたグローバルアドレスのARPリクエストに応答することは必須です。NATルーターがこれらの要求に応答しなかった場合、ネットワークにこれらのアドレスに所有権を持つ他のノードはありません。
This scenario is unlikely with NAPT setup except when the single address used in NAPT mapping is not the interface address of the NAT router (as in the case of a switch-over from Basic NAT to NAPT explained in 5.4 above, for example).
このシナリオは、NAPTマッピングで使用されている単一のアドレスがNATルーターのインターフェイスアドレスではない場合を除き、NAPTセットアップではほとんどありません（たとえば、上記5.4で説明されている基本NATからNAPTへのスイッチオーバーの場合のように）。
Using an address range from a directly connected subnet for NAT address mapping would obviate static route configuration on the service provider router.
NATアドレスマッピング用の直接接続されたサブネットのアドレス範囲を使用すると、サービスプロバイダールーターの静的ルート構成がなくなります。
It is the opinion of the authors that a LAN link to a service provider router is not very common. However, vendors may be interested to optionally support proxy ARP just in case.
サービスプロバイダールーターへのLANリンクがあまり一般的ではないというのは、著者の意見です。ただし、ベンダーは、念のため、オプションでプロキシARPをサポートすることに関心がある場合があります。
Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT setup are doomed to fail. The reason is as follows. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted.
NAPTセットアップにおけるアウトバウンドTCP/UDPフラグメント（つまり、プライベートホストから発生したもの）の翻訳は失敗する運命にあります。その理由は次のとおりです。最初のフラグメントのみに、翻訳目的でパケットをセッションに関連付けるために必要なTCP/UDPヘッダーが含まれています。後続のフラグメントには、TCP/UDPポート情報は含まれていませんが、最初のフラグメントで指定された同じフラグメンテーション識別子を単純に運ぶだけです。たとえば、2人のプライベートホストが断片化されたTCP/UDPパケットを同じ宛先ホストに発信しました。そして、彼らはたまたま同じ断片化識別子を使用していました。ターゲットホストが同じ断片化IDを運ぶ2つの無関係なデータグラムを受信し、同じ割り当てられたホストアドレスから受信すると、データグラムが属する2つのセッションのどれを決定できません。その結果、両方のセッションが破損します。
Many commercial implementations are available in the industry that adhere to the NAT description provided in this document. Linux public domain software contains NAT under the name of "IP masquerade". FreeBSD public domain software has NAPT implementation running as a daemon. Note however that Linux source is covered under the GNU license and FreeBSD software is covered under the UC Berkeley license.
このドキュメントで提供されているNATの説明を順守する業界では、多くの商業実装が利用可能です。Linuxパブリックドメインソフトウェアには、「IPマスカレード」という名前のNATが含まれています。FreeBSDパブリックドメインソフトウェアには、デーモンとして実行されているNAPT実装があります。ただし、LinuxソースはGNUライセンスの対象であり、FreeBSDソフトウェアはUC Berkeleyライセンスの対象であることに注意してください。
Both Linux and FreeBSD software are free, so you can buy CD-ROMs for these for little more than the cost of distribution. They are also available on-line from a lot of FTP sites with the latest patches.
LinuxとFreeBSDソフトウェアの両方が無料なので、これらのCD-ROMを配布コスト以上で購入できます。また、最新のパッチを備えた多くのFTPサイトからオンラインで利用できます。
The security considerations described in [NAT-TERM] for all variations of NATs are applicable to traditional NAT.
NATのすべてのバリエーションについて[NAT-Term]で説明されているセキュリティ上の考慮事項は、従来のNATに適用できます。
References
参考文献
[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月。
[RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC 1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC 1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[RFC 1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC 1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[FTP] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", STD 9, RFC 959, October 1985.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル（FTP）」、STD 9、RFC 959、1985年10月。
[TCP] Defense Advanced Research Projects Agency Information Processing Techniques Office, "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", STD 7, RFC 793, September 1981.
[TCP]防衛高度な研究プロジェクト機関情報処理手法、「トランスミッションコントロールプロトコル（TCP）仕様」、STD 7、RFC 793、1981年9月。
[ICMP] Postel, J., "INTERNET CONTROL MESSAGE (ICMP) SPECIFICATION", STD 5, RFC 792, September 1981.
[ICMP] Postel、J。、「インターネット制御メッセージ（ICMP）仕様」、STD 5、RFC 792、1981年9月。
[UDP] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[UDP] Postel、J。、「ユーザーデータグラムプロトコル（UDP）」、STD 6、RFC 768、1980年8月。
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC 2101] Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
Authors' Addresses
著者のアドレス
Pyda Srisuresh Jasmine Networks, Inc. 3061 Zanker Road, Suite B San Jose, CA 95134 U.S.A.
Pyda Srisuresh Jasmine Networks、Inc。3061 Zanker Road、Suite B San Jose、CA 95134 U.S.A.
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
電話：（408）895-5032メール：srisuresh@yahoo.com
Kjeld Borch Egevang Intel Denmark ApS
Kjeld Borch Egevang Intel Denmark APS
Phone: +45 44886556
Fax: +45 44886051
EMail: kjeld.egevang@intel.com
http: //www.freeyellow.com/members/kbe
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明するか、その実装を支援する派生作品は、いかなる種類の制限なしに、準備、コピー、公開、配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。