（本翻訳は、参考のために供されるもので、正確には英文の RFC1597 を参照し
  ていただきたい）
Network Working Group                                        Y. Rekhter
Request for Comments: 1597       T.J. Watson Research Center, IBM Corp.
分類：情報伝達						   B. Moskowitz
                                                         Chrysler Corp.
                                                          D. Karrenberg
                                                               RIPE NCC
                                                            G. de Groot
                                                               RIPE NCC
                                      翻訳：加藤  朗・川副  博・吉村 伸
							   WIDE Project
							   1994 年 3 月

		閉じたインターネットの為のアドレス割り振り

このメモの状態

   このメモはインターネットコミュニティへの情報伝達を目的としたもので
   あり、いかなる標準を定義したものではない。このメモは自由に配布可能
   である。

１．はじめに

   この RFC では、世界的にユニークなアドレスを割り当てることなしに、組
   織内部のホスト同士は完全な接続性が確保され、また異なった組織のパブ
   リックホスト間の通信も可能な方法を述べる。この方法を利用することにより、
   IP アドレス空間を大変節約することができるのではないかと期待する。

   このメモでは、エンタープライズとは TCP/IP を用いて自立的に運用され、
   特にその内部でのアドレス計画とアドレス割り当てを決定しているネット
   ワークを意味する。

２．背景

   世界的な TCP/IP の普及により、インターネットではない部分も含めて、
   接続されていないエンタープライズがこの技術を採用し、他のエンタープ
   ライズやインターネットに直接接続する予定がなくても、エンタープライズ
   内の通信のためだけにアドレスを用いるケースは非常に多くなってきている。

   現在は、TCP/IP を使用する総てのホストに世界的に独立なアドレスを割り
   振っている。このため、有限な IP アドレス空間が使い尽くされてしまう
   という問題が次第に深刻になってきている。それゆえ、近年は IP アドレス
   の割り当て基準が厳しくなってきている。この規則は各エンタープライズが
   ネットワークを実装し運営しなければならないときには、しばしば十分なア
   ドレス空間の割り当てを受けることが難しいという問題になる。

   IP を用いたエンタープライズ内部のホストは、次の３つのカテゴリに分類
   できる：

      - 他のエンタープライズやインターネットにアクセスする必要のない
	ホスト。

      - 外部の限られたサービス（電子メール、ファイル転送、ネットワーク
	ニュース、遠隔ログイン）を必要とするホスト。これらはアプリケー
	ション層ゲートウェイで扱うことができる。

      - IP により、外部とネットワーク層での通信が必要なホスト。

      - 最初のグループのホストは、エンタープライズ内部では重なりがなく、
        ただしエンタープライズ間では重複しているかもしれない IP アドレ
	スを用いることもできる。

   ２番目のカテゴリのホストでは、IP による無制限のアクセスはおそらく必要
   ではなく、セキュリティ上やプライバシ上の理由で、好ましくないことすら
   ある。最初のカテゴリと同様に、このようなホストはエンタープライズ内部
   ではユニークであるが、エンタープライズ間では重複のないアドレスを使用
   することができる。

   最後のカテゴリのホストだけが、世界的に重複のない IP アドレスが必要で
   ある。

   多くのアプリケーションは、エンタープライズ内部のみの接続性があれば
   よく、大部分の内部ホストにとっては外部への接続性は不要である。大きな
   エンタープライズでは、TCP/IP を使用するホストの数の内、他のエンター
   プライズに対してネットワーク層での接続性を必要としないものの数は、
   非常に大きいものであることはほとんど自明である。

   外部との接続性が必要ではないケースとして次のような例がある：

      - 大空港の出発便や到着便のディスプレーがそれぞれ TCP/IP で通信し
	いる場合。これらのディスプレー装置が直接外部へ接続する必要があ
	るとは思えない。

      - 銀行や小売り店チェーンなどの大きな組織では、内部の通信に TCP/IP
	を用いる傾向にある。非常に沢山のキャッシュレジスタや自動支払い機
	や事務用の機器も外部への接続性が必要になることは希である。

      - セキュリティ上の理由により、多くのエンタープライズではアプリケー
	ション層のゲートウェイ（ファイアウォール）を介してインターネット
	に接続している。内側のネットワークは通常外部への直接の接続性を持
	たず、ファイアウォールのごく少数のホストだけがインターネットから
	見えている。この場合、内側のネットワークでは、独立ではない IP ア
	ドレスを使うことができる。

      - ２つのエンタープライズがプライベートなリンクを経由して通信する
	場合、ごく少数のホストだけが相互に到達可能になっている。これら
	のホストだけが世界的に独立したアドレスを必要とする。

      - 内側のネットワークのルータのインターフェースはエンタープライズ
	の外側からアクセスできる必要は通常ないだろう。

３．閉じたアドレス空間

   インターネット番号割り当て機構(IANA) は次のブロックを個別ネットワークの
   為に予約した：

	10.0.0.0	- 10.255.255.255
	172.16.0.0	- 172.31.255.255
	192.168.0.0	- 192.168.255.255

   最初のブロックを 24bit ブロック、２番目のものを 20bit ブロック、最後の
   ものを 16bit ブロックと呼ぶ。最初のものは従来のクラスＡアドレスそのもの
   であり、２番目のものは連続した１６個のクラスＢアドレス、３番目のものは
   255 個の連続したクラスＣアドレスである。

   この文書で示されたアドレス空間を利用しようとする場合には、IANA や
   インターネット登録機関などの調整なしに使用することができる。従ってア
   ドレスは多くのエンタープライズによって使用され、アドレスはエンター
   プライズ内部のみでユニークとなる。

   以前と同様に、世界的にユニークなアドレス空間が必要な組織は、インター
   ネット登録機関からアドレスを得ることができる。外部に接続する必要がある
   ために IP アドレスを要求する場合には、上のアドレス空間から割り当てを
   受けることはない。

   プライベートアドレス空間を使う為には、各組織は近い将来まで考えた場合、
   どの部分が外部との接続性が不要であるかどうかを決定しなければならない。
   このようなホストはプライベートホストと呼ばれ、上に示したプライベート
   アドレス空間を使用する。プライベートホストはエンタープライズ内部の総
   てホスト（プライベートであるかパブリックであるかを問わず）と通信する
   ことができるが、外部のホストとの IP での接続性はない。直接のネットワー
   ク層での接続性はなくても、アプリケーション層でのリレー機構を利用する
   ことにより、外部のサービスにアクセスすることは可能である。

   プライベートホストではないホストは特にパブリックホストと呼ばれ、
   インターネット登録機構から割り当てられた世界的に独立なアドレスを
   使用する。パブリックホストはエンタープライズ内部の、パブリック、
   プライベートを問わず、いかなるホストとも通信をすることができる。
   ただし、他のエンタープライズのプライベートホストとの接続性はない。

   ホストがパブリックになったり、プライベートになった場合には、アドレス
   の変更を伴う。

   プライベートアドレスは世界的な意味合いは持たないので、プライベート
   ネットワークに関する経路情報をエンタープライズ間リンクを越えてアナ
   ウンスするべきではないし、これらのアドレスを持つパケットをエンター
   プライズ間リンク上を転送するべきでもない。プライベートアドレス空間
   を使用しないルータ、特にプロバイダでは、プライベートネットワークに
   関する経路情報を排除するように設定されることが好ましい。もしルータ
   がこのようなアドレスを受け取ったとしても、プロトコルエラーとして処
   理してはいけない。

   プライベートアドレス空間に対する間接的な参照もエンタープライズ内部に
   留めること。これの典型的な例はプライベートアドレス空間に関する DNS
   のリソースレコードやその他の情報である。特に、プロバイダはこのような
   流出を防止するように努力すること。

４．プライベートアドレス空間を利用する場合の得失

   インターネット全体としてプライベートアドレス空間を利用する利点は、
   世界的な独立性が必要でない場合にプライベートアドレス空間を用いるこ
   とによりアドレス空間の浪費を避けることができることである。

   各エンタープライズにとってもプライベートアドレス空間を利用することは
   多くの利点がある：世界的に独立なアドレス空間からアドレスを得るより、
　 自由になるアドレス空間がたくさんできるので、ネットワーク構築の自由度
   が高まる。このことは、アドレス利用の成長を緩やかにするとともに、
   運用や管理の面から便利なアドレス割り当て方法を用いることができる。

   様々な理由によってインターネットは、インターネットに接続されていない
   エンタープライズが IANA から割り当てられていないアドレス空間を使用し
   ている場合がある。このうちの一部はすでに他のエンタープライズに割り当
   てが行われている。このようなエンタープライズが後日インターネットへの
   接続を行う場合、深刻な問題が発生する。つまり曖昧なアドレスが使われて
   いる場合には IP の経路制御が正しく機能しない。プライベートアドレス空
   間を用いることによって、外部への接続が必要になった場合にも衝突を避け
   ることができる利点がある。

   アドレス変更が必要な可能性があるという点は、このようなプライベート
   インターネット用のアドレス空間を使うことの重大な欠点であると考える
   人がいるかもしれない。しかし、多くのホストが第３のカテゴリに移行する
   ことはないだろうし、あるエンタープライズは他のエンタープライズと全面
   的に相互接続するようになることは少ないだろうから、アドレス変更は単に
   可能性があるというというだけにすぎない。

   仮にアドレスの付けなおしが必要だった場合でも、クラスのないドメイン間
   経路制御方式（CIDR）の元では接続しているサービスプロバイダを変更した
   場合にはアドレスの振りなおしが奨励されていることにも考える必要がある。
   従って、組織がプライベートアドレス空間を使用するしないに関らず、アド
   レス振りなおしは将来より頻繁に行われるようになる。DHCP のような技術に
   よってアドレス振りなおしは大した手間ではなくなるだろう。

   また、パブリックホストとプライベートホストを明確に区別すれば、その結果と
   してのアドレス振りなおしが起きても、それは意図しない外界からの接続要求を
   防ぎやすくなる。そのため、アドレス振りなおしの必要性は利点と見ることもで
   きる。

５．運用上の議論

   推奨される設計方針は、まずプライベートな部分を先に設計し、内側のリン
   クにはプライベートアドレスを使用する。その後にパブリックなサブネット
   を計画し、外部への接続性を設計することである。

   このデザインは永久に固定されるものではない。もし沢山のホストがあとで
   状態の変更を必要とする場合には、関係するホストだけアドレス付け替えを
   行い、または必要に応じて別な物理的サブネットを設置すればよい。

   もし適切なサブネット化が計画され、関連機器でサポートされているならば、
   24bit ブロックを使用して成長に応じたアドレス計画を行えばよい。また、
   もしサブネット化が問題ならば、16bit クラスＣブロック、つまり、連続
   している 255 個のサブネット番号を使用することもできる。

   単一物理ネットワークに複数の異なったサブネットを用いることは沢山の
   問題が生じる。運用上の諸問題が十分に研究され、総ての機器がサポートす
   るまではこのような運用は避けることが望ましい。

   ある単一ホストがプライベートとパブリックの間で変更がある場合には、
   アドレスの変更と、そして多くの場合物理的な接続性の変更が必要になる
   だろう。そのような変更が予期される場合（マシンルームなど）には、パブ
   リックとプライベートそれぞれにメディアを分割し、変更が容易に計画して
   おいた方がよい。

   あるサブネットのホスト全体を変更する場合には、全体のネットワークを止め
   ることなしに容易に行うことができる。そのため、将来の変更が必要になる
   かもしれないホストのグループは、独立したサブネットにしておいた方がいい
   かも知れない。

   エンタープライズと外部を接続するルータには、リンクの両端でパケットや
   経路情報の漏洩が発生しないようにパケットフィルタや経路フィルタを設定
   することが強く要請されている。さらに、エンタープライズ内部に取り込む
   経路情報も適切にフィルタリングし、プライベートアドレス空間に対する経
   路がエンタープライズ外部に向いてしまわないようにすることも重要である。

   企業グループ間など相互の通信に対する要求が高い場合には、共通のアドレ
   ス計画を作成し、必要なアレンジが可能なようにしておき、単一のエンター
   プライズを構成できるようにすることを考えることができる。

   もし同一エンタープライズの各部が(例えば二つの支店)が外部のサービスプロ
   バイダを経由して接続されるような場合には、IP トンネリングを用いてプラ
   イベートネットワーク間のパケットの漏れを防ぐこともできる。

   DNS のリソースレコードにおけるアドレスの漏洩を防ぐ方法として、２つの
   ネームサーバ、一つは外部向きネームサーバで世界的に独立なアドレスに
   関して機能し、もう一つは内向けにパブリックとプライベート両方のアドレ
   スに関して動作するネームサーバを運用する方法がある。
   ２つのネームサーバの一貫性を確保する為、外向きのネームサーバは共通デー
   タをフィルタリングしたものを使用する。

   パブリックホストもプライベートホストも内側のホスト上ののリゾルバは、
   内向きのネームサーバだけをアクセスする。外向きのネームサーバは外部か
　 らの問い合わせのみに用いられ、世界的な DNS に組み込まれる。内向きの
   サーバは、エンタープライズ外に対する問い合わせは総て外向きネームサー
   バに転送する。このことによって、内側のホストは世界的な DNS をアクセ
   スすることができる。この方法によって、プライベートホストに関する情報
   は、エンタープライズ外部のリゾルバやネームサーバに届くことはない。

６．参考文献

   [1] Gerich, E., "Guidelines for Management of IP Address Space", RFC
       1466, Merit Network, Inc., May 1993.

７．セキュリティに関する考慮

   プライベートアドレス空間の利用はセキュリティを向上することができるが
   セキュリティの個々の機能を置き換えるものではない。

８．まとめ

   ここに示された方法によって、多くの大きなエンタープライズは世界的にユニ
   ークなアドレス空間からは比較的小さなブロックの割り当てをが必要になるだ
   けである。インターネット全体としても、世界的に独立なアドレス空間の利用
   を抑えることができることによって、アドレス空間の寿命を効率的に延長する
   ことができる。各エンタープライズも比較的大きなアドレス空間を使えること
   により、自由度が高くなるというメリットが生まれる。

９．謝辞

   この文書を作成するにあたり、有用なコメントを頂いた Tony Bates (RIPE
   NCC), Jordan Becker (ANS), Hans-werner Braun (SDSC), Ross Callon
   (Wellfleet), John Curran (NEARNET), Vince Fuller (Barrnet), Tony
   Li (cisco Systems), Anne Lord (RIPE NCC), Mile Medin (NSI), Marten
   Terpstra (RIPE NCC), Geza Turchanri (RIPE NCC) に感謝します。

１０．著者のアドレス

   Yakov Rekhter
   T.J. Watson Research Center, IBM Corp.
   P.O. Box 218
   Yorktown Heights, NY, 10598

   Phone: +1 914 945 3896
   Fax: +1 914 945 2141
   EMail: yakov@watson.ibm.com


   Robert G Moskowitz
   Chrysler Corporation
   CIMS: 424-73-00
   25999 Lawrence Ave
   Center Line, MI 48015

   Phone: +1 810 758 8212
   Fax: +1 810 758 8173
   EMail: 3858921@mcimail.com


   Daniel Karrenberg
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands

   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: Daniel.Karrenberg@ripe.net


   Geert Jan de Groot
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands

   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: GeertJan.deGroot@ripe.net