<!doctype linuxdoctr system>
<article>
<title>Proxy ARP mini-HOWTO</title>
<author>Al Longyear, &lt;longyear@netcom.com&gt;</author>
<date>December 5, 1994</date>
<trans>川島 浩, &lt;kei@sm.sony.co.jp&gt;</trans>
<tdate>October 1, 1996</tdate>

<![IGNORE[
ProxyARP の使用に関する小さな論文 1994/12/05 版

Al Longyear &lt;longyear@netcom.com&gt; 著

日本語訳 : 川島 浩 (kei@sm.sony.co.jp)
校正     : 堀江 誠一 さん  (shorie@ibm.net)
           鴨澤 眞夫 さん (k957134@sci.u-ryukyu.ac.jp)
           中野 武雄 さん (nakano@apm.seikei.ac.jp)


== 訳者より ==
これは、Linux MINI-HOWTO の、Proxy-ARP の翻訳です。
意訳も多くありますが、ご容赦ください。
また、誤訳や、もっとわかりやすい訳案などありましたら、
ぜひ訳者までフィードバックをお願い致します。
==============
]]>

<abstract>
Proxy ARP の設定方法
</abstract>

<p>
<bf>注意: この文書はかなり以前に書かれたものなので、
いまどきの Linux 環境にはあてはまらない箇所があります。
(JF Project)</bf>
</p>

<sect><!--Introduction-->イントロダクション
<p>
<!--
This document is written to help those who are considering using the
proxy ARP (Address Resolution Protocol) logic within Linux in the aid
of PPP and SLIP server devices. Proxy ARP is also called 'gracious
ARP' in some sources of documentation. There have been numerous
requests for the use of proxy ARP. When it is not able to be used,
some people deem this as a flaw in the software and wonder why it is
broken.
-->
このドキュメントは Linux 上で PPP や SLIP サーバデバイスとともに
プロクシ ARP (Address Resolution Protocol) を使おうと考えている人
を対象にして書かれています。
他の文献では、プロクシ ARP を 「gracious ARP」 (愛想のよい ARP)などと
呼んでいることもあります。
プロクシ ARP を使いたいという要求はよく出ます。これが使えない場合、
ソフトウエアの不良だと考え、なぜ使えなくなってしまったのだろう、
といぶかる人達もいます。

<!--
I hope that with the aid of this document, people will understand
more about proxy ARP as well as when it is and is not useful.
-->
このドキュメントが助けとなって、プロクシ ARP はどのようなときに有用で、
どのようなときには使わなくてもよいのかをよく理解してもらえるよう
願っています。

<!--
The use of proxy ARP is useful when you have a server. It will allow
the dynamic connection of remote systems without the need for the
update of the routing tables on other system but the one associated
as the 'server'.
-->
プロクシ ARP を使うと、「(プロクシ)サーバ」における経路テーブルさえ
変更すれば、他のシステムでは経路テーブルを変更する必要がありません。
このことは、リモートシステムの動的なネットワーク接続が可能になると
いうことを意味しています。

<!--
The term 'server' is somewhat of a misnomer. TCP/IP is a peer-to-peer
networking environment. It does not have a client to server relation
as other systems do in that resources are offered or 'shared' on
servers while clients 'use' them. However, it is convenient to call the
'system which answers the telephone' a server; while the 'system
which dials the telephone to connect to the server' a client.
-->
ここで、「サーバ」と呼んでいるのは、ある意味では誤りかもしれません。
TCP/IP は、ピアーツーピアー(対等)のネットワーク環境だからです。
他のシステムでは、サーバーが資源を提供することで、「共有」され、
クライアントはこれを「利用」しますが、TCP/IP には、この手の
クライアント／サーバー関係はありません。
とはいえ、「電話を取るコンピュータ」をサーバと呼び、
「電話を架けるコンピュータ」をクライアントと呼ぶのは便利ですよね。

<!--
Linux's networking software directly supports proxy ARP. There is
no need for a special daemon process such as proxyarpd used in some
systems.
-->
Linux のネットワークソフトは プロクシ ARP を直接サポートしています
ので、他のシステムで使われている proxyarpd のような特別なデーモン
は必要ありません。

<!--
Both the PPP protocol support code, pppd, and at least one of the SLIP
support code, dip-uri, will support proxy ARP. In addition, the
networking program, arp, will manage and display the table.
-->
PPP をサポートするコード（pppd）と、SLIP をサポートするコード（の少
なくとも一つ、dip-uri）の両方が proxy ARP をサポートしているはずです。
これに加え、ネットワーク用プログラム ARP も経路テーブルを管理し、
表示することができるはずです。

<!--
To understand how Proxy ARP works and when it may be used, you need to
have a basic understanding of how networking is performed in general.
The next three sections of this document will describe in the
briefest of terms how TCP/IP networking is performed and how routing
works.
-->
プロクシ ARP がどのように動作し、どんな時に使われるのかを理解する
ためには、一般的にネットワークがどのように機能するのかについて
基本的理解が必要です。
以下の3つの章では TCP/IP ネットワークがどのように機能し、ルーティングが
どういう風に動作するのか、を簡単に述べます。


<sect><!--The Hardware side of Networking-->ハードウエア側から見たネットワーク
<p>
<!--
All networking using ethernet or token ring is performed using a MAC
(Media Access Control) address. This is a hardware address associated
with a specific controller. Each MAC address is unique. They are
assigned by the manufacturer of the controller. While they may be
overridden in software, this is not the general rule.
-->
イーサネットやトークンリングを使ったネットワークはすべて MAC
(Media Access Control) アドレスを使って実現されています。
これはそれぞれのコントローラーに割り当てられたハードウエアアドレス
であり、それぞれの MAC アドレスは世界中で唯一(unique)のものです。
これはコントローラーのメーカが割り当てます。
ソフトウエアによって変更することも可能ですが、一般的な意味では
ルール違反です。

<!--
IP addresses are translated to MAC addresses using a special table
within the networking software called the `ARP cache'. When the
networking software wishes to send an IP frame to the specified
address, it will consult this cache to determine the MAC address. If
the entry is not found in the cache, a special request is made of all
systems attached to the network to resolve the IP address to a MAC
address. This is called an ARP request.
-->
IP アドレスは 「ARP キャッシュ」 と呼ばれる、ソフトウエア上の特別な
テーブルによって MAC アドレスに変換されます。
ネットワークソフトが、 IP パケットを指定されたアドレスに送る時
には、MAC アドレスを知るためにこのキャッシュを検索します。
キャッシュの中になかった場合には、 IP アドレスから MAC アドレス
に変換するために、ネットワークに接続されているすべてのシステムに
対して特殊な要求を発行します。
これが ARP (Address Resolution Protocol)要求と呼ばれているものです。

<!--
The response to the ARP request is a reply with the MAC address. This
MAC address is then added to the cache so that the translation may be
performed subsequently without the aid of ARP.
-->
ARP 要求に対しては それに対応する MAC アドレスが返されます。
この MAC アドレスは、次には ARP を使わなくて済むように、キャッシュ
に蓄えられます。

<!--
It is this ARP request which is used by the proxy ARP logic to aid
in the support of remote connections.
-->
プロクシ ARP はこの仕組みを使って、リモート接続をうまく処理することが
できるわけです。

<!--
There are rules by which the entries in the cache are removed. Those
rules are not germane to this document and are best left to a
technical description of ip networking.
-->
キャッシュの中のエントリーを削除するルールもありますが、この
ドキュメントではそれについては触れません。これに関しては 
IP ネットワークに関するドキュメントを参照して下さい。

<!--
(While token ring is under development, and is available on a test
basis, the common networking transport media for Linux is ethernet. I
will use the term 'ethernet' from now on. Similar facilities are
available for token ring, irrespective of token ring's source routing.)
-->
(トークンリングは開発中で、テストベースでは利用可能ですが、
Linux の一般的なネットワーク媒体という意味ではやはりイーサネット
です。ですからここから先、「イーサネット」という言葉を使います。
同様の機能はトークンリングでも使えます。トークンリングの
ソースルーティングに関わりなく。)


<sect><!--III. Reason for the use of Proxy ARP-->
III. プロクシ ARP を使う理由
<p>
<!--
The purpose of proxy ARP is to allow the assignment of more than one
IP address to a single network adapter.
-->
目的は、ひとつのネットワークアダプタに対して、2つ以上の
IP アドレスを割り当てることにあります。

<!--
The manner in which it does this is to create an entry in the ARP
cache of Linux which associates the additional IP address with the
hardware address of the ethernet controller. This permits the Linux
system to respond to an ARP request to translate an IP address to a
hardware address.
-->
これは、イーサネットコントローラのハードウエアアドレスに対応した、
追加の IP アドレスのエントリーを ARP キャッシュに生成することで
実現されます。
これによって、 IP アドレスをハードウエア (MAC) アドレスに変換する
ARP 要求に対して Linux システムはうまく応答することができるわけ
です。


<sect><!--IV. TCP/IP Routing-->TCP/IP ルーティング
<p>
<!--
[A small preface is in order at this time. This describes the
'spanning-tree' routing. It does not describe 'source-routing' of IP
frames. The source routing performed by token ring is not IP source
routing but is performed at the MAC layer. The use of IP source
routing is discouraged. Token ring MAC source routing is a
requirement of that transport.]
-->
&lsqb;前もっておことわりしますが、ここでは、「スパンニング・ツリー
(spanning-tree)」ルーティングについて述べており、IP パケットの
「ソース・ルーティング(source-routing)」ではありません。
トークンリングではソースルーティングが使われますが、これは IP の
ソースルーティングではなく、（トークンリングの）MAC 層で行われて
るものです。
トークンリングで MAC ソースルーティングを行っているのは、それが
トークンリングによるパケットの配送に必要だからです。
一般的には IP ソースルーティングを使う事は推奨できません。&rsqb;

<!--
To understand more about proxy ARP, you need to understand how IP
frames are routed on the network. I do not plan to go into great
detail. If you wish additional information, there are many books
available which will offer more in-depth information. (If you don't
wish the books, then look at the RFC documents.)
-->
プロクシ ARP についてもっと詳しく知るためには、IP パケットが
ネットワーク上でどのようにルーティングされるのかを知る必要がありますが、
ここではあまり詳しく述べるつもりはありません。
詳しい情報を知りたい方には、深く解説された、たくさんの本があります。
(本が嫌いでしたら、RFC ドキュメントをお読みください。)

<!--
IP frames are routed at each stage of their passage through the
network. Each host, router, and gateway decides for itself and based
upon its own copy of the routing tables where the specific IP frame is
to be transmitted.
-->
IP パケットは、それが経由するネットワークのそれぞれの段階で
ルーティングされます。それぞれのホスト、ルーター、ゲートウエイ
は、それぞれが経路テーブル情報のコピーを所有し、それに
もとづいてそれぞれの IP パケットをどこに送ればよいかを決定します。

<!--
The routing is performed using the term which I will call an
'IP network'. Each network interface is assigned an unique IP network.
Each is given an IP address. Each is given a netmask. The 'IP network'
is simply the logical conjunction of the IP address with the netmask.
For example, the IP address of 10.124.35.40 and the netmask of
255.255.0.0 would have an 'IP network' of 10.124.0.0. While I am using
byte netmasks, the same logic would apply to the non-byte boundary
netmasks.
-->
ルーティングは、「IP ネットワーク」 を使って行なわれます。
それぞれのネットワークインターフェースには、ユニークな IP 
ネットワークと、IP アドレス、ネットマスクが割り当てられています。
「IP ネットワーク」 とは、単純にIP アドレスと ネットマスクのビット
ごとの積をとったものです。例えば、IP アドレス 10.124.35.40 で、
ネットマスクが 255.255.0.0 の場合には、「IP ネットワーク」 は、
10.124.0.0 となります。
この例ではバイト単位のネットマスクを使っていますが、バイト単位では
ないネットマスク(訳注:例えばサブネッティングした時など)の場合でも
同様です。

<!--
Linux associates the netmask with the route entry. When you add a
route into the system, you specify a IP address and the associated
destination device. If you don't specify a netmask, the netmask is
taken from the destination device's default netmask which is set when
the device is configured with ifconfig.
-->
Linux はネットマスクを経路エントリーと関連づけます。
システムに経路を付け加える時 (訳注: route コマンドなど) には、
そのIP アドレスと関連する行き先のデバイスを指定しますが、
この際にネットマスクを指定しなければ、ifconfig でそのデバイス
を設定したときに指定したデフォールトネットマスクが使われます。

<!--
To better understand routing, consider the following configuration of
a sample system.
-->
ルーティングに関しての理解を助けるために、次のような構成の
システムを考えてみましょう。

<tscreen><verb>
Destination     Netmask          Gateway       Flags    Device
10.124.0.0      255.255.0.0      0.0.0.0       U        eth0
10.125.0.0      255.255.0.0      0.0.0.0       U        eth1
10.126.0.0      255.255.0.0      10.125.31.1   UG       eth1
10.124.12.5     255.255.255.255  0.0.0.0       UH       ppp0
0.0.0.0         0.0.0.0          10.124.25.1   U        eth0
</verb></tscreen>

<!--
This is a system with three network devices. It has two ethernet
controllers and one PPP device. IP frames may come into this system
from any one of the three sources. In addition, frames are forwarded
through this system to any one of the three destination devices.
-->
このシステムは3つのネットワークデバイスを持っています。
2つはイーサネットコントローラで、1つは PPP デバイスです。
これら3つのいずれからも IP パケットは到着し、さらにこのシステム
を通じて、 3つのどのデバイスに対してもパケットは転送されます。

<!--
The default route is to the gateway device at 10.124.25.1 as
demonstrated by the last entry. To reach that gateway, the frame is
to be transmitted by the eth0 controller.
-->
デフォールトの経路は、上のエントリーで示されている通り、
10.124.25.1 のゲートウエイデバイスです。
ゲートウエイに送るためには eth0 コントローラが使われます。

<!--
There is one PPP device connected. Its IP address is 10.124.12.5.
-->
PPP デバイスが1つ接続されており、その IP アドレスは 10.124.12.5
です。

<!--
The eth0 device is on the IP network of 10.124.0.0 while the eth1
device is on the IP network 10.125.0.0.
-->
eth0 デバイスは IP ネットワーク 10.124.0.0 上にあり、eth1 デバイスは
IP ネットワーク 10.125.0.0上にあります。

<!--
In addition, there is a net route to the IP network 10.126.0.0
available at the gateway associated with 10.125.31.1.
-->
さらに、IP アドレス 10.125.31.1 のゲートウエイを通じて利用可能な
IP ネットワーク 10.126.0.0 へのネット経路が存在します。

<!--
To understand how routing is performed, consider an IP frame for the
destination of 10.125.45.1.
-->
ルーティングがどのように行われるのかを理解するために、10.125.45.1
に送られる IP パケットを考えてみましょう。

<!--
Linux will go through the route table and for each entry, take the
netmask, perform a logical conjunction (and) with the netmask and
then compare it to the entry's destination IP address. If the result
matches, the frame is sent to the device indicated.
-->
Linux は経路テーブルを検索し、それぞれのエントリからネットマスクを
取りだし、ビットごとの積をとり、行き先の IP アドレスと比較します。
合致したら、パケットはそのデバイスに送られます。

<!--
The result is that the frame for the IP address of 10.125.45.1 will
be sent to the eth1 device.
-->
結果として、IP アドレス 10.125.45.1 のパケットは、eth1 デバイスに
送られます。

<!--
Likewise a frame for the IP address of 10.124.12.5 will go to the
ppp0 device while the IP address of 10.124.12.6 will go to the eth0
device since the ppp0 device will only accept its one IP address of
10.124.12.5.
-->
同様に、 IP アドレス 10.124.12.6 のパケットは eth0 デバイスに送られ
るのですが、IP アドレス 10.124.12.5 のパケットは ppp0 デバイスに
送られます。
なぜなら、ppp0 デバイスは 10.124.12.5 というただひとつの
IP アドレスだけしか受け取ることができないからです。

<!--
Frames for 10.126.31.4 are different. They have a 'gateway'
associated with them. They are found in the similar manner. However,
instead of just sending them to the eth1 device, they are sent to the
one system which is associated with the IP address of 10.125.31.1. It
is this IP address which is translated to a MAC address, rather than
the destination address, 10.126.31.4.
-->
10.126.31.4 宛のパケットの場合はちょっと異なります。
この場合には、このアドレスに接続された「ゲートウエイ」が存在する
からです。
上で述べたようなのと同じ方法で検索されますが、ただ単に eth1 デバイス
に送られるのではなく、10.125.31.1 という IP アドレスのシステムに
送られるのです。つまり、最終的な行き先のアドレス 10.126.31.4 ではなく、
ゲートウエイの IP アドレス (10.125.31.1) に対応する MAC アドレスに
送られるわけです。

<!--
When they arrive at the 10.126.31.1 system, that system will forward
them on to the final destination of 10.126.31.4 by using its routing
table which may say to send it on its eth3 interface.
-->
10.125.31.1 のシステムに到着したら、そのシステムの経路テーブルを
使って、最終的な行き先の 10.126.31.4 に転送されます (たとえばその
システムの eth3 インターフェースを使って)。

<!--
There are many error conditions which are caught by this form of
routing. I don't want to go into all of them, however, if for
example, 10.126.31.1 did not have a path to reach the .4 address,
then it would send back a ICMP (Internet Control Message Protocol)
frame to the original sender that it does not have a 'route to the
host' condition.
-->
このようなルーティングでは、いろいろな誤りが発生し得ます。
それについてはここではあまり触れたくありませんが、たとえば、
10.126.31.1 が 10.126.31.4 のアドレスに対する経路を持っていなかった場合、
もともとの送り元に対して、ICMP (Internet Control Message Protocol)
パケットを送り返し、「そのホストに対する経路が無い」ことを知らせます。


<sect><!--V. Routing with Proxy ARP-->プロクシ ARP によるルーティング
<p>
<!--
Finally, we are getting to the focus of this document now that all of
the foundation has been described.
-->
さて、基礎として必要な部分については説明が終わったので、このドキュメント
の目的の部分に移ることにしましょう。

<!--
Remember that Linux will put an entry into the ARP cache for the IP
address and the associated hardware MAC address when it is to do proxy
ARP. Remember that this cache is used to translate IP addresses to
MAC addresses.
-->
プロクシ ARP を実行している Linux が、IP アドレスおよび対応するハー
ドウエア MAC アドレスのエントリを ARP キャッシュに格納することと、
このキャッシュが IP アドレスを MAC アドレスに変換するのに使われると
いうことを思い出して下さい

<!--
When the remote connects at IP address 10.124.12.5, the Linux system
will add this IP address and the MAC address associated with the eth0
controller to the ARP cache.
-->
リモートシステムが IP アドレス 10.124.12.5 に接続するときに、Linux
はこの IP アドレスと、eth0 コントローラに対応する MAC アドレスを ARP
キャッシュに格納します。

<!--
When it receives a request to translate the IP address 10.124.12.5 to
a MAC address, it will send the entry from its tables to the
requester. The result is that frames to this IP address will be sent
to the server and the server may then forward them to the remote
system.
-->
その後に IP アドレス 10.124.12.5 を MAC アドレスに変換する要求 (ARP) 
を受け取った場合、このテーブルから得たエントリーを要求元に返します。
その結果、この IP アドレスに送られたパケットは、いったんこのサーバに
送られ、サーバはそれをリモートシステム (10.124.12.5) に転送します。

<!--
This is how proxy ARP works. The server is a proxy (an agent, an
inter-lopper, a 'front' person, etc.) for the remote IP address. It is
saying to the network that it can accept frames for the remote IP
address and deliver them by responding to the ARP requests.
-->
これが プロクシ ARP の仕組みです。
サーバは リモートな IP アドレスに対する proxy (つまり、代理人、でしゃばり屋、
「表向きの」人などなど) として機能するわけです。
つまり、ARP 要求に応答することで、リモートな IP アドレスに対する
パケットを受け付け、それらを転送するわけです。

<!--
So, for proxy ARP to work, the IP address of the remote (10.124.12.5
in my example) needs to be on one of the IP networks for a network
adapter.
-->
ところで、プロクシ ARP がうまく動作するためには、リモートな IP アドレス
(この例では 10.124.12.5) は、(訳注:サーバに接続されている) ネットワーク
アダプタの IP ネットワークのうちの一つでなければなりません。

<!--
There are two reasons for this requirement.
-->
これには二つの理由があります。

<!--
The first reason is that the MAC address of the controller is entered
into the ARP cache to be associated with the IP address. A MAC
address is required for the ARP assignment since the ARP cache is a
translation from IP addresses to MAC addresses.
-->
一つ目の理由は、コントローラの MAC アドレスは、それに対応する IP アドレス
の ARP キャッシュに格納されるからです。ARP キャッシュは、IP アドレス
から MAC アドレスへの変換テーブルなので、ARP 割り当て (assignment) を
おこなうためには、MAC アドレスが必要です。

<!--
The second reason is that all systems on the network do their own
routing. They know that to send a IP frame to the remote's IP address
that they must 'put it on the same wire' which is connected to the
server's network adapter.
-->
二番目の理由は、ネットワーク上のすべてのシステムは、それぞれ独自に
ルーティングをおこなっているという点です。
しかし、それぞれのシステムは少なくとも、リモートな IP アドレスに対して
IP パケットを送るためには、「それと同じ線につながっている」サーバの
ネットワークアダプタに送らなければならないことはわかっています。

(校正者注:リモート 10.124.12.5 に対する Proxy ARP をあてがう
インターフェースは、10.124.0.0 ネットワークに接続されている必要がある、
ということでしょう。
ほかのネットワークにあるシステムが 10.124.12.5 にパケットを送る場合、
とりあえず 10.124.0.0 のネットワークまで要求を送り付けてくるはずなの
で、インターフェースが 10.123.0.0 ネットワークなどにあっても、そもそ
も ARP 要求があったことがわかりませんから。（ARP 要求はネットワークに
対するブロードキャストとして実行されるのではなかったかと思います。）)

<sect><!--VI. When Proxy ARP will not work-->
プロクシ ARP がうまく動作しない場合
<p>
<!--
Consider what would happen if the remote's IP address was 10.200.3.1
rather than 10.124.12.5.
-->
リモートの IP アドレスが、10.124.12.5 ではなくて、例えば 10.200.3.1 の
場合を考えてみましょう。

<enum>

<item>
<!--
1. The remote systems would not know where to send this address.
-->
リモートシステムは、このアドレスをどこに送ったらいいかわからない。
<p>
<!--
They all know that to reach the IP network 10.124.0.0 that the frames
should go on the cable attached to eth0. However, there is no IP
network for 10.200.0.0. They would not know where to send frames to
this destination.
-->
リモートシステムがわかっているのは、IP ネットワーク 10.124.0.0 に送る
ためには eth0 に接続されているケーブルにパケットを送ればいい、という
ことだけです。しかし、10.200.0.0 という IP ネットワークはありません。
この宛先のパケットをどこへ送ればいいのかわからないわけです。

<item>
<!--
2. The server would not know what controller to use for the
   appropriate MAC address when it made the ARP entry.
-->
ARP エントリーを作成する時に、サーバは対応する MAC アドレスに
対して、どのコントローラを使えばよいのかわからない。
<p>
<!--
This is the most common reason why proxy ARP will not work for people
who wish to use it. They have a different IP network associated with
the remote IP address than one of their own network interfaces.
-->
これは、プロクシ ARP を使おうとしてもうまく動作しない場合に、最もよくある
ケースです。宛先の IP アドレスが、自分に接続されているネットワーク
インターフェースに割り当てられている、いずれの IP ネットワークアドレス
とも異なるという場合です。
</enum>


<sect><!--VII. Problems with Proxy ARP and what must be avoided-->
プロクシ ARP の問題点と避けなければいけないこと
<p>
<enum>

<item>
<!--
Do not have more than one system respond to the proxy ARP entry for
   a specific IP address. In the case of BSD, this will may mean that
   since proxy ARP for a range of addresses, ensure that that the
   address ranges do not conflict. For a network based upon BSD networking,
   this means that you should dedicate the entire network to one server.
-->
   特定の IP アドレスに対して応答する プロクシ ARP エントリーは
   ただ一つでなければなりません。BSD の場合、あるアドレス範囲に
   対して プロクシ ARP をおこなう場合にはそのアドレス範囲が衝突しない
   ことを保証する必要があります。
   これはつまり、BSD ベースのネットワークでは、あるネットワーク
   全体をひとつのサーバに割り当てる必要があることを意味します。
<p>
<!--
Again, BSD systems will bitterly complain if it receives more than one
reply for its ARP request.
-->
もう一度強調しておきますが、もし ARP 要求に対して複数の応答を
受け取った場合、BSD システムでは相当ひどいことになります。

<item>
<!--
2. Do not attempt to perform Proxy ARP for an address which is already
   present on the network.
-->
   すでにネットワーク中に存在しているアドレスに対して、プロクシ ARP を
   実行してはいけません。
<p>
<!--
This is a slight variation of the above problem. If you attempt to
perform proxy ARP for an IP address which is presently available on
the network, then two replies will be generated. This may mean that
you should not take IP addresses from one network and move them to a
remote connection which may cause the server to attempt to perform
Proxy ARP.
-->
これは、上で述べた問題のちょっとしたバリエーションです。ネットワーク
上にすでに存在するIP アドレスに対する プロクシ ARP を実行すると、
２つの応答が生成されることになります。
つまり、サーバーがリモートシステムとの接続にプロクシ ARP を
適用する場合に、現在ネットワークで使用中の IP アドレスを
リモート接続に流用したりしてはいけない、ということです。
<p>
(校正者注:本来の IP アドレスのマシンへのコネクションをサーバが横取り
して proxy ARP に使ってしまう、つまり本来のコネクションが成立しなく
なる、ということではないかと思います。)
</enum>


<sect><!--VII. What to do if you can't use Proxy ARP but want the same
functionality.-->
プロクシ ARP を使う事はできないが、同様の機能を実現したい場合には？
<p>
<!--
There are several choices available if you are unable to use proxy
ARP.
-->
あなたが プロクシ ARP を使えない場合にはいくつかの代替手段があります。

<!--
The easiest is to subnet the remote IP addresses so that all of the
remote addresses are on their own IP network. Then add a network route
on each of the routers (those devices which are indicated by the
'gateway' addresses of all of your hosts) so that the IP network is to
be sent to the server to which the remote IP addresses connect.
-->
もっとも簡単なのは、全てのリモートアドレスがそれぞれの IP ネットワーク
アドレスを所有できるように、リモート IP アドレスをサブネット化してしまう
という方法です。
そして、それぞれのルーター (すべてのホスト上で、ゲートウエイアドレスと
して表示されているすべてのデバイスです。) 上にネットワーク経路を
付け加えるのです。

<!--
Alternately, you could use gated on the server and the routers.
-->
これによって、それぞれのリモート IP アドレスが接続されているサーバに
対してその IP ネットワーク宛の（パケットが)送られるようにできます。

(校正者注: リモートマシンのアドレスをまとめてサブネットに押し込む -&gt; 
そのサブネットへの経路をゲートウェイ（サブネットへのゲートウェイマシンの、
元々のゲートウェイ）に書く。-&gt; サブネット化したネットワークへの接続要求が、
サブネットのゲートウェイにくるようになる。ということでしょうか。)

<!--
Alternately, you could put a host route if you don't wish to subnet
the IP network. You would put entries in each of the routers for all
of the remote IP addresses.
-->
この代わりに、ルーターと、サーバ上の gated を使うということも
できます。

<!--
You need to update only the gateways and routers. You do not need to
change all of the hosts in your network. The default routes which the
hosts use to send frames to routers will cause what is called a "ICMP
re-direct" frame to be sent to the host making the request. This will
automatically add a 'host' route to the appropriate server.
-->
IP ネットワークをサブネット化したくない場合には、すべてのホスト経路を指定
してしまう、という方法もあります。
つまり、全てのリモート IP アドレスそれぞれに対して、それぞれのルーター
エントリーを指定してしまうのです。

ゲートウエイとルーター上の情報をアップデートする必要はありますが、
ネットワーク上の全てのホストを変更する必要はありません。

それぞれのホストがルーターにパケットを送る時に使われるデフォールトルート
を通じて、「ICMP re-direct パケット」が、要求を発行したホストに送られ、
その結果、それぞれのサーバ上にホスト経路が自動的に追加されるからです。


<sect><!--VIII. Conclusion-->結論
<p>
<!--
I hope that I have explained a little more about the proxy ARP and
how it works. Fortunately, if you use pppd or dip-uri, you do not
need to know how the mechanical steps in using it. It is
automatically performed for you by these pieces of software.
-->
プロクシ ARP がどのように動作し、どのようなものか、を少しでも
説明できたことを願っています。

pppd や dip-uri を使う場合には、この機械のような手順を知っている必要は
（幸運なことに）ありません。これらのソフトウエアが自動的に実行して
くれるからです。

<!--
Proxy ARP is not for everyone. It is a workable solution in some
cases. Hopefully, you can determine for yourself whether this will
help you with your networking problems.
-->
プロクシ ARP は万能の解決ではありません。いくつかの場合にうまく
機能する解決方法にすぎません。

あなたのネットワークの問題にこの機能が役に立つかどうか、自分で判断で
きることを期待しています。

<!--
Additional information may be found in the book 'TCP/IP Illustrated,
volume 1' "The protocols" by W. Richard Stevens and published by
Addison Wessley.
-->
もっと情報が必要な方には、W. Richard Stevens 氏による
「TCP/IP Illustrated, volume 1」 "The protocols" (アジソンウエスレイ社刊)
などがいいかもしれません。

<!--
Thank you.
-->
読んでくれて、ありがとう！


<sect>日本語訳について
<p>
これは、Linux MINI-HOWTO の、Proxy-ARP の翻訳です。
意訳も多くありますが、ご容赦ください。
また、誤訳や、もっとわかりやすい訳案などありましたら、
ぜひ訳者までフィードバックをお願い致します。
<p>
<verb>
日本語訳 : 川島 浩 (kei@sm.sony.co.jp)
校正     : 堀江 誠一 さん  (shorie@ibm.net)
           鴨澤 眞夫 さん (k957134@sci.u-ryukyu.ac.jp)
           中野 武雄 さん (nakano@apm.seikei.ac.jp)
</verb>
</sect>
</article>
