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)
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.
著作権（C）インターネット協会（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アドレスを持っています。リモートアクセスユーザーのこの増え続ける社会は、同時に自分のルータに割り当てられた単一のIPアドレスを使用してリモートネットワークにアクセスするために、ローカルネットワーク内の複数のノードを可能にするNAPTによって恩恵を受けられます。
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ルータを経由してルーティングされることが必須です。これを確認する一つの方法は、すべてのIPパケットがいずれかのドメインから発信またはドメイン宛てのスタブドメインに固有である境界ルータに基づいてNATを持っているだろう。複数のNATデバイスでこれを確保するための他の方法があります。例えば、プライベートドメインは、異なるプロバイダに二つの別個の出口点を有する可能性があり、プライベートネットワーク内のホストからのセッションフローは、NATデバイスは外部のホストのための最高のメトリックを有する方を通って横断することができました。 NATルータの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を無効にするだろうと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 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.
このソリューションは、IPアドレスのエンド・ツー・エンドの重要性を奪う、およびネットワークにおける増加した状態でそれを補うという欠点があります。結果として、IPSecで保証エンド・ツー・エンドのIPネットワーク・レベルのセキュリティは、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ポート」、「ALG」等、のような用語の定義は、[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はNAPTでの翻訳は、IPアドレスとトランスポート識別子を含むように拡張されたのに対し、IPに限定されている基本的なNATのその訳で、一人で対処し、伝統的なNATの2つのバリエーションです（例えば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 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.
次のように基本的なNATの動作です。プライベートネットワークアドレスのセットとスタブドメインは動的にグローバルで有効なネットワークアドレスのセットにプライベートアドレスのセットをマッピングすることにより、外部のネットワークと通信するために有効にすることができます。ローカルノードの数がより少ないまたはグローバルセットのアドレスに等しい場合、各ローカルアドレスは、グローバルアドレスをにマッピングすることが保証されています。それ以外の場合は、外部ネットワークへの同時アクセスを持つことが許されたノードは、グローバルセット内のアドレスの数によって制限されています。個々のローカルアドレスは、静的外部に保証アクセスを確保するために、または固定のパブリックアドレスを介して外部ホストからローカルホストへのアクセスを許可する特定のグローバルアドレスにマッピングすることができます。複数の同時セッションが同じアドレスマッピングを使用して、ローカル・ノードから開始されてもよいです。
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の両方が内部クラスプライベートアドレスブロック10.0.0.0/8 [RFC 1918]を使用します。スタブAのNATは、クラスCアドレスブロック198.76.29.0/24を割り当てられ、スタブBのNATは、クラスCアドレスブロック198.76.28.0/24を割り当てられています。他のNAT箱がそれらを使用することはできませんクラスCアドレスはグローバルにユニークです。
\ | /
+---------------+
|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.
Bホスト10.81.13.22をスタブにパケットを送信したい10.33.96.5ホストをスタブすると、それは宛先としてグローバルに一意のアドレス198.76.28.4を使用し、そのプライマリルータにパケットを送信します。スタブルータは、そのパケットがWANリンクに転送され、ネット198.76.0.0の静的ルートを持っています。パケットが転送される前に、しかし、NATは、グローバルに一意198.76.29.7にIPヘッダの送信元アドレス10.33.96.5を変換します。同様に、リターンパス上の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.
これは、ホストやルーターを変更する必要はありませんことに注意してください。例えば、限りホストに関してはスタブとして、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の助けを借りて、1つの登録済み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の例では、スタブ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が138.76.29.7をホストするためのtelnetパケットを送信し、それが宛先としてグローバルに一意のアドレス138.76.29.7を使用し、それはプライマリルータだにパケットを送信します。スタブルータは、サブネット138.76.0.0/16の静的ルートを持っているので、パケットがWANリンクに転送されます。パケットが転送される前に、しかし、NAPTは138.76.28.4グローバルに一意と一意に割り当てられたTCPポートへのIPおよびTCPヘッダの送信元アドレス10.0.0.10とソースTCPポート3017のタプルを翻訳し、1024年を言います。復路のパケットは、ターゲット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.
REDIRECTメッセージタイプを除いて、TCP / UDPセッション、ICMPメッセージ、に加えて、NAPTルータによって監視することができます。 ICMPメッセージヘッダ内の識別子フィールドが一意に登録されたIPアドレスの問合せ識別子にマッピングされることにICMP問合せタイプパケットは、TCP / UDPパケットのと同様に翻訳されます。 ICMPクエリーメッセージ内の識別子フィールドには、クエリの送信者によって設定され、クエリの応答者からの応答メッセージにそのまま返されます。だから、（ローカルIPアドレス、ローカルICMP問合せ識別子）のタプルは一意のローカルホストのいずれかからすべてのタイプのICMPクエリを識別するためにNAPTルータが（登録されたIPアドレス、割り当てられたICMP問合せ識別子）の組にマッピングされます。すなわち、ICMPペイロードの修正ならびにIPとICMPヘッダを含むように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ルータによってサービスのローカル・ノードから許可されていません。
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-TERM]で説明したように、伝統的なNATと翻訳段階は同じです。以下のサブセクションでは、伝統的なNATに固有の項目を識別します。
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.
最初の発信セッションがプライベートホストから開始された場合の基本的な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 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.
多くのプライベートアドレスを単一のグローバルにユニークなアドレスにマッピングされるNAPTの場合には、結合は、（プライベートアドレス、プライベートTUポート）のタプルから（TUポートを割り当て、割り当てられたアドレス）のタプルになるであろう。最初の発信セッションがプライベートホスト上のタプル（プライベートアドレス、プライベートTUポート）によって開始されたときの基本的なNATと同じように、この結合が決定されます。一般的ではありませんが、（プライベートアドレス、プライベートTUポート）の同じタプルに起因する複数の同時セッションを確立するプライベートホスト上のアプリケーションを持つことが可能です。このような場合には、（プライベートアドレス、プライベートTUポート）のタプルのための単一の結合は、ホスト上の同じタプルから開始されたすべてのセッションに関連するパケットの変換に使用することができます。
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ポート）が確立された後、柔らかい状態は、結合を使用して、接続のそれぞれのために維持することができます。同じセッションに属するパケットは、翻訳の目的のためにセッションルックアップの対象となります。翻訳の正確な性質は、後続のセクションで説明されています。
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.
基本的な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ヘッダ内のチェックサムはIPアドレスをカバーしていないとしてICMPクエリパケット（[ICMP]）については、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 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.
NAPTモデルでは、IPヘッダの修正は基本NATと同様です。 TCP / UDPセッションでは、修飾は、TCP / UDPヘッダにおける（発信パケットおよび着信パケットの宛先TUポートのソースTUポート）TUポートの翻訳を含むように拡張されなければなりません。 ICMPクエリパケット内のICMPヘッダはまた、クエリIDとICMPヘッダのチェックサムを交換するように修正されなければなりません。プライベートホストクエリーIDは、アウトバウンドとインバウンド上の正確な逆に割り当てられた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ヘッダにチェックサムの調整を行い、以下のアルゴリズムを持っています。すべてのこれらのヘッダは1の補数和を使用しているので、翻訳の前と後に、翻訳アドレス間の算術の差を計算し、チェックサムにこれを追加するのに十分です。以下のアルゴリズムは、偶数のオフセット（すなわち、以下OPTRもヘッダの先頭からのオフセットでなければならない）、さらに長さ（すなわち、オレン以下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]）への変更は、ICMPエラーメッセージのペイロード内に埋め込まれたパケットのヘッダに外層上のIPおよび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-エラーメッセージのペイロード内に埋め込まれた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.
ICMP内に埋め込まれたIPメッセージがあることを起こる場合NAPT設定では、TCPは、UDPまたはICMPクエリパケットが、あなたはまた、ICMPクエリでのTCP / UDPヘッダまたはクエリ識別子フィールド内の適切なTUポート番号を変更する必要がありますヘッダ。
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.
最も人気のあるアプリケーションの一つ、「FTP」（[FTP]）はその後、データセッションパラメータを決定するために、制御セッションペイロードを監視するためにALGを必要とするであろう。 FTP ALGは、ほとんどの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 PORTコマンドまたはPASV応答が見られる場合にのみ作成されます。シーケンス番号デルタは増加またはすべてのFTP PORTコマンドまたは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の設定については、しかし、翻訳はアドレスオクテット以下（ASCIIで）TCPポートのオクテットを含むように拡張されなければなりません。
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 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.
次のように伝統的なNAT内のセッションがプライベートドメインから優先的に発信していることを考慮すると、DNS ALGは、従来のNATと組み合わせて使用することから回避することができます。プライベートドメインへの内部DNSサーバ（複数可）内部ホストおよびおそらくいくつかの外部のホストのIPアドレスに名前のマッピングを維持します。外部の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アドレス空間を分割する必要があります。任意のアドレスはどちらかプライベートアドレスまたはグローバルアドレスでなければなりません。重複はありません。
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（Internet Assigned Numbers Authority）のIPアドレス空間、すなわち10.0.0.0/8、172.16.0.0/12、民間のインターネットのための192.168.0.0/16の三つのブロックがあります。第二のブロックは、16の連続したクラスBのネットワークの集合であり、第3ブロックは256の連続したクラスCネットワークの設定されている間プレCIDR表記で、最初のブロックは、単一のクラスのネットワーク番号に過ぎません。
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 many independent organizations at the same time, with NAT operation enabled on their border routers.
上記で定義されたアドレス空間内のIPアドレスを使用することを決定した組織は、IANAまたはインターネットレジストリといかなる調整なしそうすることができます。アドレス空間は、このように彼らの境界ルータ上で有効に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を実行しているルータは、バックボーンにプライベートネットワークをアドバタイズべきではありません。グローバルアドレスを持つ唯一のネットワークがスタブの外に知られていてもよいです。しかし、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.
プライベートネットワークノードは（たとえば、クラスBのプライベートネットワークはクラスCのグローバルアドレスブロックにマッピングされた）マッピングのためにローカルノードの一部に、外部ネットワークへのアクセスを可能なグローバルアドレスを上回ったときに基本的なNATの設定では、突然最後のグローバル後に切断されますアドレスリストからアドレスが使い果たされます。これは非常に不便と制約です。このような事件が安全に、必要に応じて基本的なNATルータがアドレスリストの最後のグローバルアドレスをNAPT設定に切り替えるようにすることによって回避することができます。こうすることで、プライベートネットワーク上のホストは、ほとんどのアプリケーションのための外部ノードとサービスへの中断のないアクセスを続けているだろうことを保証します。基本的なNATで動作するように使用されるアプリケーションの一部が突然によるNAPTへの切り替えに壊れた場合注は、しかし、それは混乱を招く可能性があります。
[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リンクを維持しています。しかし、LAN接続によって置換されるWANリンクがされた場合や一部またはNATマッピングに使用されるグローバルアドレス空間のすべてが、LANセグメントと同じIPサブネットに属している場合、NATルータがためにARPのサポートを提供することが期待されます同じサブネットに属しているアドレスの範囲。自身のMACアドレスとグローバルアドレスをマッピングされたNATのためのARP要求に応答することは基本的なNATの設定とそのような状況では必須です。 NATルータは、これらの要求に応答しなかった場合は、unresponded行きますので、これらのアドレスへの所有権を持っており、ネットワーク内の他のノードがありません。
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).
このシナリオでは、（ベーシックNATからNAPTの切り替えの場合には、例えば、上記5.4で説明したように）NAPTマッピングで使用される単一のアドレスが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.
アウトバウンドTCP / UDPの断片の翻訳は（すなわち、プライベートホストから発信されるもの）NAPT設定では、失敗する運命にあります。その理由は以下の通りです。唯一の最初のフラグメントは、翻訳の目的のためにセッションにパケットを関連付けることが必要であろう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バークレーライセンスの下で覆われていることに注意してください。
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.ホールドレッジ、 "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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC 1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[RFC 1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1122]ブレーデン、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]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC 1812]、RFC 1812、1995年6月ベイカー、F.、 "IPバージョン4つのルータのための要件"。
[FTP] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", STD 9, RFC 959, October 1985.
[FTP]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル（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]ポステル、J.、 "インターネット制御メッセージ（ICMP）仕様"、STD 5、RFC 792、1981年9月。
[UDP] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[UDP]ポステル、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]大工、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、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ジャスミンネットワークス株式会社3061 Zanker道路、スイートBサンノゼ、CA 95134 U.S.A.
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
電話：（408）895-5032 Eメール：srisuresh@yahoo.com
Kjeld Borch Egevang Intel Denmark ApS
ドゥイツボルフEgevangインテルデンマークApSは
Phone: +45 44886556 Fax: +45 44886051 EMail: kjeld.egevang@intel.com http: //www.freeyellow.com/members/kbe
電話：+45 44886556ファックス：+45 44886051 Eメール：kjeld.egevang@intel.comます。http：//www.freeyellow.com/members/kbe
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。