RFC1631 日本語訳
1631 The IP Network Address Translator (NAT). K. Egevang, P. Francis. May 1994. (Format: TXT=22714 bytes) (Obsoleted by RFC3022) (Status: INFORMATIONAL)
RFC一覧
英語原文
Network Working Group K. Egevang
Request for Comments: 1631 Cray Communications
Category: Informational (広報) P. Francis
NTT
May 1994
The IP Network Address Translator (NAT)
IP ネットワークアドレス変換 (NAT)
Status of this Memo
このメモの位置づけ
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
このメモは、Internet community のための情報を提供する。このメモは、い
かなる種類の Internet 標準を明細に述べるものではない。このメモの配布は
無制限である。
-------------------------------------------------------------------------
Abstract
要約
The two most compelling problems facing the IP Internet are IP
address depletion and scaling in routing. Long-term and short-term
solutions to these problems are being developed. The short-term
solution is CIDR (Classless InterDomain Routing). The long-term
solutions consist of various proposals for new internet protocols
with larger addresses.
IP Internet が直面している非常に切実な問題は、IP アドレスの枯渇と経路
表増大である。これらの問題に対する、長期的と短期的な解決法が、開発され
続けている。短期的な解決法は、CIDR (Classless InternetDomain Routing)
である。長期的な解決法は、より長いアドレスを持つ新しい internet プロト
コルとして、さまざまな提案からなる。
It is possible that CIDR will not be adequate to maintain the IP
Internet until the long-term solutions are in place. This memo
proposes another short-term solution, address reuse, that complements
CIDR or even makes it unnecessary. The address reuse solution is to
place Network Address Translators (NAT) at the borders of stub
domains. Each NAT box has a table consisting of pairs of local IP
addresses and globally unique addresses. The IP addresses inside the
stub domain are not globally unique. They are reused in other
domains, thus solving the address depletion problem. The globally
unique IP addresses are assigned according to current CIDR address
allocation schemes. CIDR solves the scaling problem. The main
advantage of NAT is that it can be installed without changes to
routers or hosts. This memo presents a preliminary design for NAT,
and discusses its pros and cons.
長期的な解決法がふさわしくなるまで、CIDR が IP Intenret を維持するのに
十分でないことがありうる。このメモは、別の短期的解決法である、アドレス
再利用を提案する。これは、CIDR を補って完全にし、また CIDR を不必要に
さえする。アドレス再利用解決法は、スタブドメインの境界に Network
Address Translators (NAT) を置くことである。それぞれの NAT box は、複
数のローカルな IP アドレスと世界で一意のアドレスのペアからなるテーブル
を持つ。スタブドメイン内側の IP アドレスは、世界で固有ではない。これら
のアドレスは他のドメインで再利用され、したがってアドレス枯渇問題を解決
する。世界で一意の IP アドレスは、現在の CIDR アドレス割り当て計画にし
たがって割り当てられる。CIDR は、経路表増大問題を解決する。NAT のおも
な長所は、ルータやホストへの変更なしに取り付けられることが出来ることで
ある。このメモは、NAT についての仮デザインを紹介し、その長所と短所を議
じる。
-------------------------------------------------------------------------
Acknowledgments
謝辞
This memo is based on a paper by Paul Francis (formerly Tsuchiya) and
Tony Eng, published in Computer Communication Review, January 1993.
Paul had the concept of address reuse from Van Jacobson.
このメモは、Computer Communication Review, January 1993 で発表された
Paul Francis (以前は Tsuchiya) と Tony Eng による論文に基づく。Paul は
Van Jacobson からアドレス再利用のアイデアを得た。
Kjeld Borch Egevang edited the paper to produce this memo and
introduced adjustment of sequence-numbers for FTP. Thanks to Jacob
Michael Christensen for his comments on the idea and text (we thought
for a long time, we were the only ones who had had the idea).
Kjeld Borch Egevang は、このメモを作成するための論文を編集し、FTP のた
めの順序番号調整を導入した。このアイデアとテキストに関するコメントをお
こなった Jacob Michael Christensen に感謝する (われわれは長い間考え、
われわれのみが、このアイデアを得た)。
-------------------------------------------------------------------------
1. Introduction
1. 序論
The two most compelling problems facing the IP Internet are IP
address depletion and scaling in routing. Long-term and short-term
solutions to these problems are being developed. The short-term
solution is CIDR (Classless InterDomain Routing) [2]. The long-term
solutions consist of various proposals for new internet protocols
with larger addresses.
IP Internet が直面している非常に切実な問題は、IP アドレスの枯渇と経路
表増大である。これらの問題に対する、長期的と短期的な解決法が、開発され
続けている。短期的な解決法は、CIDR (Classless InternetDomain Routing)
[2] である。長期的な解決法は、より長いアドレスを持つ新しい internet プ
ロトコルとして、さまざまな提案からなる。
Until the long-term solutions are ready an easy way to hold down the
demand for IP addresses is through address reuse. This solution takes
advantage of the fact that a very small percentage of hosts in a stub
domain are communicating outside of the domain at any given time. (A
stub domain is a domain, such as a corporate network, that only
handles traffic originated or destined to hosts in the domain).
Indeed, many (if not most) hosts never communicate outside of their
stub domain. Because of this, only a subset of the IP addresses
inside a stub domain, need be translated into IP addresses that are
globally unique when outside communications is required.
長期的な解決法の用意が出来るまで、IP アドレスのための需要を維持するた
めの簡単な方法は、アドレス再利用を通してである。この解決法は、どんな時
間でもドメインの外側と通信しているスタブドメイン内のホストの割合が大変
少ない、という事実を利用する (スタブドメインは、ドメイン内のホストから
起因されるか、またはそのホストへ向けられるトラフィックを扱うだけの企業
ネットワークのようなドメインである)。確かに、(大部分でないとしても) 多
くのホストは、スタブドメインの外側と決して通信しない。この理由で、外側
との通信が要求される時、スタブドメイン内側での IP アドレスのサブネット
のみが、世界で一意である IP アドレスに変換される必要がある。
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. There are various work-arounds that minimize
the potential pitfalls of this. Indeed, connection-oriented protocols
are essentially doing address reuse at every hop.
この解決法は、IP アドレスの end-to-end での重要性を奪い、ネットワーク
で増加される状態を持つ IP アドレスを補っているという不都合を持つ。この
潜在的な落とし穴を最小化する、さまざまな予備手段がある。いや実際、コネ
クション指向プロトコルは、すべてのホップでアドレス再利用を、本質的にお
こなっている。
The huge advantage of this approach is that it can be installed
incrementally, without changes to either hosts or routers. (A few
unusual applications may require changes). As such, this solution can
be implemented and experimented with quickly. If nothing else, this
solution can serve to provide temporarily relief while other, more
complex and far-reaching solutions are worked out.
このアプローチの非常に大きな長所は、ホストかルータへの変更なしに、増加
して設置することが出来ることである (少数のまれなアプリケーションは、変
更を必要とするかもしれない)。そういうものとして、この解決法は、すばや
く実装され実験されることが出来る。もし他になければ、他のもっと複雑で広
範囲に渡る解決法が作り出される間に、この解決法は困難の除去を一時的に提
供するものとして役立つことが出来る。
-------------------------------------------------------------------------
2. Overview of NAT
2. NAT の概観
The design presented in this memo is called NAT, for Network Address
Translator. NAT is a router function that can be configured as shown
in figure 1. Only the stub border router requires modifications.
このメモで示されるデザインは、Network Address Translator として、NAT
と呼ばれる。NAT は、図 1 で示されるように構成されることができる、ルー
タの機能である。スタブ境界ルータのみが、変更を必要とする。
NAT's basic operation is as follows. The 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.
NAT の基本的な操作は、次のとおりである。スタブドメイン内側のアドレスは
他のどんなスタブドメインにも再利用されることができる。たとえば、たった
1 つの Class A アドレスは、多くのスタブドメインにより、使用されること
ができる。スタブドメインとバックボーン間のそれぞれの出口に、NAT は設置
される。もし 2 つ以上の出口があるなら、それぞれの NAT は同じ変換テーブ
ルを持つことは、非常に重要である。
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
Figure 1: NAT Configuration
\ | / . /
+---------------+ WAN . +------------------+/
|局地的なルータ |----------------------|スタブルータ w/NAT|---
+---------------+ . +------------------+\
. | \
. | LAN
. ---------------
スタブ境界
図 1: NAT 構成
For instance, in the example of figure 2, both stubs A and B
internally use class A address 10.0.0.0. Stub A's NAT is assigned the
class C address 198.76.29.0, and Stub B's NAT is assigned the class C
address 198.76.28.0. The class C addresses are globally unique no
other NAT boxes can use them.
たとえば、図 2 の例で、スタブ A と B 両方は、class A アドレス 10.0.0.0
を内部で使用する。スタブ A の NAT は、class C アドレス 198.76.29.0 を
割り当てられ、スタブ B の NAT は、class C アドレス 198.76.28.0 を割り
当てられる。この class C アドレスは、他の NAT box が使用することができ
ない、世界で一意のアドレスである。
\ | /
+---------------+
|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
\ | /
+---------------+
|局地的なルータ |
+---------------+
WAN | | WAN
| |
スタブ A .............|.... ....|............ スタブ B
| |
{s=198.76.29.7,^ | | v{s=198.76.29.7,
d=198.76.28.4}^ | | v d=198.76.28.4}
+------------------+ +------------------+
|スタブルータ w/NAT| |スタブルータ w/NAT|
+--0---------------+ +------------------+
| |
| 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
図 2: 基本的な NAT 操作
When stub A host 10.33.96.5 wishes to send a packet to stub B host
10.81.13.22, it uses the globally unique address 198.76.28.4 as
destination, and sends the packet to it's 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 with the globally unique 198.76.29.7
before the package is forwarded. Likewise, IP packets on the return
path go through similar address translations.
スタブ A のホスト 10.33.96.5 がスタブ B のホスト 10.81.13.22 にパケッ
トを送信したい時、スタブ A のホストは、終点アドレスとして世界で一意で
あるアドレス 192.76.28.4 を使用する。そして、その最初のルータにパケッ
トを送信する。スタブルータは net 198.76.0.0 について静的な経路を持って
いて、パケットは WAN-link に転送される。しかしながら、パッケージが転送
される前に、NAT は IP ヘッダの始点アドレス 10.33.96.5 を世界で一意であ
る 198.76.29.7 に書き換える。帰り経路での IP パケットもまた、同様なア
ドレス書き換えを通過する。
Notice that this requires no changes to hosts or routers. For
instance, as far as the stub A host is concerned, 198.76.28.4 is the
address used by the host in stub B. The address translations are
completely transparent.
これはホストやルータへの変更を必要としないことがわかる。たとえば、スタ
ブ A のホストに関する限り、198.76.28.4 は、スタブ B でのホストにより使
用されるアドレスである。アドレス書き換えは、完全に透過的である。
Of course, this is just a simple example. There are numerous issues
to be explored. In the next section, we discuss various aspects of
NAT.
もちろん、これは、ただの簡単な例にすぎない。探求されるための、たくさん
の問題点がある。次のセクションで、われわれは、NAT のさまざまな側面を論
じる。
-------------------------------------------------------------------------
3. Various Aspects of NAT
3. NAT のさまざまな側面
3.1 Address Spaces
3.1 アドレス空間
Partitioning of Reusable and Non-reusable Addresses
再利用できるアドレスとできないアドレスの分割
For NAT to operate properly, it is necessary to partition the IP
address space into two parts - the reusable addresses used internal
to stub domains, and the globally unique addresses. We call the
reusable address local addresses, and the globally unique addresses
global addresses. Any given address must either be a local 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 local addresses
of stub B overlapped the local 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 local addresses.
重複による問題は、次に述べることである。スタブ A のホストがスタブ B の
ホストにパケットを送信したいと言うが、スタブ B のローカルアドレスはス
タブ A のローカルアドレスと重複していた。このケースで、スタブ A のルー
タは、それ自身のローカルアドレスからスタブ B のグローバルアドレスを識
別することができないだろう。
Initial Assignment of Local and Global Addresses
ローカルとグローバルアドレスの最初の割り当て
A single class A address should be allocated for local networks. (See
RFC 1597 [3].) This address could then be used for internets with no
connection to the Internet. NAT then provides an easy way to change
an experimental network to a "real" network by translating the
experimental addresses to globally unique Internet addresses.
たった 1 つの class A アドレスは、ローカルネットワークのために割り当て
られるべきである。(RFC 1597 [3] を参照しなさい。) このアドレスは、この
時、Internet への接続はなく、internet (相互接続) のために使用されるこ
とができる。NAT は、実験用のアドレスを世界で一意の Internet アドレスに
変換することにより、実験用のネットワークを "real (実際の)" ネットワー
クに変更する簡単な方法を、この時、提供する。
Existing stubs which have unique addresses assigned internally, but
are running out of them, can change addresses subnet by subnet to
local addresses. The freed adresses can then be used by NAT for
external communications.
内側で割り当てられた一意のアドレスを持つが、それらアドレスを使い果たし
ているような存在しているスタブは、ローカルアドレスへのサブネットにより
アドレスサブネットを変更することができる (?)。解放されたアドレスは、外
部との通信のため NAT により、その後、使用されることができる。
3.2 Routing Across NAT
3.2 NAT を横切る経路制御
The router running NAT should never advertise the local 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 が受信するグローバル情報は、スタブの普通の方法で広告されること
ができる。
Private Networks that Span Backbones
バックボーンにかかるプライベートネットワーク
In many cases, a private network (such as a corporate network) will
be spread over different locations and will use a public backbone for
communications between those locations. In this case, it is not
desirable to do address translation, both because large numbers of
hosts may want to communicate across the backbone, thus requiring
large address tables, and because there will be more applications
that depend on configured addresses, as opposed to going to a name
server. We call such a private network a backbone-partitioned stub.
多くのケースで、(企業ネットワークのような) プライベートネットワークは
異なる場所で広げられるだろうし、それらの場所の間で通信をするために公の
バックボーンを使用するだろう。このケースで、アドレス変換をすることは望
ましくない。なぜなら、たくさんのホストがバックボーンを横断して通信した
いかもしれなく、したがって大きなアドレステーブルを必要とするという理由
と、ネームサーバに問い合わせに行くとは対照的に設定されたアドレスに依存
する多くのアプリケーションがあるだろうという理由からである。われわれは
そのようなプライベートネットワークを、backbone-partitioned (バックボー
ンを分割した) スタブと呼ぶ。
Backbone-partitioned stubs should behave as though they were a non-
partitioned stub. That is, the routers in all partitions should
maintain routes to the local address spaces of all partitions. Of
course, the (public) backbones do not maintain routes to any local
addresses. Therefore, the border routers must tunnel through the
backbones using encapsulation. To do this, each NAT box will set
aside one global address for tunneling. When a NAT box x in stub
partition X wishes to deliver a packet to stub partition Y, it will
encapsulate the packet in an IP header with destination address set
to the global address of NAT box y that has been reserved for
encapsulation. When NAT box y receives a packet with that destination
address, it decapsulates the IP header and routes the packet
internally.
backbone-partitioned スタブは、あたかも分割されていないスタブのように
ふるまうべきである。すなわち、すべてのパーティションのルータは、すべて
のパーティションのローカルアドレス空間への経路を維持するべきである。も
ちろん、(公の) バックボーンは、どんなローカルアドレスへの経路も維持し
ない。それゆえ、境界ルータは、カプセル化を使用してバックボーンのために
トンネルしなければならない。このことをするために、それぞれの NAT box
は、トンネリングのために 1 つのグローバルアドレスを別にしてセットする
だろう。スタブパーティション X の NAT box x がスタブパーティション Y
にパケットを配送したい時、NAT box x はパケットをカプセル化するだろう。
これは、カプセル化のために予約された NAT box y のグローバルである終点
アドレスを持つ IP ヘッダでカプセル化される。NAT box y がその (グローバ
ルな) 終点アドレスを持つパケットを受信した時、NAT box y は IP ヘッダの
カプセル化を外し、内側にパケットを経路づける。
3.3 Header Manipulations
3.3 ヘッダ操作
In addition to modifying the IP address, NAT must modify the IP
checksum and the TCP checksum. Remember, TCP's checksum also covers a
pseudo header which contains the source and destination address. NAT
must also look out for ICMP and FTP and modify the places where the
IP address appears. There are undoubtedly other places, where
modifications must be done. Hopefully, most such applications will be
discovered during experimentation with NAT.
IP アドレスを変更することに加えて、NAT は IP チェックサムと TCP チェッ
クサムを変更しなければならない。TCP のチェックサムは、始点と終点アドレ
スを含む疑似ヘッダも扱うことを思い出しなさい。NAT は ICMP と FTP も見
張らなければならなく、IP アドレスが現れるような場所を変更しなければな
らない。変更がされなければならないような他の箇所が確かにある。うまくい
けば、大部分のそうのようなアプリケーションは、NAT での実験の間に発見さ
れるだろう。
The checksum modifications to IP and TCP are simple and efficient.
Since both 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 only tricky
part is determining whether the addition resulted in a wrap-around
(in either the positive or negative direction) of the checksum. If
so, 1 must be added or subtracted to satisfy the one's complement
arithmetic. Sample code (in C) for this is as follows:
IP と TCP へのチェックサム変更は、簡単で効率的である。両方とも 1 の補
数合計を使用するので、変換前と変換後のアドレス間の演算の差を計算するの
と、チェックサムへこの差を加えるのに十分である。唯一 tricky な部分は、
足し算がチェックサムの (正か負かの指示での) 包み込みという結果となった
かどうかを決めていることである。もしそうであるなら、1 の補数演算を満た
すために、1 は足されるか引かれなければならない。このことについての (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
*/
/* unsigned char は 8 bits で、long は 32 bits を仮定する。
- chksum は、packet の chksum を指す。
- optr は、packet の古いデータを指す。
- nptr は、packet の新しいデータを指す。
*/
{
long x, old, new;
x=chksum[0]*256+chksum[1];
x=~x;
while (olen) {
if (olen==1) {
old=optr[0]*256+optr[1];
x-=old & 0xff00;
if (x<=0) { x--; x&=0xffff; }
break;
}
else {
old=optr[0]*256+optr[1]; optr+=2;
x-=old & 0xffff;
if (x<=0) { x--; x&=0xffff; }
olen-=2;
}
}
while (nlen) {
if (nlen==1) {
new=nptr[0]*256+nptr[1];
x+=new & 0xff00;
if (x & 0x10000) { x++; x&=0xffff; }
break;
}
else {
new=nptr[0]*256+nptr[1]; nptr+=2;
x+=new & 0xffff;
if (x & 0x10000) { x++; x&=0xffff; }
nlen-=2;
}
}
x=~x;
chksum[0]=x/256; chksum[1]=x & 0xff;
}
The arguments to the File Transfer Protocol (FTP) PORT command
include an IP address (in ASCII!). If the IP address in the PORT
command is local to the stub domain, then NAT must substitute this.
Because the address is encoded in ASCII, this may result in a change
in the size of the packet (for instance 10.18.177.42 is 12 ASCII
characters, while 193.45.228.137 is 14 ASCII characters). If the new
size is the same as the previous, only the TCP checksum needs
adjustment (again). If the new size is less than the previous, ASCII
zeroes may be inserted, but this is not guaranteed to work. If the
new size is larger than the previous, TCP sequence numbers must be
changed too.
File Transfer Protocol (FTP) PORT コマンドへの引数は、(ASCII (コード)
での !) IP アドレスを含む。もし PORT コマンドでの IP アドレスがスタブ
ドメインに対しローカルであるなら、そのとき NAT は、このアドレスを代わ
りに用いなければならない。アドレスは ASCII で符号化されているので、こ
れはパケットサイズの変更という結果になるかもしれない (たとえば、
10.18.177.42 は 12 個の ASCII 文字である。だが 193.45.228.137 は 14 個
の ASCII 文字である)。もし新しいサイズが前と同じであるなら、TCP チェッ
クサムのみが (再び) 調整を必要とする。もし新しいサイズが前より小さいな
ら、ASCII (コード) のゼロが挿入されるかもしれないが、これは動作するこ
とを保証しない。もし新しいサイズが前より大きいなら、TCP 順序番号も変更
されなければならない。
A special table is used to correct the TCP sequence and acknowledge
numbers with source port FTP or destination port FTP. The table
entries should have source, destination, source port, destination
port, initial sequence number, delta for sequence numbers and a
timestamp. New entries are created only when FTP PORT commands are
seen. The initial sequence numbers are used to find out if the
sequence number of a packet is before or after the last FTP PORT
command (delta may be increased for every FTP PORT command). Sequence
numbers are incremented and acknowledge numbers are decremented. If
the FIN bit is set in one of the packets, the associated entry may be
deleted soon after (1 minute should be safe). Entries that have not
been used for e.g. 24 hours should be safe to delete too.
特別なテーブルが、source port FTP や destination port FTP を持つ TCP
sequence と acknowledge 番号を直すために使用される。テーブルエントリは
始点、終点 (アドレス)、source port、destination port、初期順序番号、順
序番号とタイムスタンプのためのデルタ (差) を持つべきである。新しいエン
トリは、FTP PORT コマンドが見られる時のみ作成される。初期順序番号は、
パケットの順序番号が最後の FTP PORT コマンドの前か後かどうかを見つけ出
すために使用される (デルタは、すべての FTP PORT コマンドのために増やさ
れるかもしれない)。順序番号は増やされ、確認応答番号は減らされる。もし
パケットの 1 つに FIN ビットがセットされるなら、関連されるエントリは、
すぐ後に削除されるかもしれない (1 分は安全であろう)。たとえば 24 時間
の間、使用されないエントリは削除しても間違いはないだろう。
The sequence number adjustment must be coded carefully, not to harm
performance for TCP in general. Of course, if the FTP session is
encrypted, the PORT command will fail.
順序番号調整は、一般に TCP のパフォーマンスを傷つけることなく、注意深
くコード化されなければならない。もちろん、もし FTP セッションが暗号化
されるなら、PORT コマンドは失敗するだろう。
If an ICMP message is passed through NAT, it may require two address
modifications and three checksum modifications. This is because most
ICMP messages contain part of the original IP packet in the body.
Therefore, for NAT to be completely transparent to the host, the IP
address of the IP header embedded in the data part of the ICMP packet
must be modified, the checksum field of the same IP header must
correspondingly be modified, and the ICMP header checksum must be
modified to reflect the changes to the IP header and checksum in the
ICMP body. Furthermore, the normal IP header must also be modified as
already described.
ICMP メッセージが NAT を通過するなら、2 つのアドレス変更と 3つのチェッ
クサム変更を必要とするかもしれない。これは、大部分の ICMP メッセージが
それ自身に、もともとの IP パケット部分を含むからである。それゆえ、NAT
がホストに対し完全に透過的であるために、ICMP パケットのデータ部分に埋
め込まれた IP ヘッダの IP アドレスは変更されなければならないし、同じ
IP ヘッダのチェックサムフィールドは同様に変更されなければならなく、
ICMP ヘッダチェックサムは ICMP データ部分の IP ヘッダとチェックサムへ
の変更を反映するために変更されなければならない。それだけでなく、正常な
IP ヘッダもすでに記述されたとして変更されなければならない。
It is not entirely clear if the IP header information in the ICMP
part of the body really need to be modified. This depends on whether
or not any host code actually looks at this IP header information.
Indeed, it may be useful to provide the exact header seen by the
router or host that issued the ICMP message to aid in debugging. In
any event, no modifications are needed for the Echo and Timestamp
messages, and NAT should never need to handle a Redirect message.
もし ICMP データ部分の IP ヘッダ情報がほんとうに変更をされる必要がある
なら、これは完全にクリアではない。これは、いずれにせよ、この IP ヘッダ
情報を実際に見る何らかのホストのコードに依存する。いや実際、デバッグを
助けるため ICMP メッセージを発行したルータやホストにより見られる、正確
なヘッダを提供するのに役立つかもしれない。どんなイベントでも、Echo と
Timestamp メッセージのための変更は必要とされなく、NAT は Redirect メッ
セージを扱う必要が決してあるべきではない。
SNMP messages could be modified, but it is even more dubious than for
ICMP messages that it will be necessary.
SNMP メッセージは変更されることが出来る。しかし ICMP メッセージが必要
であるよりも、よりあいまいでさえある。
Applications with IP-address Content
IP アドレスを満足するアプリケーション
Any application that carries (and uses) the IP address inside the
application will not work through NAT unless NAT knows of such
instances and does the appropriate translation. It is not possible or
even necessarily desirable for NAT to know of all such applications.
And, if encryption is used then it is impossible for NAT to make the
translation.
もし NAT がこのようなインスタンスを知っていないで適切な変換をおこなわ
ないならば、アプリケーション内部の IP アドレスを運ぶ (そして使用する)
どんなアプリケーションも NAT を通して動作しないだろう。NAT が、すべて
のそのようなアプリケーションを知っていることは可能ではなく、必ずしも望
ましいことでさえない。そして、もし暗号化がその時に使用されるなら、NAT
が変換をおこなうことは不可能である。
It may be possible for such systems to avoid using NAT, if the hosts
in which they run are assigned global addresses. Whether or not this
can work depends on the capability of the intra-domain routing
algorithm and the internal topology. This is because the global
address must be advertised in the intra-domain routing algorithm.
With a low-feature routing algorithm like RIP, the host may require
its own class C address space, that must not only be advertised
internally but externally as well (thus hurting global scaling). With
a high-feature routing algorithm like OSPF, the host address can be
passed around individually, and can come from the NAT table.
もしそのようなシステムが走っているホストで、そのホストがグローバルアド
レスを割り当てられるなら、システムが NAT の使用を避けることは可能かも
しれない。これが動作することができるにせよそうでないにせよ、イントラド
メイン経路制御アルゴリズム能力と内部のトポロジに依存する。これはグロー
バルアドレスがイントラドメイン経路制御アルゴリズムで広告されなければな
らないからである。RIP のような低い特徴の経路制御アルゴリズムを用いて、
内部だけでなく外部にもまた広告されなければならないホストは、それ自身の
class C アドレス空間を必要とするかもしれない (したがってグローバルな経
路表増大を害する)。OSPF のような高い特徴の経路制御アルゴリズムを用いて
ホストアドレスは個別に通過されることができ、NAT テーブルから取り出すこ
とができる。
Privacy, Security, and Debugging Considerations
プライバシー、セキュリティとデバッグに関する考察
Unfortunately, NAT reduces the number of options for providing
security. With NAT, nothing that carries an IP address or information
derived from an IP address (such as the TCP-header checksum) can be
encrypted. While most application-level encryption should be ok, this
prevents encryption of the TCP header.
不運にも、NAT はセキュリティを提供するためのオプションの数を減らす。
NAT を用いることで、IP アドレスや (TCP ヘッダチェックサムのような) IP
アドレスから得られる情報を運ぶものは、何も暗号化されることができない。
大部分のアプリケーションレベル暗号化はうまくいくだろうが、これは TCP
ヘッダの暗号化を妨げる。
On the other hand, NAT itself can be seen as providing a kind of
privacy mechanism. This comes from the fact that machines on the
backbone cannot monitor which hosts are sending and receiving traffic
(assuming of course that the application data is encrypted).
他方では、NAT それ自身は、プライバシーメカニズムに近いものを提供するも
のとして、見られることができる。これはバックボーン上のマシンが、どのホ
ストがトラフィックを送受信しているかをモニタできない、という事実からく
る (もちろん、アプリケーションデータは暗号化されていると仮定する)。
The same characteristic that enhances privacy potentially makes
debugging problems (including security violations) more difficult. If
a host is abusing the Internet is some way (such as trying to attack
another machine or even sending large amounts of junk mail or
something) it is more difficult to pinpoint the source of the trouble
because the IP address of the host is hidden.
プライバシーを潜在的に高める同一の特徴は、(セキュリティ違反を含む) デ
バッグ問題をさらに難しくする。もし Internet を乱用しているホストが (他
のマシンを攻撃しようと試みていたり、junk メールを大量に送信することで
さえ、または何かのような) 何らかの状態であるなら、トラブルの元を正確に
示すことは、さらに難しい。なぜならホストの IP アドレスは隠されているか
らである。
-------------------------------------------------------------------------
4. Conclusions
4. 結論
NAT may be a good short term solution to the address depletion and
scaling problems. This is because it requires very few changes and
can be installed incrementally. NAT has several negative
characteristics that make it inappropriate as a long term solution,
and may make it inappropriate even as a short term solution. Only
implementation and experimentation will determine its
appropriateness.
NAT は、アドレス枯渇と経路表増大に対し、よい短期的な解決法であるかもし
れない。これは、ほとんど変更を必要としないことと、少しずつ設置すること
ができるからである。NAT は、長期的解決法としてふさわしくさせなく、短期
的解決法としてもふさわしくさせない、いくつかのマイナスの特徴を持つ。実
装と実験のみが、そのふさわしさを決定するだろう。
The negative characteristics are:
マイナスの特徴は、(次のとおりである):
1. It requires a sparse end-to-end traffic matrix. Otherwise, the NAT
tables will be large, thus giving lower performance. While the
expectation is that end-to-end traffic matrices are indeed sparse,
experience with NAT will determine whether or not they are. In any
event, future applications may require a rich traffic matrix (for
instance, distributed resource discovery), thus making long-term use
of NAT unattractive.
これは、まばらな end-to-end トラフィックマトリックスを必要とする。もし
そうでなければ、NAT テーブルは大きくなるだろうし、したがってパフォーマ
ンスは低下する。期待は end-to-end トラフィックマトリックスが実際まばら
であることだが、NAT を用いた経験が、実際にまばらであるかどうかを決定す
るだろう。どんなイベントでも、将来のアプリケーションは、ぜいたくなトラ
フィックマトリックス (たとえば、分配されたリソース発見) を必要とするか
もしれなく、したがって長期的な NAT の使用を魅力ないようにさせる。
2. It increases the probability of mis-addressing.
これは、アドレス誤りの確率を増やす。
3. It breaks certain applications (or at least makes them more difficult
to run).
これは確実なアプリケーションを壊す (もしくは、少なくともそれらを走らせ
ることを、より困難にさせる)。
4. It hides the identity of hosts. While this has the benefit of
privacy, it is generally a negative effect.
これはホストの身元を隠す。これはプライバシーの恩恵を持つが、たいていマ
イナスの影響がある。
5. Problems with SNMP, DNS, ... you name it.
SNMP, DNS, ... あなたが名前を上げるものの問題。
Current Implementations
現在の実装
Paul and Tony implemented an experimental prototype of NAT on public
domain KA9Q TCP/IP software [1]. This implementation manipulates
addresses and IP checksums.
Paul と Tony は、public domain KA9Q TCP/IP software [1] で NAT の実験
のためのプロトタイプを実装した。この実装は、アドレスと IP チェックサム
を操作する。
Kjeld implemented NAT in a Cray Communications IP-router. The
implementation was tested with Telnet and FTP. This implementation
manipulates addresses, IP checksums, TCP sequence/acknowledge numbers
and FTP PORT commands.
Kjeld は、Cray Communications IP-router で NAT を実装した。実装は、
Telnet と FTP でテストされた。この実装は、アドレス、IP チェックサム、
TCP 順序/確認応答番号と FTP PORT コマンドを操作する。
The prototypes has demonstrated that IP addresses can be translated
transparently to hosts within the limitations described in this
paper.
これらのプロトタイプは、この文書で記述された制限の範囲内で IP アドレス
がホストへ透過的に変換されることが出来ることを実証した。
-------------------------------------------------------------------------
REFERENCES
参考文献
[1] Karn, P., "KA9Q", anonymous FTP from ucsd.edu
(hamradio/packet/ka9q/docs).
[2] Fuller, V., Li, T., and J. Yu, "Classless Inter-Domain Routing
(CIDR) an Address Assignment and Aggregation Strategy", RFC 1519,
BARRNet, cisco, Merit, OARnet, September 1993.
[3] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot,
"Address Allocation for Private Internets", RFC 1597, T.J. Watson
Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.
-------------------------------------------------------------------------
Security Considerations
セキュリティに関する考察
Security issues are not discussed in this memo.
セキュリティに関する問題は、このメモで論じられない。
-------------------------------------------------------------------------
Authors' Addresses
著者のアドレス
Kjeld Borch Egevang
Cray Communications
Smedeholm 12-14
DK-2730 Herlev
Denmark
Phone: +45 44 53 01 00
EMail: kbe@craycom.dk
Paul Francis
NTT Software Lab
3-9-11 Midori-cho Musashino-shi
Tokyo 180 Japan
Phone: +81-422-59-3843
Fax +81-422-59-3765
EMail: francis@cactus.ntt.jp
---
Copyright (C) The Internet Society (May 1994). 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.
一覧
スポンサーリンク
