この文書はRFC3022の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
この文書で記述されたＮＡＴオペレーションはＲＦＣ１６３１で導入された
アドレス翻訳に、新しいタイプのネットワークアドレスとＴＣＰ／ＵＤＰポー
ト翻訳を含む拡張をします。加えて、この文書はＲＦＣ１６３１で公開され
たチェックサム調整アルゴリズムを修正し、そして詳細でＮＡＴオペレーショ
ンと限界を論じようと試みます。
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.
基本的なネットワークアドレス翻訳あるいは基本的なＮＡＴは、エンドユー
ザに透過にＩＰアドレスが１つのグループから他に変換する方法です。ネッ
トワークアドレスポート翻訳、あるいはＮＡＰＴは、多数のネットワークア
ドレスとＴＣＰ／ＵＤＰ（伝送制御プロトコル／ユーザーデータグラムプロ
トコル）ポートを、単一のネットワークアドレスとＴＣＰ／ＵＤＰポートに
翻訳する方法です。同時に、これらの２つの伝統的ＮＡＴと呼ばれるオペレー
ションは、プライベートアドレスの領域を、世界的規模でユニークな登録さ
れたアドレスを使う外部の領域とを、結び付けます。
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.
ＩＰアドレス翻訳の必要性は、ネットワークの内部のＩＰアドレスがプライ
バシの理由やネットワーク外では無効でネットワークの外で使えない時、生
じます。
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]やこの文書の６章に記述する場
合を除く多くの場合）。主に内部使用のためにネットワークを設定し、時々
の外部のアクセスの必要とする組織は、この案の良い候補です。
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.
多く小さいオフィスやホームオフィス（ＳＯＨＯ）ユーザと通信従事者は、
ＴＣＰ／ＵＤＰアプリケーションを走らせる多数のネットワークノードをオ
フィスに持つが、遠隔のネットワークにアクセスするためにサービスプロバ
イダからリモートアクセスルーターに割り当てられたひとつのＩＰアドレス
を持っています。これは遠隔アクセスユーザの通信が増えても、ＮＡＰＴは
利点があり、これはローカルネットワークでの多数のノードが同時に１つの
ルーターに割り当てられたＩＰアドレスでアクセスするのを許すでしょう。
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.
翻訳方法を使うことに限界があります。すべてのセッションに関しての要求
と応答が同じＮＡＴルータを通ることは必須です。これを確かめる一つの方
法が、スタブドメインの唯一の境界ルータに基づいてＮＡＴを持つことで、
そしてすべてのＩＰパケットはドメイン発か、ドメイン着宛です。多数のＮ
ＡＴ装置がある時にこれを保証する他の方法があります。例えば、プライベー
トドメインが異なるプロバイダへの２の別の出口を持つことができます、そ
してプライベートネットワークのホストからのセッションフローは外部ホス
トへの最良距離のＮＡＴ経由でできます。ＮＡＴルータの１つが故障する時、
すべての接続のトラフィックの経路を他に出来ます。この方法に問題があり
ます、経路を変更されたフローは新しいＮＡＴルータに切替わる時に失敗し
ます。この可能性がある問題を克服する方法はルータが同じＮＡＴ設定を共
有し、お互いに障害時のバックアップを保証するために状態情報を交換する
ということです。
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.
アドレス翻訳はアプリケーションに依存しなくて、そしてペイロードモニタ
リングと改変を行うためにしばしばアプリケーション固有ゲートウェイ（Ａ
ＬＧ）を伴います。ＦＴＰはＮＡＴ装置上の最も一般的なＡＬＧ装置です。
暗号化を行うとＡＬＧがペイロードを解読するための鍵を持たない限りＡＬ
Ｇ動作に障害を与えるので、ＡＬＧ仲介を必要としているアプリケーション
はペイロードを暗号化してはなりません。
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.
この解決策はＩＰアドレスのエンドエンド性を取り去り、そしてネットワー
クで状態を増やす欠点を持ちます。結果的に、ＮＡＴ装置が途中にある場合
に、ＩＰｓｅｃで保証されたエンドエンドＩＰネットワークレベルセキュリ
ティは、エンドホストで想定できません。この方法の利点はホストやルータ
に対する変更なしで導入できることです。
Definition of terms such as "Address Realm", "Transparent Routing",
"TU Ports", "ALG" and others, used throughout the document, may be
found in [NAT-TERM].
この文書で使用している「アドレス領域」や「透過ルーティング」や「ＴＵ
ポート」や「ＡＬＧ］などの用語の定義は、[NAT-TERM]にあります。
2. Overview of traditional NAT
2. 伝統的ＮＡＴの概観
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).
この文書で示したアドレス翻訳オペレーションは「伝統的ＮＡＴ」と言われ
ます。この文書の対象としない他の種類のＮＡＴがあります。伝統的ＮＡＴ
はプライベートネットワーク内のホストが、たいていの場合は透過的に、外
部ネットワークのホストにアクセスすることを許すでしょう。伝統的ＮＡＴ
で、セッションはプライベートネットワークから外向きの一方向性です。反
対方向へのセッションは、特例として、事前に選択されたホストの静的アド
レス対応を使って許されるかもしれません。基本ＮＡＴやＮＡＰＴは伝統的
なＮＡＴの２つの種類で、基本ＮＡＴの変換はＩＰアドレスに限定され、Ｎ
ＡＰＴ翻訳はＩＰアドレスとトランスポート識別子（ＴＣＰ／ＵＤＰポート
やＩＣＭＰ問合せ識別子）を含むように拡張されます。
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.
特に言わない限り、この文書でアドレス翻訳やＮＡＴは伝統的ＮＡＴ、すな
わち基本ＮＡＴとＮＡＰＴの事です。下図１で記述されたようなスタブ境界
ルータだけが、アドレス翻訳を演ずるように設定されるかもしれません。
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
Figure 1: Traditional NAT Configuration
図１：伝統的ＮＡＴ設定
2.1 Overview of Basic NAT
2.1 基本ＮＡＴの概観
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.
基本ＮＡＴオペレーションは次の通りです。プライベートネットワークアド
レスを持っているスタブドメインが動的にプライベートアドレスの集合をグ
ローバル有効ネットワークアドレスの集合に対応付けることで外部のネット
ワークと通信を可能にします。もしローカルノードの数がグローバル集合の
アドレス数以下なら、各ローカルアドレスはグローバルアドレスと対応付け
を保証されます。さもなければ、外部ネットワークに同時アクセスを許され
たノードは、グローバルアドレスの数で制限されます。個別のローカルアド
レスが外部アクセスをするのや外部ホストがローカルホストに固定公開アド
レスでアクセスするのを保証するため、個別のローカルアドレスが静的に特
定のグローバルアドレスに対応付けされるかもしれません。同じアドレス対
応を使って、多数の同時のセッションが、ローカルノードから始められるか
もしれません。
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.
スタブドメインの内部アドレスは、ドメイン内のローカルで、ドメイン外で
無効です。それで、スタブドメイン内のアドレスは他のスタブドメインで再
利用できます。例えば、１つのクラスＡアドレスが多くのスタブドメインで
使えます。スタブドメインとバックボーンの間のそれぞれの出口でＮＡＴが
導入されます。もし複数の出口があるなら、それぞれのＮＡＴが同じ翻訳テー
ブルを持っていることは非常に重要です。
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.
例えば、図２の例で、内部のＡとＢの両方がクラスＡプライベードアドレス
ブロック10.0.0.0/8 [RFC 1918]を使います。スタブＡのＮＡＴはクラスＣ
アドレスブロック198.76.29.0/24を割当てられ、スタブＢのＮＡＴはクラス
Ｃアドレスブロック198.76.28.0/24を割当てられます。クラスＣアドレスは
グローバルに一意で、他のＮＡＴの箱が使えません。
\ | /
+---------------+
|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
図２：基本ＮＡＴオペレーション
When stub A host 10.33.96.5 wishes to send a packet to stub B host
10.81.13.22, it uses the globally unique address 198.76.28.4 as
destination, and sends the packet to its primary router. The stub
router has a static route for net 198.76.0.0 so the packet is
forwarded to the WAN-link. However, NAT translates the source
address 10.33.96.5 of the IP header to the globally unique
198.76.29.7 before the packet is forwarded. Likewise, IP packets on
the return path go through similar address translations.
スタブＡホスト10.33.96.5がスタブＢホスト10.81.13.22にパケットを送るこ
とを望む時、宛先としてグローバルアドレス198.76.28.4を使い、主ルータに
パケットを送ります。スタブルータはネット198.76.0.0の静的経路を持ち、
それでパケットはＷＡＮリンクに転送されます。しかしながら、ＮＡＴはパ
ケットを転送する前に、ＩＰヘッダのソースアドレス10.33.96.5をグローバ
ルアドレス198.76.29.7に翻訳します。同じく、返送パス上のＩＰパケットが
同様のアドレス翻訳を通ります。
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 がスタブＢホストの使っているア
ドレスと考えます。アドレス翻訳はたいていの場合にエンドホストに透過で
す。もちろん、これは単純な例です。探検される多数の問題があります。
2.2. Overview of NAPT
2.2. ＮＡＰＴの概観
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).
組織がプライベートＩＰネットワークとサービスプロバイダへのＷＡＮリン
クを持つとします。プライベートネットワークのスタブルータはＷＡＮリン
ク上でグローバルアドレスを割り当てられます、そして組織での残りのノー
ドはローカルにだけ有効なＩＰアドレスを持っています。このような場合、
プライベートネットワーク上のノードはＮＡＰＴと共に一つの登録されたＩ
Ｐアドレスを使って外部ネットワークに同時アクセスを許されます。ＮＡＰ
Ｔはタイプ（ローカルＩＰアドレス、ローカルＴＵポート番号）２項組みを
タイプ（登録ＩＰアドレス、割当てＴＵポート番号）２項組みに変換をしま
す。
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.
このモデルは、外部ネットワークアクセスにひとつのサービスプロバイダが
割当てたＩＰアドレスを使用する、たいていの小さいオフィスホームオフィ
ス（ＳＯＨＯ）の必要条件に合います。このモデルはそれぞれの登録ＩＰア
ドレスのサービスＴＵポート毎に静的にローカルノードを対応付ける事で内
行きのアクセスを許すように拡張できます。
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.
下の図３の例で、スタブＡが内部でクラスＡアドレスブロック10.0.0.0/8を
使います。スタブルータのＷＡＮインタフェースはサービスプロバイダから
ＩＰアドレス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
図３：ネットワークアドレスポート翻訳（ＮＡＰＴ）オペレーション
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にｔｅｌｎｅｔパケットを送
る時、宛先としてグローバルアドレス138.76.29.7を使い、パケットを主ルー
タに送ります。スタブルータはサブネット138.76.0.0/16の静的経路を持って
います、それでパケットはＷＡＮリンクに転送されます。しかしながら、Ｎ
ＡＰＴがＩＰヘッダとＴＣＰヘッダのソースアドレス10.0.0.10とソースＴＣ
Ｐポート3017の組を、パケットが転送される前に、グローバルアドレス
138.76.28.4と一意に割り当てられたＴＣＰポート、ここでは1024、に翻訳し
ます。応答パス上のパケットが宛先ＩＰアドレスと宛先ＴＣＰポートについ
て、類似のアドレスとＴＣＰポート翻訳を行います。再度、これがホストや
ルータに対する変更を必要としないことに気付いてください。翻訳は完全に
透過です。
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.
この設定で、ＴＣＰ／ＵＤＰセッションだけが許され、そしてローカルなネッ
トワーク発でなければなりません。しかしながら、内行きのアクセスを要求
するＤＮＳのようなサービスがあります。組織が内行きのセッションアクセ
スを許すことを望む他のサービスがあるかもしれません。静的にスタブルー
タ上の既知ＴＵポートサービス[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.
ＴＣＰ／ＵＤＰセッションのほかに、ＩＣＭＰメッセージが、リダイレクト
メッセージタイプを例外として、ＮＡＰＴルータによってモニターされるか
もしれません。ＩＣＭＰ問合せタイプパケットは、ＩＣＭＰメッセージヘッ
ダの識別子フィールドが登録されたＩＰアドレスの問合せ識別子に一意に対
応付けられるという点で、ＴＣＰ／ＵＤＰパケットに類似して翻訳されます。
ＩＣＭＰ問合せメッセージでの識別子フィールドは問合せ送信者によって設
定され、そして問合せ応答からの応答メッセージで変化せずに戻ります。そ
れで、（ローカルＩＰアドレス、ローカルＩＣＭＰ問合せ識別子）の２項組
みは、ローカルホストのどれからでも一意にすべてのタイプのＩＣＭＰの問
合せを識別するため、ＮＡＰＴルータによって（登録ＩＰアドレス、割り当
てＩＣＭＰ問合せ識別子）の２項組みに変換されます。ＩＣＭＰエラーメッ
セージへの修正は、ＩＰとＩＣＭＰヘッダだけでなく、ＩＣＭＰペイロード
の修正を伴うので、後の章で論じられます。
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.
ＮＡＰＴ設定で、登録ＩＰアドレスがスタブルータのＷＡＮインタフェース
のＩＰアドレスと同じである時、ルータはＴＣＰとＵＤＰとＩＣＭＰ問合せ
のセッションを自分自身が発したのか、あるいはローカルネットワークのノー
ドが発したのか、確実に区別しなければなりません。すべての内行きのセッ
ション（ＴＣＰとＵＤＰとＩＣＭＰ問合せセッションを含む）は、宛先サー
ビスポートがローカルネットワークに対応しなければ、エンドノードとして
ＮＡＴルータに向けられると考えられます。
Sessions other than TCP, UDP and ICMP query type are simply not
permitted from local nodes, serviced by a NAPT router.
ＴＣＰとＵＤＰとＩＣＭＰ問合せタイプ以外のセッションはＮＡＰＴルータ
の提供するサービスで単純に認められません。
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-TERM]で記述されているものと同じです。次
の詳細は伝統的なＮＡＴに固有の項目を示します。
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.
基本的ＮＡＴで、最初の外向セッションがプライベートホストから始められ
る時、プライベートアドレスが外部アドレスと結合されます。その後、同じ
プライベートアドレスからのすべての外向セッションはパケット翻訳に同じ
アドレス結合を使うでしょう。
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.
ＮＡＰＴの場合、多くのプライベートアドレスが一つのグローバルアドレス
に対応付けられる場合、結合は（プライベートアドレス、プライベートＴＵ
ポート）の２項組みから（割り当てアドレス、割り当てＴＵポート）の２項
組みへであるでしょう。基本ＮＡＴと同様に、この結合は最初の外向セッショ
ンがプライベートホスト上の（プライベートアドレス、プライベートＴＵポー
ト）の２項組みで始められる時に、決定されます。一般的ではないが、プラ
イベートホスト上のアプリケーションが同じ（プライベートアドレス、プラ
イベートＴＵポート）２項組みで開始する多数の同時のセッションを確立す
ることは可能です。このような場合、（プライベートアドレス、プライベー
トＴＵポート）２項組みがのためのひとつの結合が、すべてのホスト上の同
じ２項組みで開始するセッションのパケットの翻訳のために使われるかもし
れません。
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.
アドレス結合あるいはＮＡＰＴの場合に（アドレス、ＴＵポート）２項組み
結合が確立された後、ソフト状態が接続のそれぞれが結合を使うことに関し
てサポートされるかもしれません。同じセッションに属しているパケットは
翻訳のためにセッション検索の適用を受けるでしょう。翻訳の厳密な性質は
後続の章で論じられます。
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.
アドレスあるいは（アドレス、ＴＵポート）２項組み結合に基づいた最後の
セッションが終了する時、結合自身も終了するかもしれません。
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.
ＮＡＴで管理されたセッションに関するパケットがいずれかの方向の翻訳を
経験します。個別のパケットの翻訳問題が次の章で詳細にカバーされます。
4.1. IP, TCP, UDP and ICMP Header Manipulations
4.1. ＩＰとＴＣＰとＵＤＰとＩＣＭＰヘッダの扱い
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.
基本ＮＡＴモデルで、すべてのパケットのＩＰヘッダは修正されなくてはな
りません。この修正はＩＰアドレス（外行きパケットでソースＩＰアドレス、
内行きパケットで宛先ＩＰアドレス）とＩＰチェックサムを含みます。
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])とＵＤＰ([UDP])セッションで、ＴＣＰ／ＵＤＰヘッダのチェッ
クサムの更新が必要です。これはＴＣＰ／ＵＤＰチェックサムがソースと宛
先ＩＰアドレスを含む擬似ヘッダをカバーするからです。例外として、０の
チェックサムを持つＵＤＰヘッダは修正されないべきです。ＩＣＭＰ問合せ
パケット([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.
ＮＡＰＴモデルで、ＩＰヘッダへの修正は基本ＮＡＴ同様です。ＴＣＰ／Ｕ
ＤＰセッションで、修正はＴＣＰ／ＵＤＰヘッダのＴＵポート（外行きパケッ
トのソースＴＵポートと、と内行きパケットの宛先ＴＵポート）の翻訳を含
めるために拡張されなくてはなりません。ＩＣＭＰ問合せパケットの中のＩ
ＣＭＰヘッダが問合せ識別子とＩＣＭＰヘッダチェックサムを置き換えるた
めに同じく修正されなくてはなりません。外向きでプライベートホストの問
合識別子が割当て識別子に翻訳され、内行きで正確な逆変換が必要です。Ｉ
ＣＭＰヘッダチェックサムは問合せ識別子翻訳のために修正されなくてはな
りません。
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.
ＮＡＴ修正がパケット毎に行われ、集中計算が可能で、単純なフィールド修
正に加えて１つ以上のチェックサム修正を伴います。運良く、我々は下記の
アルゴリズムを持ち、これは非常に単純で能率的に、ＩＰとＴＣＰとＵＤＰ
とＩＣＭＰヘッダのチェックサムを調整します。これらすべてのヘッダが１
の補数チェックサムを使うので、翻訳前と翻訳後のアドレスの間の数学的差
分を計算し、チェックサムに加算すれば十分です。以下のアルゴリズムは偶
数オフセット（すなわち、下記のoptrがヘッダの始めから偶数オフセットに
ある）と偶数長（すなわち、下記のolenとnlenは偶数）でのみ適用可能です。
（Ｃの）これのサンプルコードが次の通りです。
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
仮定：unsigned charは８ビットで、longは３２ビット
- chksumがパケットのチェックサムを指し示す
- optrがパケットの古いデータを指し示す
- nptrがパケットで新しいデータを指し示す
*/
{
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;
}
4.3. ICMP error packet modifications
4.3. ＩＣＭＰエラーパケット修正
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])に対する変更は、外側のＩＰとＩＣＭＰ
ヘッダに対する変更と、ＩＣＭＰエラーメッセージペイロードの中の埋め込
みのパケットのヘッダに対する変更を含みます。
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.
ＮＡＴがエンドホストに透過であるために、ＩＣＭＰエラーメッセージのペ
イロードの中の埋め込みのＩＰヘッダのＩＰアドレスは修正されなくてはな
りません、埋め込みのＩＰヘッダのチェックサムフィールドは修正されなく
てはなりません、そして最後に、ＩＣＭＰヘッダチェックサムはペイロード
に対する変更を反映するために同じく修正されなくてはなりません。
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.
ＮＡＰＴ設定で、もしＩＣＭＰの中の埋め込みのＩＰメッセージがたまたま
ＴＣＰかＵＤＰかＩＣＭＰ問合せパケットであるなら、ＴＣＰ／ＵＤＰヘッ
ダのＴＵポート番号やＩＣＭＰ問合せヘッダの問合せ識別子フィールドの適
切な修正をする必要があるでしょう。
Lastly, the IP header of the ICMP packet must also be modified.
最後に、ＩＣＭＰパケットのＩＰヘッダも修正されなくてはなりません。
4.4. FTP support
4.4. ＦＴＰサポート
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])は、後のデータセッ
ションのパラメータを決定するために、制御セッションのモニターをするＡ
ＬＧを要求するでしょう。ＦＴＰのＡＬＧはたいていのＮＡＴ実装に不可欠
な部分です。
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 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.
基本ＮＡＴで、ＦＴＰペイロードの翻訳はプライベートアドレスと割当て外
部アドレス（ＡＳＣＩＩで個別のオクテットとしてコード化される）に制限
されます。ＮＡＰＴ設定では、翻訳はアドレスオクテットの後のＴＣＰポー
トオクテット（ＡＳＣＩＩ）を含むように拡張されなくてはなりません。
4.5 DNS support
4.5 ＤＮＳサポート
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.
伝統的ＮＡＴでのセッションが主にプライベートドメインから外行きである
事を考えると、ＤＮＳのＡＬＧは次のように伝統的なＮＡＴと関連した使用
から取り除かれるかもしれません。プライベートドメイン内のＤＮＳサーバ
が内部ホストともしかしたらいくつかの外部ホストに対する名前からのアド
レスへの対応を維持します。外部ＤＮＳサーバが外部ホストの名前の対応だ
けを維持し、内部ホストのを維持しません。もしプライベートネットワーク
が内部ＤＮＳサーバを持たないなら、すべてのＤＮＳ要求は外部ホストのア
ドレス対応を見いだすために外部ＤＮＳサーバに向けられるかもしれません。
4.6. IP option handling
4.6. ＩＰオプション取り扱い
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.
ＩＰオプション、経路記録、厳密ソースルート、緩いソースルート、を持つ
ＩＰデータグラムは、中間ルータのＩＰアドレスの記録か使用を伴うでしょ
う。ＮＡＴ中間ルータがこれらのオプションをサポートしないと選択するか、
あるいは、オプションを処理する間にアドレスを翻訳しないままにしておく
かもしれません。アドレスを翻訳しないままにしておくことの結果は、ソー
スルートに沿ってのプライベートアドレスがエンドエンドで露出する事でしょ
う。これは、それぞれのルータが次の転送先のルータのを見ることになって
いるので、本質的に、パケットの横断パスを危険にさらすべきではありませ
ん。
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.
ＮＡＴで、この文書で記述されるように稼働するために、ＩＰアドレス空間
を２つの部分に分割することが必要です−スタブドメインの内部で使用する
プライベートアドレスと、グローバルユニークアドレス。どんなアドレスも
プライベートアドレスかグローバルアドレスに違いありません。重複があり
ません。
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.
重複における問題は次のことです。スタブＡのホストがスタブＢのホストに
パケットを送ることを望んだとします、けれどもスタブＢのグローバルアド
レスはスタブＡのプライベートアドレスと重複しています。この場合、スタ
ブＡのルータはスタブＢのグローバルアドレスを自己のプライベートアドレ
スと区別することが可能ではないでしょう。
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.
[RFC 1918]はプライベートのネットワークのためにアドレス空間割当を推薦
します。インターネット番号割当当局（ＩＡＮＡ）はプライベートインター
ネットのためにＩＰアドレス空間の３つのブロック、すなわち、10.0.0.0/8
と172.16.0.0/12と192.168.0.0/16を持っています。ＣＩＤＲ以前の表記法で
は、最初のブロックは１つは、クラスＡの１つのネットワーク番号で、２番
目のブロックは１６個の連続したクラスＢネットワークの集合で、３番目の
ブロックは２５６個の連続的なクラスＣネットワークの集合です。
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.
上で定義されたアドレス空間のＩＰアドレスを使うと決めた組織は、ＩＡＮ
Ａやインターネット登記所との調整無しで使うことができます。アドレス空
間は、境界ルータの上でＮＡＴオペレーションを使用する状態で、同時に多
くの独立な組織でプライベートに使えます。
5.3. Routing Across NAT
5.3. ＮＡＴ越えルーティング
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.
ＮＡＴを動かしているルータはバックボーンにプライベートのネットワーク
を広告しないべきです。ただグローバルアドレスを持っているネットワーク
だけがスタブ外で知られています。しかしながら、ＮＡＴがスタブ境界ルー
タから受け取るグローバル情報は通常の方法でスタブに広告できます。
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ルータに転送するように設定されているでしょう。
5.4. Switch-over from Basic NAT to NAPT
5.4. 基本的ＮＡＴとＮＡＰＴの切り替え
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.
基本的ＮＡＴ設定で、プライベートネットワークノードが入手可能なグロー
バルアドレス数を越えるとき（クラスＢプライベートアドレスをクラスＣグ
ローバルアドレスブロックに対応付ける時）、アドレスリストからの最後の
グローバルなアドレスが使い尽くされた後、ローカルノードが突然外部ネッ
トワークアクセスから切り離されます。これは非常に不都合で制約です。こ
のような事故は、オプションで基本ＮＡＴルータがアドレスリストの最後の
グローバルアドレスをＮＡＰＴ設定に切り替えることを許すことで、安全に
避けれます。これをすることはプライベートネットワーク上のホストが外部
のノードに継続的で中断されないアクセスを、そしてたいていのアプリケー
ションのためのサービスを保証するでしょう。もし基本的ＮＡＴで動作した
アプリケーションのいくつかがＮＡＰＴに切り替わることで突然壊れるなら、
それが紛らわしいことに注意してください。
6.0. NAT limitations
6.0. ＮＡＴ限界
[NAT-TERM] covers the limitations of all flavors of NAT, broadly
speaking. The following sub-sections identify limitations specific
to traditional NAT.
[NAT-TERM]概括的な話で、すべてのＮＡＴの限界をカバーします。次の章は
伝統的ＮＡＴに固有の限界を示します。
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.
伝統的ＮＡＴは、セッションがプライベートホストからの一方向で、そして
プライベートホストの実際のアドレスが外部ホストに見えないから、プライ
バシーメカニズムを供給していると見ることができます。
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.
潜在的にプライバシーを拡張するこの特徴は（セキュリティ違反を含め）問
題解決をより難しくします。もしプライベートネットワークのホストがイン
ターネットをある意味で乱用するなら（他のマシンを襲おうとするか、大量
のスパムを送るなど）、ホストのＩＰアドレスがＮＡＴルータで隠されるか
ら、問題の実際のソースを追跡することはより難しくなります。
6.2. ARP responses to NAT mapped global addresses on a LAN interface
6.2. ＬＡＮインタフェース上のグローバルアドレスに対応したＮＡＴに対するＡＲＰ応答
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.
ＮＡＴはスタブドメインの境界ルータ上でだけ使用可能に違いありません。
基本的ＮＡＴとＮＡＰＴを示す文書で示される例は、ＮＡＴルータから外部
ルータ（すなわち、サービスプロバイダルータ）へ接続する管理されたＷＡ
Ｎリンクを持ちます。しかしながら、もしＷＡＮリンクをＬＡＮ接続で置き
換えるなら、そしてもしＮＡＴ対応に使われたグローバルなアドレス空間の
一部か全てがＬＡＮセグメントと同じサブネットに属するなら、ＮＡＴルー
タは同じサブネットに属するアドレス範囲に対するＡＲＰサポートを供給す
ることを期待されるでしょう。それ自身のＭＡＣアドレスでＮＡＴに対応し
たグローバルアドレスのＡＲＰの要求に応答することは基本的ＮＡＴ設定状
態で不可欠です。もしＮＡＴルータがこれらの要請に返答しなかったなら、
ネットワークにこれらのアドレスを所有するノードはなく、それ故に応答が
ありません。
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).
このシナリオは、ＮＡＰＴ変換で使用するアドレスがＮＡＴルータのインター
フェースアドレスである場合を除き、ＮＡＰＴ設定と異なります（例えば、
５.４で説明した、基本的ＮＡＴとＮＡＰＴの切り替えの場合の様に）。
Using an address range from a directly connected subnet for NAT
address mapping would obviate static route configuration on the
service provider router.
直接接続されたサブネットのアドレス範囲のアドレスをＮＡＴアドレスの対
応付けを使うことは、サービスプロバイダルータでの静的経路設定を除くで
しょう。
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.
サービスプロバイダルータへのＬＡＮリンクが非常に一般的でないことは著
者の意見です。しかしながら、ベンダは万一に備えてオプションとしてプロ
キシＡＲＰをサポートすることに興味を持っているかもしれません。
6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup
6.3. ＮＡＰＴ設定での外行きのＴＣＰ／ＵＤＰ分割パケットの翻訳
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.
ＮＡＰＴ設定での外行き（すなわち、プライベートホスト発）の分割ＴＣＰ
／ＵＤＰの翻訳が失敗します。理由は次の通りです。ただ最初の部分にだけ
翻訳のためにセッションとパケットを関連づけるために必要であるＴＣＰ／
ＵＤＰヘッダを含んでいます。次の部分はＴＣＰ／ＵＤＰポート情報を含ん
でいませんが、最初の部分で指定されのと同じ分割識別子を運びます。２つ
のプライベートホストが同じ宛先ホストに分割ＴＣＰ／ＵＤＰパケットを送
るとします。そして、それらはたまたま同じ分裂識別子を使ったとします。
宛先ホストが、同じ割り当てホストアドレスからの、同じ分割ＩＤの２つの
無関係なデータグラムを受け取る時、これらデータグラムが２つのセッショ
ンのいずれに属するか決定することが不可能です。従って、両方のセッショ
ンが失敗するでしょう。
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.
この文書で供給したＮＡＴをサポートする多くの商用実装が利用可能です。
リナックスパブリックドメインソフトウェアは「ＩＰマスカレード」の名前
でＮＡＴを含んでいます。ＦｒｅｅＢＳＤパブリックドメインソフトウェア
がデーモンとして作動するＮＡＰＴ実装を持っています。しかしながらリナッ
クスソースがＧＮＵライセンス下でカバーされ、ＦｒｅｅＢＳＤソフトウェ
アがＵＣバークレーライセンス下でカバーされることに注意してください。
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.
リナックスとＦｒｅｅＢＳＤの両ソフトウェアがフリーです、それであなた
は実費でこれらのＣＤ−ＲＯＭを買えます。これらは最近では多くのＦＴＰ
サイトから最新パッチ付きでオンラインでも利用可能です。
8.0. Security Considerations
8.0. セキュリティの考察
The security considerations described in [NAT-TERM] for all
variations of NATs are applicable to traditional NAT.
全てのＮＡＴの種類の[NAT-TERM]で記述されたセキュリティの考察は伝統的
ＮＡＴに適用できます。
References
参考文献
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[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 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[FTP] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL
(FTP)", STD 9, RFC 959, October 1985.
[TCP] Defense Advanced Research Projects Agency Information
Processing Techniques Office, "TRANSMISSION CONTROL
PROTOCOL (TCP) SPECIFICATION", STD 7, RFC 793, September
1981.
[ICMP] Postel, J., "INTERNET CONTROL MESSAGE (ICMP)
SPECIFICATION", STD 5, RFC 792, September 1981.
[UDP] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC
768, August 1980.
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
Authors' Addresses
著者のアドレス
Pyda Srisuresh
Jasmine Networks, Inc.
3061 Zanker Road, Suite B
San Jose, CA 95134
U.S.A.
Phone: (408) 895-5032
EMail: srisuresh@yahoo.com
Kjeld Borch Egevang
Intel Denmark ApS
Phone: +45 44886556
Fax: +45 44886051
EMail: kjeld.egevang@intel.com
http: //www.freeyellow.com/members/kbe
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（Ｃ）インターネット学会（２０００）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。