RFC3022 日本語訳
3022 Traditional IP Network Address Translator (Traditional NAT). P.Srisuresh, K. Egevang. January 2001. (Format: TXT=37675 bytes) (Obsoletes RFC1631) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Srisuresh
Request for Comments: 3022 Jasmine Networks
Obsoletes: 1631 K. Egevang
Category: Informational Intel Corporation
January 2001
Srisureshがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3022のジャスミンネットワークが以下を時代遅れにします。 1631年のK.Egevangカテゴリ: 情報のインテル社2001年1月
Traditional IP Network Address Translator (Traditional NAT)
伝統的なIPネットワークアドレス変換機構(伝統的なNAT)
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
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操作は、RFC1631で導入されたアドレス変換を広げていて、新しいタイプに関するネットワーク・アドレスとTCP/UDPポート翻訳を含んでいます。 さらに、このドキュメントは、RFC1631で発行されたChecksum調整アルゴリズムを修正して、詳細に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.
基本的なNetwork Address TranslationかBasic NATがIPアドレスが1つのグループから別のグループまで写像されるメソッドです、エンドユーザにとって、透明です。 Address Port Translationをネットワークでつないでください。さもないと、NAPTは多くのネットワーク・アドレスとそれらのTCP/UDP(通信制御プロトコル/ユーザー・データグラム・プロトコル)ポートがただ一つのネットワーク・アドレスとそのTCP/UDPポートに移されるメソッドです。 伝統的なNATと呼ばれたこれらの2つの操作が、グローバルにユニークな登録されたアドレスで外部の分野へのプライベート・アドレスに分野を接続するためにメカニズムを一緒に、提供します。
1. Introduction
1. 序論
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 Address翻訳の必要性は起こります。
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
局所領域の外のネットワーク形態は様々な意味で変化できます。 顧客がプロバイダーを変えるかもしれなくて、会社のバックボーンが再編成されるかもしれないか、またはプロバイダーは、合併するか、分かれるかもしれません。 外部のトポロジーが変化するときはいつも
Srisuresh & Egevang Informational [Page 1] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[1ページ]のRFC3022
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.
基本のAddress翻訳で、私設のネットワークのホストは、透過的に外部のネットワークにアクセスして、外部から選択能力があるローカル・ホストへのアクセスを可能にするでしょう(このドキュメントの[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.
多くのSmallオフィス、内務省(ソーホー)のユーザ、および在宅勤務従業員はそれらのオフィスに複数のNetworkノードを持っています、TCP/UDPアプリケーションを実行してそれらのサービスプロバイダーにリモートネットワークにアクセスするためにただ一つのIPアドレスをそれらの遠隔アクセスのルータに割り当てさせて。 遠隔アクセスのユーザのこの増加し続けている共同体はNAPTによってためになられるでしょう。(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つの方法はNATをすべてのIPパケットがドメインから溯源されるか、またはそのドメインに運命づけられているスタッブドメインにユニークな境界ルータに基づかせているだろうことです。 複数のNATデバイスでこれを確実にする他の方法があります。 例えば、個人的なドメインには、私設のネットワークのホストからの流れがベストを外部のホストにとってメートル法にするどのNATデバイスを通して横断できた異なったプロバイダーとセッションまで2つの異なったエキジットポイントがあるかもしれません。 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.
アドレス変換はアプリケーションから独立していて、アプリケーションの特定のゲートウェイ(ALGs)によってしばしば伴われて、ペイロードモニターと変更を実行します。 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
このソリューションには、終わりから終わりへのIPアドレスの意味を持ち去って、ネットワークで増強された状態でそれの埋め合わせをする不都合があります。 結果、終わりから終わりへのIPネットワークレベルとして
Srisuresh & Egevang Informational [Page 2] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[2ページ]のRFC3022
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ポート」や、"ALG"や他のものなどの用語の定義は[ナット-用語]で見つけられるかもしれません。
2. Overview of traditional NAT
2. 伝統的なNATの概要
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).
本書では提示されたAddress Translation操作は「伝統的なNAT」と呼ばれます。 本書では探検されないNATの他の変化があります。 多くの場合、伝統的なNATで、外部のネットワークで私設のネットワークの中のホストは透過的にホストにアクセスできるでしょう。 伝統的なNATでは、セッションは、uni方向上であって、私設のネットワークから外国行きです。 逆方向へのセッションは、例外的ベースで前選択されたホストに静的なアドレス地図を使用することで許容されるかもしれません。 基本的なNATとNAPTは伝統的なNATの2回の変化です、NAPTの翻訳がIPアドレスとTransport識別子(TCP/UDPポートかICMP質問IDなどの)を含むように広げられてBasic NATにおける翻訳が単独でIPアドレスに制限されるので。
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.
別の方法で言及されないと、このドキュメント中のAddress TranslationかNATがNAPTと同様にすなわち、伝統的なNAT、Basic NATに関係するでしょう。 アドレス変換を実行するために以下の1図で説明されるスタッブ境界ルータだけを構成してもよいです。
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
\ | / . / +---------------+ WAN+-----------------+/ |地方のルータ|----------------------|NATがあるスタッブルータ|--- +---------------+ . +-----------------+\ . | \ . | ラン。--------------- スタッブ境界
Figure 1: Traditional NAT Configuration
図1: 伝統的なNAT構成
2.1 Overview of Basic NAT
2.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操作は以下の通りです。 1セットの個人的なネットワーク・アドレスがあるスタッブドメインがダイナミックに1セットのグローバルに有効なネットワーク・アドレスにプライベート・アドレスのセットを写像することによって外部のネットワークとコミュニケートするのを可能にすることができました。 写像するグローバルアドレスはグローバルなセットによりアドレスがローカルのノードの数であるならあるのが各ローカルアドレスに保証されます。 さもなければ、外部のネットワークに同時アクセスを持つことができたノードはそうです。
Srisuresh & Egevang Informational [Page 3] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[3ページ]のRFC3022
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.
スタッブドメインの中のアドレスは、そのドメインにローカルであってドメインの外で有効ではありません。 したがって、いかなる他のスタッブドメインもスタッブドメインの中のアドレスを再利用できます。 例えば、多くのスタッブドメインはただ一つのClass Aアドレスを使用できました。 スタッブドメインとバックボーンの間の各エキジットポイントに、NATはインストールされます。 1つ以上のエキジットポイントがあれば、かなりの重要性では、各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[RFC1918]を使用します。 スタッブAのNATはクラスCアドレスブロック198.76.29.0/24に配属されます、そして、Stubビーズ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
\ | / +---------------+ |地方のルータ| +---------------+ WAN| | WAN| | Aを…………引き抜いてください。|.... ....|............ スタッブB| | s=198.76.29.7、^ | |対s=198.76.29.7、d=198.76.28.4、^ | |対d=198.76.28.4、+-----------------+ +-----------------+ |NATがあるスタッブルータ| |NATがあるスタッブルータ| +-----------------+ +-----------------+ | | | ラン・ラン| ------------- ------------- | | s=10.33.96.5、^ | |対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操作
Srisuresh & Egevang Informational [Page 4] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[4ページ]のRFC3022
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ホストを引き抜くためにパケットを送るというスタッブAホスト10.33.96の.5願望である、10.81、.13、.22、グローバルにユニークなアドレスを使用する、198.76、.28、.4、目的地、プライマリルータにパケットを送ります。 スタッブルータには、ネットの198.76のためのスタティックルートがあります。.0 .0 WANリンクにパケットを送ります。 しかしながら、NATがソースアドレスを翻訳する、10.33、.96、.5、グローバルに特有へのIPヘッダー、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。アドレスはスタッブB.でホストによって使用されます。.28 .4 アドレス変換は、多くの場合、ホストを終わらせるために見え透いています。 もちろん、これはただ簡単な例です。 探検されるために、多数の問題があります。
2.2. Overview of NAPT
2.2. NAPTの概要
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).
組織がプライベートアイピーネットワークとWANをサービスプロバイダーにリンクさせると言ってください。 私設のネットワークのスタッブルータはグローバルに有効なアドレスをWANリンクに割り当てられます、そして、組織における残っているノードには、ローカルの意味しか持っていないIPアドレスがあります。 このような場合には、私設のネットワークのノードに外部のネットワークへの同時アクセスを許容できました、NAPTの援助があるただ一つの登録されたIPアドレスを使用して。 NAPTは、写像するのをタイプ(ローカルアイピーアドレス、地方のTUは数を移植する)のtuplesをタイプのtuplesに許容するでしょう(登録された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アドレスが割り当てられたサービスプロバイダーを使用することでほとんどのソーホー(ソーホー)グループが外部のネットワークにアクセスするという要件に合います。 静的に登録されたIPアドレスのそれぞれのサービスTUポートあたり1つのローカルのノードを写像することによって本国行きのアクセスを許すためにこのモデルを広げることができました。
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は内部的にクラスAアドレスブロック10.0.0.0/8を使用します。 IPアドレス138.76はスタッブルータのWANインタフェースに割り当てられます。.28 .4 サービスプロバイダーで。
Srisuresh & Egevang Informational [Page 5] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[5ページ]のRFC3022
\ | /
+-----------------------+
|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
\ | / +-----------------------+ |サービスプロバイダールータ| +-----------------------+ WAN| | Aを…………引き抜いてください。|.... | ^、s=138.76.28.4、スポーツ=1024| s=138.76.29.7、スポーツ=23、^d=138.76.29.7、dport=23に対して|、v d=138.76.28.4、dport=1024、+------------------+ |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.
スタッブAホストである、10.0、.0、.10、接待するtelnetパケットを送る、138.76、.29、.7、グローバルにユニークなアドレスを使用する、138.76、.29、.7、目的地、それのプライマリルータにパケットを送ります。 スタッブルータには、サブネット138.76.0.0/のためのスタティックルートがあります。16 WANリンクにパケットを送ります。 しかしながら、NAPTはソースアドレス10.0.0.10のtupleを翻訳します、そして、ソースTCPはIPとTCPヘッダーで.4と唯一割り当てられたTCPが移植する.28、たとえばパケットの前の1024が送られるグローバルにユニークな138.76に3017を移植します。 リターンパスのパケットは目標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がスタッブルータにおけるサービス[RFC1700]を移植する井戸を構成するのは可能です。
Srisuresh & Egevang Informational [Page 6] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[6ページ]のRFC3022
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メッセージに加えて、REDIRECTを除いて、メッセージタイプはNAPTルータによってモニターされるかもしれません。 ICMP質問タイプパケットはTCP/UDPパケットのものと同様の状態で翻訳されます、ICMPメッセージヘッダーの識別子分野が唯一登録されたIPアドレスに関する質問識別子に写像されるので。 Query応答者から応答メッセージで変わりがない状態でICMP質問メッセージの識別子野原をQuery送付者が設定して、返します。 したがって、(ローカルアイピーアドレス、ローカルのICMP質問識別子)のtupleはそうです。NAPTルータによって(登録されたIPアドレス、割り当てられたICMP質問Identifier)のtupleに写像されて、ローカル・ホストのどれかからすべてのタイプの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.
NAPTセットアップで、ルータは確実にTCP、UDPまたは企業内情報通信網のノードから溯源されたものに対してそれ自体から溯源されたICMP質問セッションの間で区別をしなければなりません。そこでは、登録されたIPアドレスがスタッブルータWANインタフェースのIPアドレスと同じです。 エンドノードとしてすべての本国行きのセッション(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ポート)のtupleからtupleまで結合は(割り当てられたアドレス、割り当てられたTUポート)のものでしょう。(そこでは、多くのプライベート・アドレスがただ一つのグローバルにユニークなアドレスに写像されます)。 最初の外向的なセッションが個人的なホストの上で(プライベート・アドレス、個人的なTUポート)のtupleによって開始されるとき、Basic NATのように、この結合は決定しています。 一般的な習慣でない間、ホストが複数の同時のセッションの起因することを設立する兵卒の上にアプリケーションを持っているのは可能です。
Srisuresh & Egevang Informational [Page 7] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[7ページ]のRFC3022
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ポート)の同じtuple。 ケース、(プライベート・アドレス、個人的なTUポート)のtupleに、ただ一つの結合がそうするそのようなものでは、パケットに関する翻訳にホストの上に同じtupleから発するすべてのセッションに関して使用されてください。
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ポート)tupleが確立された後に、軟性国家は、接続各人のために結合を使用することで維持されるかもしれません。 同じセッションに属するパケットは翻訳目的のためにセッションルックアップをなることがあるでしょう。 フォローオン部で翻訳の正確な本質について議論します。
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ポート)tuple結合に基づく納会が終えられるとき、結合自体は終えられるかもしれません。
4.0. Packet Translations
4.0. パケット翻訳
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の管理されたセッションに関するパケットはどちらかの方向による翻訳を受けます。 個々のパケット翻訳問題は以下の小区分で詳細にカバーされています。
4.1. IP, TCP, UDP and ICMP Header Manipulations
4.1. IP、TCP、UDP、およびICMPヘッダー操作
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 Queryパケット([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港)に関する翻訳を含むように変更を広げなければなりません。 また、質問IDとICMPヘッダーチェックサムを置き換えるようにICMP QueryパケットのICMPヘッダーを変更しなければなりません。 個人的なホスト質問IDはそうであるに違いありません。
Srisuresh & Egevang Informational [Page 8] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[8ページ]のRFC3022
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に翻訳されます。 Query ID翻訳を説明するためにICMPヘッダーチェックサムを修正しなければなりません。
4.2. Checksum Adjustment
4.2. チェックサム調整
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はヘッダーの始まりから同等のオフセットで来ているに違いない)とさえ長さだけにさえ、以下のアルゴリズムは適切です(すなわち、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;
}
checksumadjust(未署名の炭*のchksum、未署名の炭*のoptr、int olen、未署名の炭*nptr、int nlen)/*仮定を欠如させてください: 未署名の炭は8ビットであり、長いのは、32ビットです。 - chksumはパケットにchksumを示します--optrはパケットに古いデータを示します--nptrはパケット*/に新しいデータを示します。長い..古い..新しい..等しい..老人..等しい..等しい..老人..新しい..新しい..0×10000..等しい
Srisuresh & Egevang Informational [Page 9] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[9ページ]のRFC3022
4.3. ICMP error packet modifications
4.3. ICMP誤りパケット変更
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.
また、NAPTセットアップで、TCP、UDPまたはICMPの中で埋め込まれたIPメッセージがたまたまICMP Queryパケットであるなら、あなたは、TCP/UDPヘッダーの中の適切なTUポートナンバーかICMP QueryヘッダーのQuery Identifier分野を変更する必要があるでしょう。
Lastly, the IP header of the ICMP packet must also be modified.
また、最後に、ICMPパケットのIPヘッダーを変更しなければなりません。
4.4. FTP support
4.4. FTPサポート
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 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は、ソースポートFTPか仕向港FTPでTCP系列を修正して、数を承認するために特別なテーブルを必要とするでしょう。 テーブル項目には、ソースアドレス、送付先アドレス、ソースポート、仕向港、一連番号のためのデルタ、およびタイムスタンプがあるべきです。 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ペイロード翻訳はBasic NATのためにプライベート・アドレスとそれらの割り当てられた外部アドレスに制限されます(ASCIIにおける個々の八重奏として、コード化されます)。 しかしながら、NAPTセットアップにおいて、アドレス八重奏に続いて、TCPポート八重奏(ASCIIにおける)を含むように翻訳を広げなければなりません。
4.5 DNS support
4.5 DNSサポート
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におけるセッションが支配的に個人的なドメインから外国行きであると考える場合、以下の伝統的なNATに関連して使用からDNS ALGを取り除くかもしれません。 個人的なドメインへの内部のサーバがIPアドレスへの名前に関するマッピングを維持するDNS
Srisuresh & Egevang Informational [Page 10] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[10ページ]のRFC3022
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サーバに指示されるかもしれません。
4.6. IP option handling
4.6. IPオプション取り扱い
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オプションRecord Route、Strict Source RouteまたはLoose Source RouteのどれかがあるIPデータグラムは、中間的ルータのIPアドレスを記録するか、または使用することを伴うでしょう。 NATの中間的ルータは、オプションを処理している間、これらのオプションをサポートもしませんし、アドレスを非翻訳されたままにもしないのを選ぶかもしれません。 アドレスを非翻訳されたままにするという結果は終わりが終わるために送信元経路に沿ったプライベート・アドレスに暴露されるということでしょう。 各ルータが次のホップルータだけを見るべきであるとき、これはそういうものとしてパケットの縦断経路を危険にさらすべきではありません。
5. Miscellaneous issues
5. 種々雑多な問題
5.1. Partitioning of Local and Global Addresses
5.1. 地方の、そして、グローバルなアドレスの仕切り
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.の個人的な受け取り人を重ね合わせました。In本件、スタッブAのルータはそれ自身のプライベート・アドレスとスタッブBのグローバルアドレスを区別できないでしょう。
5.2. Private address space recommendation
5.2. プライベート・アドレス宇宙推薦
[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.
[RFC1918]は私設のネットワークのためのアドレス空間配分に推薦を持っています。 インターネットAssigned民数記Authority(IANA)には、3ブロックのIPアドレス空間、すなわち、10.0.0 8、.0/172.16.0 12、および.0/192.168.0があります。個人的なインターネットのための.0/16。 プレCIDR記法で、最初のブロックはただただ一つのクラスAネットワーク・ナンバーです、2番目のブロックが1セットの16の隣接のクラスBネットワークです、そして、3番目のブロックは1セットの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かインターネット登録で少しもコーディネートなしでそうできます。 その結果、アドレス空間を個人的に使用できます。
Srisuresh & Egevang Informational [Page 11] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[11ページ]のRFC3022
many independent organizations at the same time, with NAT operation enabled on their border routers.
同時にのNAT操作がそれらの境界ルータで可能にされている多くの独立機関。
5.3. Routing Across NAT
5.3. 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.
通常、すべての域外交通をサービスプロバイダールータに送るためにWANリンクの上にNATスタッブルータでスタティックルートを構成するでしょう、そして、サービスプロバイダールータで、NATパケット(すなわち、送付先IPアドレスがNATの範囲の中に下がるそれらはグローバルアドレスリストを管理した)をNATルータに送るためにWANリンクの上にスタティックルートを構成するでしょう。
5.4. Switch-over from Basic NAT to NAPT
5.4. オーバー、基本的なNATからNAPTまで切り替わります。
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.
個人的なネットワーク・ノードが(たとえばクラスCグローバルアドレスブロックに写像されたクラスのB私設のネットワーク)を写像するのに利用可能なグローバルなアドレスに数でまさるときのBasic NATセットアップで、住所録からの最後のグローバルアドレスが使いきられた後にいくつかのローカルのノードへの外部のネットワークアクセスは突然に断ち切られます。 これは、非常に不便で抑制しています。 Basic NATルータが住所録における最後のグローバルアドレスのためのNAPTセットアップに切り替わるのを任意に許容することによって、安全にそのようなインシデントを避けることができます。 これをするのは、私設のネットワークのホストには外部ノードへの継続的で、とぎれないアクセスとほとんどのアプリケーションのためのサービスがあるのを確実にするでしょう。 しかしながら、以前は突然よくBasic NATで動作していたアプリケーションのいくつかがオーバースイッチのためNAPTに壊れるならそれが混乱させられているかもしれないことに注意してください。
6.0. NAT limitations
6.0. 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に特定の制限を特定します。
6.1. Privacy and Security
6.1. プライバシーとセキュリティ
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.
セッションがuni個人的なホストから方向上であるのでプライバシーメカニズムを提供すると伝統的な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
プライバシーを高めるのと同じ特性で、デバッグ問題(安全の侵害を含んでいる)は潜在的により難しくなります。 私設のネットワークのホストが何らかの方法でインターネットを乱用している、(そのようなもの
Srisuresh & Egevang Informational [Page 12] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[12ページ]のRFC3022
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ルータに隠されるので問題の実際の源を追跡するのは、より難しいです。
6.2. ARP responses to NAT mapped global addresses on a LAN interface
6.2. NATへのARP応答はLANインタフェースに関するグローバルなアドレスを写像しました。
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を可能にしなければなりません。 例はBasic NATを例証するためにドキュメントに供給されました、そして、NAPTは接続のためにNATルータから外部のルータ(すなわち、サービスプロバイダールータ)にWANリンクを維持しました。 しかしながら、WANリンクをLAN接続に取り替えるつもりであり、NATマッピングに使用されるグローバルアドレススペースの部分かすべてがLANセグメントと同じIPサブネットのものなら、NATルータが同じサブネットに属すアドレスの範囲のサポートをARPに供給すると予想されるでしょう。 NATがそれ自身のMACアドレスでグローバルなアドレスを写像したので、ARP要求に応じるのは、Basic NATセットアップがあるそのような状況で絶対に必要なものです。 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ルータのインターフェース・アドレス(オーバースイッチに関するBasic NATから例えば上の5.4で説明されたNAPTまでのケースのように)でない時を除いて、このシナリオは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であると任意にサポートしたがっているかもしれません。
6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup
6.3. 外国行きのTCP/UDPに関する翻訳はNAPTセットアップでパケットを断片化しました。
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パケットを同じあて先ホストに断片化したと言ってください。 そして、彼らはたまたま同じ断片化識別子を使用しました。 同じ断片化イドを運んで、目標ホストが2個の関係ないデータグラムを受け取って、ホスト・アドレスが割り当てられた同じくらいからデータグラムが2つのセッションのどれに属すかを決定できないとき。 その結果、両方のセッションは崩壊するでしょう。
Srisuresh & Egevang Informational [Page 13] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[13ページ]のRFC3022
7.0. Current Implementations
7.0. 現在の実装
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記述を固く守る産業で利用可能です。 リナックスパブリックドメインソフトは「アイピーマスカレード」という名でNATを含んでいます。 無料OSの一つパブリックドメインソフトには、デーモンとして稼働するNAPT実装があります。 しかしながら、そのリナックスソースがGNUライセンスの下でカバーされていて、無料OSの一つソフトウェアが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.
リナックスと無料OSの一つソフトウェアの両方が無料であるので、あなたはこれらのためにただ分配の費用でCD-ROMを買うことができます。 また、それらも最新のパッチで多くのFTPサイトからオンラインであることで利用可能です。
8.0. Security Considerations
8.0. セキュリティ問題
The security considerations described in [NAT-TERM] for all variations of NATs are applicable to traditional NAT.
NATsのすべての変化のために[NAT-TERM]で説明されたセキュリティ問題は伝統的なNATに適切です。
References
参照
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
Srisuresh、P.、M.Holdrege、および「IPネットワークアドレス変換機構(NAT)用語と問題」という[ナット-用語]、RFC2663、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.
[RFC1918] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
ブレーデン、R.、[RFC1122]「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
ブレーデン、[RFC1123]R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[FTP] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL
(FTP)", STD 9, RFC 959, October 1985.
[FTP] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、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)仕様」を映し出します、STD7、RFC793、1981年9月。
Srisuresh & Egevang Informational [Page 14] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[14ページ]のRFC3022
[ICMP] Postel, J., "INTERNET CONTROL MESSAGE (ICMP)
SPECIFICATION", STD 5, RFC 792, September 1981.
[ICMP] ポステル、J.、「インターネットコントロールメッセージ(ICMP)仕様」、STD5、RFC792、1981年9月。
[UDP] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC
768, August 1980.
[UDP] ポステル、J.、「ユーザー・データグラム・プロトコル(UDP)」、STD6、RFC768、1980年8月。
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[RFC2101] 大工とB.とクロウクロフトとJ.とY.Rekhter、「IPv4は今日ふるまいを扱う」RFC2101、1997年2月。
Authors' Addresses
作者のアドレス
Pyda Srisuresh Jasmine Networks, Inc. 3061 Zanker Road, Suite B San Jose, CA 95134 U.S.A.
Pyda SrisureshジャスミンはInc.3061Zanker道路、Bサンノゼ、スイートカリフォルニア95134米国をネットワークでつなぎます。
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
以下に電話をしてください。 (408) 895-5032 メールしてください: srisuresh@yahoo.com
Kjeld Borch Egevang Intel Denmark ApS
Kjeld Borch EgevangインテルデンマークApS
Phone: +45 44886556 Fax: +45 44886051 EMail: kjeld.egevang@intel.com http: //www.freeyellow.com/members/kbe
以下に電話をしてください。 +45 44886556Fax: +45 44886051はメールされます: kjeld.egevang@intel.com http: //www.freeyellow.com/members/kbe
Srisuresh & Egevang Informational [Page 15] RFC 3022 Traditional NAT January 2001
NAT2001年1月に伝統的なSrisuresh&Egevang情報[15ページ]のRFC3022
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Srisuresh & Egevang Informational [Page 16]
Srisuresh&Egevang情報です。[16ページ]
一覧
スポンサーリンク
