本文書は RFC1918 を日本語に訳したものであり、原文と語彙あるいは解釈の
相違が生じる場合は原文を正しいものとする。訳者および日本語訳に関わった
全ての関係者は、本文書によって読者が被り得る如何なる損害の責任をも
負わない。
上田 健 ken@sphere.ad.jp
(株)NTT PC コミュニケーションズ
------------------------------------------------------------------------
Network Working Group Y. Rekhter
Request for Comments: 1918 Cisco Systems
Obsoletes: 1627, 1597 B. Moskowitz
BCP: 5 Chrysler Corp.
Category: Best Current Practice D. Karrenberg
RIPE NCC
G. J. de Groot
RIPE NCC
E. Lear
Silicon Graphics, Inc.
February 1996
プライベート網のアドレス割当
このメモの位置づけ
この文書はインターネットコミュニティのInternet Best Current Practiceを示し、
改善のための討議、提案を求めるものである。このメモの配布は自由である。
1. はじめに
本文書において、エンタープライズとは、独立してTCP/IPを用いてネットワークを
運用している組織、特にそのネットワーク内のアドレッシングの計画及びアドレス
の割当を行う組織を指す。
本文書はプライベート網においてのアドレス割当を示す。その、割当は、エンター
プライズ内の全てのホスト及び他のエンタープライズの公開されているホストとの
間の完全なネットワーク層の接続性を許容するものである。プライベート網アドレス
空間を用いるためのコストとはパブリックからプライベートへのホスト及びネット
ワークのリナンバリングの為の潜在的労力である。
2. 目的
インターネット以外を含む世界的なTCP/IP技術の繁栄と共に、接続されていない
エンタープライズが単なるエンタープライズ間通信のためにこの技術及び
アドレッシング能力を他のエンタープライズあるいはインターネットへの直接接続
することを全く意図せずに使用するようになってきている。
インターネットは誰の想像をも超える成長を遂げた。継続する急激な増加は新たな
難題をもたらし続ける。一つの懸念はコミュニティ内のアドレス空間の枯渇にある。
別の、さらに重要な問題は、ルーティングのオーバーヘッド(経路情報)がインター
ネットサービスプロバイダー(ISP)の処理容量を超えてしまうことにある。
コミュニティ内では、両方の問題を解く長期的な解を検討中である。一方、
アドレス割当の過程及びそのインターネットのルーティングシステムに対する影響を
再検討することが必要である。
ルーティングオーバーヘッドの増加を抑えるために、ISPはアドレスレジストリから
アドレスブロックを取得し、そのブロックの中から各々の顧客の要求に応じて
顧客に割当を行っている。この方法によって、多数の顧客に対しての経路は
統合され、他のプロバイダに対して一つの経路として見える[RFC 1518]、
[RFC 1519]。経路情報の統合を有効なものとするために、ISPはカスタマの
ネットワークに対してそのプロバイダのブロックを使用し、そのために、顧客の
コンピュータのアドレスをリナンバリングする事を勧めなければならない。
このような推奨は将来において必須事項となるかもしれない。
現在のインターネットの大きさ及びその拡大速度を考えると、一組織がインター
ネットレジストリからグローバルIPアドレスの割当を受けインターネットに接続
した場合に全インターネットへの接続性を得られると考えるのはもはや現実的では
ない。一方、組織がインターネットに接続し全インターネットへの接続性を得よう
とする場合、その組織はそのすべてのパブリックホスト(全インターネットに接続性
を持つホスト)の、IPアドレスを、元々その組織がグローバルIPアドレスを用いて
いたかどうかには関わらず、リナンバリングしなければならないだろう。
今まではTCP/IPを使用するすべてのホストにグローバルIPアドレスを割り当てるのが
典型的だった。IPv4のアドレス空間の寿命を延ばすために、アドレスレジストリは
今までになく(IP割当の)正当性を求め、すなわち組織にとって余分なアドレス空間
を得ることが難しくなっている[RFC1466]。
エンタープライズ内でIPを使用するホストは3つのカテゴリに分けられる:
カテゴリ1:他の組織のホストひいてはインターネットへのアクセスを必要としない
ホスト。このカテゴリ内のホストはそのエンタープライズ内で一意(unambiguous)な、
また他のエンタープライズとの間ではあいまいな(ambiguous)IPアドレスを用いても
よい。(訳注: 本文中では「一意」を「たった一つ」(unambiguous == unique)と
いう意味で用い、「あいまい」を「二つ以上存在するかも知れない」(ambiguous)と
いう意味で用いる。)
カテゴリ2:中間にゲートウェイ(例: アプリケーション層ゲートウェイ)を置くこと
によって処理することができる、限られた外界のサービス(例: E-mail、FTP、
ネットニュース、リモートログイン)にアクセスを必要とするホスト。この
カテゴリに属する多くのホストにとって(IPの接続性によって提供される)制約の
ない対外アクセスは必要でなく、むしろプライバシーあるいはセキュリティの問題
から望まれないものである。ちょうどカテゴリ1のホストのようにこれらのホストは
そのエンタープライズの中で一意であれば他のエンタープライズとの間では
あいまいなIPアドレスを使用することができる。
カテゴリ3:エンタープライズの外に(IPの接続性を介して)ネットワーク層の
アクセスが必要なホスト。最後のカテゴリに属するホストはグローバルなIP
アドレスが必要である。
我々は一つ目と二つ目のカテゴリに属するホストを"プライベート"とよぶ。
我々は三つ目のカテゴリに属するホストを"パブリック"とよぶ。
多くのアプリケーションは、一つのエンタープライズ内のみでの接続性が必要
であり、多数の内部ホストにとって外部への(エンタープライズ外への)接続性は
必要ない。大きいエンタープライズ内で極めて多くのTCP/IPを用いているホストが
組織外のネットワーク層の接続性を必要としていないのを見つけることはしばしば
ある。
外部への接続性が必要でないことがあるいくつかの例としては以下のような
ものがある:
・一つ一つがTCP/IPでアドレス可能な、到着、出発のディスプレーを持つ
大きな空港。そのディスプレーが他のネットワークからアクセス可能でなければ
ならないことは極めて希であろう。
・銀行や、小売りチェーンのような大きな組織はその内部通信のためにTCP/IPを
用いるようになってきている。キャッシュレジスタや現金支払機および決算機器
のような多数のローカル端末がそのような接続性を必要とすることはほとんどない。
・セキュリティの理由から多くのエンタープライズは内部ネットワークとインター
ネットを接続するのにアプリケーション層のゲートウェイを利用する。内部ネット
ワークは通常インターネットと直接続を持たず、一つかそれ以上のゲートウェイが
インターネットから見えるだけである。この場合、内部ネットワークは一意でない
IPネットワーク番号を用いることができる。
・内部ネットワークのルータインターフェースは通常エンタープライズの外から
直接アクセス可能である必要はない。
3. プライベートアドレス空間
Internet Assigned Numbers Authority (IANA)は次の三つのIPアドレス空間
ブロックをプライベートインターネットのために予約している。
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
我々は最初のブロックを"24ビットブロック"、二つ目を"20ビットブロック"、
三つ目を"16ビットブロック"とよぶ。(CIDR以前の記述では)最初のブロックが
一つのクラスAネットワーク番号、二つ目のブロックが連続した16のクラスBネット
ワーク番号、三つ目が256の連続したクラスCネットワーク番号以外の何者でもない
ことに注目されたい。
この文書で定義されているアドレス空間の中からIPアドレスを使うエンター
プライズはIANAおよびインターネットレジストリといかなる調整もなしに使用する
ことができる。このように、そのアドレス空間は多くのエンタープライズにて
使用することができる。このプライベートアドレス空間のアドレスはその
エンタープライズ内で、あるいはこの空間を用いて複数のエンタープライズが
それらのプライベートインターネットにおいて通信できるようにしたときにのみ
一意になる。
先に述べたように、グローバルに一意なアドレス空間が必要なエンタープライズは
インターネットレジストリよりそのようなアドレスの割当を受けなければならない。
対外的な接続性のためにIPアドレスが必要なエンタープライズに上記のブロックから
アドレスが割り当てられることは決してない。
プライベートアドレス空間を使うために、エンタープライズはどのホストが
エンタープライズの外とのネットワーク層での接続性が予測可能な将来において
必要がなく、プライベートとできるか判断する必要がある。このようなホストは
上に示したようなプライベートアドレス空間を使用する。プライベートホストは
エンタープライズ内の他のすべてのホストとパブリック/プライベートを問わず通信
できる。しかし、それらはエンタープライズ外のいかなるホストともIPの接続性を
持つことはできない。外的な(エンタープライズ外の)IPの接続性は持っていない
一方、プライベートホストは仲介のゲートウェイ(例: アプリケーション層
ゲートウェイ)を介して外的サービスにアクセスできる。
すべての他のホストはパブリックとなりインターネットレジストリから割り当て
られる一意なアドレス空間を使う。パブリックホストはエンタープライズ内の
パブリックおよびプライベートの両方のホストと通信でき、エンタープライズ外の
パブリックホストとIP接続性を持つことができる。パブリックホストは他の
エンタープライズのプライベートホストには接続性を持たない。
ホストをプライベートからパブリックにあるいはその逆に移行すると、IPアドレス
の変更、DNSエントリーの適切な変更、そしてそのホストをIPアドレスにて参照する
他のホストの設定ファイルを変更しなくてはならない。
プライベートアドレスはグローバルな意味を持たないのでプライベートネット
ワークの経路情報はエンタープライズエンタープライズ間のリンクを通過すべきで
なく、ソースまたはデスティネーションアドレスとしてプライベートアドレスを
持っているパケットはそのようなリンク間を転送されるべきでない。プライベート
アドレス空間を使用しないルータ、特にインターネットサービスプロバイダのものは
プライベートネットワークの経路情報を拒絶(フィルターアウト)するよう設定される
べきである。もしそのようなルータがそのような情報を受け取ったら、拒絶は
ルーティングプロトコルエラーとして扱われるべきでない。
そのようなアドレスへの間接的な参照はエンタープライズ内で行われるべきである。
突出したそのような参照の例はDNSのResource Recordであり、他の内的な
プライベートアドレスを参照する他の情報である。特に、インターネットサービス
プロバイダはそのような漏れを防ぐように極力努力すべきである。
4. プライベートアドレス空間を使うことのメリット及びデメリット
プライベートアドレス空間を使うことのインターネット全体に対しての明らかな
メリットは、グローバルにユニークなアドレス空間を必要ないところには用いない
ことによってそれを保護することである。
エンタープライズ自身にもまたプライベートアドレス空間を用いることによって
数々のメリットがある: エンタープライズはグローバルに一意なプールから得ら
れるより多くのアドレスを自由にできることによりネットワークデザインに多くの
柔軟性を持つことができる。それによってより簡単な拡張計画と共に運用管理に
便利なアドレス手法を用いることができる。
様々な理由によりインターネットはインターネットに接続されていないエンター
プライズがIANAからIPアドレス空間の割当を受けることなしにその空間をホストに
使用してしまったケースにすでに遭遇した。いくつかの場合、このアドレス空間は
すでに他のエンタープライズに割り当てられてしまっていた。曖昧なアドレスが
あるとIPルーティングは正確な運用ができないので、もしそのようなエンター
プライズが後にインターネットに接続するとそれは潜在的に非常に重大な問題を
引き起こしかねない。本来ISPは経路のフィルタを用いてこのようなミスを防ぐ
べきだが、実際には常にそうであるとは限らない。プライベート空間を用いる
ことは対外への接続性が必要になったときに衝突を防ぎ、エンタープライズに
とって安全な選択である。
プライベートアドレスを用いることの大きなデメリットはインターネットへの
エンタープライズからのアクセスの柔軟性を実際に制限してしまうかもしれない
ところにある。一度誰かがプライベートアドレスへの使用を決定したら、それは
もしそのエンタープライズの一部(あるいは全部)とインターネットとのIP
コネクティビティを持たせようとすると、そのエンタープライズはその部分的
あるいは全体的なリナンバリングをしなければならないことを意味する。普通、
リナンバリングのコストはプライベートからパブリックへの変更が必要なホストの
数を数えることによって計ることが出来る。しかしながら、以前話したように
ネットワークがグローバルに一意なアドレスを使用していても、インターネット
ワイドなIP接続性を得るにはリナンバリングしなくてはならないかもしれない。
もう一つのプライベートアドレス空間を用いることのデメリットは、複数の
プライベートアドレスを一つのプライベートインターネットに合併するときに
リナンバリングをしなければならないかもしれないと言うところにある。もし
がセクション2に於いてリストした例を復習すると、企業は合併する傾向にあること
が分かる。もしそのような合併前に別々にプライベートアドレス空間を用いており、
合併後にプライベートインターネットが一つに結合されたら、結合されたインター
ネットのいくつかのアドレスは一意でなくなってしまうかもしれない。結果として
それらのアドレスを持つホストはリナンバリングされなければならないだろう。
リナンバリングのコストはリナンバリングを容易にするツールの開発およびその
利用によって軽減されるだろう(例 Dynamic Host Configuration Protocol (DHCP))。
われわれはプライベートアドレスを使用するかどうか決定するときに、
コンピュータ及びソフトウェアベンダに対してそのようなツールがあるかどうか
聞くことを勧める。別のIETFの取り組み(PIER Working Group)ではリナンバリング
に関する全ての要求及び手順の文書を準備している。
5. 運用上の留意点
一つの可能な戦略は、まず、プライベートな部分のネットワークを構築し、
プライベートアドレス空間を全ての内部リンクに対して用いることである。そして、
必要な場所にパブリックネットワークを計画し、対外接続を確立する。
この形態は永久的に固定される必要はない。もし、一つあるいはそれ以上からなる
グループのホストが後にその位置づけを(プライベートからパブリックに、あるいは
その逆に)変えなければならないときは、関係するホストのみをリナンバリングし、
必要ならば物理的接続を変更するだけで達成できる。でそのような変更が予測
できるところ(マシンルームなど)では変更を容易にできるためにパブリック及び
プライベートサブネットを別な物理メディアで設定することが望ましい。ネット
ワークの大きな混乱を避けるために、にかよった接続性を求められるホストを
サブネット化することが望まれる。
もし、適切なサブネット化が設計され、接続される機器でサポートされるならば
24ビットブロック(クラスAネットワーク)のプライベートアドレス空間を用い拡張性
の高いアドレッシングプランを立てることが望ましい。もし、サブネット化が問題
となるならば16ビットブロック(クラスCネットワーク)あるいは20ビットブロック
(クラスBネットワーク)のプライベートアドレス空間を用いることが出来る。
もしかして、パブリック及びプライベートのアドレスを同一の物理ネットワークに
持ちたいと考えるかもしれない。これは可能ではあるが、そのような設計には
落とし穴がある(落とし穴はプライベートアドレスの使用とは全く関係なく、
共通のデータリンク層ネットワーク上に複数のIPサブネットが存在することにある
ことに留意されたい)。我々はその問題に進むときに注意を促すことにする。
エンタープライズと対外のネットワークを接続するルータは、パケット及び
ルーティング情報の漏れを防ぐためにリンクの両端で適切なパケット及び
ルーティングフィルタを設定することが強く望まれる。また、エンタープライズは
自己のネットワークをあいまいなルーティングから守る為に、外部からの
プライベートアドレス空間へのルーティング情報の流入を内部ネットワークに対して
フィルタすべきである。
各々のプライベートアドレス空間を持った二つのサイトがパブリックネットワーク
を経由して通信することがあり得る。そうするためには、何らかの encapsulation
が各のパブリックネットワークへ対しての境界で行われ、プライベートアドレスが
プライベートとして保たれなければならない。
もし、二つ(あるいはそれ以上)の組織がこの文書に示されたアドレスの割当を行い、
後にお互いの間にIPの接続性を持たせようとすると、アドレスの一意性が
おかされる危険性がある。そのリスクを軽減するために、プライベートアドレスを
使用する組織は内部にサブブロックを割り当てるときに確保されているプライベート
アドレスプールからランダムに選ぶことが強く推奨される。
もしエンタープライズがプライベートアドレス、もしくはプライベートアドレスと
パブリックアドレスの両方を使用するなら、エンタープライズの外部のDNSクライ
アントは、アドレスが曖昧になるためにエンタープライズのプライベートアドレス
空間にあるアドレスを参照すべきでない。これを保証する一つの方法としては、
それぞれパブリック及びプライベートアドレスを持ったDNSゾーンに対して、
二つの authority サーバを走らせることがある。一つのサーバはパブリック
アドレス空間から見えて、パブリックアドレスにて到達可能なエンタープライズの
アドレスのみを持つ。もう一つのサーバはプライベートネットワークからのみ到達
可能で、プライベートアドレス及びプライベートネットワークから到達可能な
パブリックアドレスを含む。一貫性を保つために、両方のサーバは同じデータ
から公開された部分のみフィルターされたものにて設定されるべきである。
このような能力を提供するために、一定の複雑さが介する。(訳注: 前者のサーバは
パブリックホストのデータのみを持ち、後者のサーバはパブリック、プライベートを
含んだ全てのホストのデータを持つ。即ち前者のデータは後者のデータのサブセット
である。)
6. セキュリティについて
セキュリティ問題についてはこのメモでは言及されない。
7. 最後に
説明された手法を用いることによって、多くの大きなエンタープライズは比較的
小さなグローバルに一意なアドレス空間のみを必要とするようになる。インター
ネット全体としてはグローバルに一意なアドレス空間の保護によってIPアドレス
空間の寿命を効果的に延ばすことになる。エンタープライズは比較的大きなプライ
ベートアドレス空間によって提供される柔軟性によって恩恵を受ける。しかし
ながら、接続性の要求が時とともに変化することによって一部あるいは全ての
エンタープライズネットワークのリナンバリングを組織は行わなくてはならない。
8. 謝辞
我々は以下の方々のコメントに感謝する。
Tony Bates (MCI), Jordan Becker (ANS), Hans-Werner Braun (SDSC),
Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller
(BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC),
Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi
(RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton
(connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik
Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom
Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford
(FNAL), Michael Patton (BBN), and Paul Vixie (Internet Software
Consortium)
9. 参考文献
[RFC1466] Gerich, E., "Guidelines for Management of IP Address
Space", RFC 1466, Merit Network, Inc., May 1993.
[RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
10. 著者の住所
Yakov Rekhter
Cisco systems
170 West Tasman Drive
San Jose, CA, USA
Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.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: rgm3@is.chrysler.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
Eliot Lear
Mail Stop 15-730
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA 94043-1389
Phone: +1 415 960 1980
Fax: +1 415 961 9584
EMail: lear@sgi.com
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
