Network Working Group B. Carpenter Request for Comments: 2101 J. Crowcroft Category: Informational Y. Rekhter IAB February 1997 IPv4 Address Behaviour Today 今日のIPv4アドレスの動作 このメモの状況 このメモは、インターネット共同体に対して情報を提供する。このメモは、何 らインターネット標準を規定しない。このメモの配布には、制限はない。 要約 このノートの主な目的は、32ビットIPバージョン4のアドレス空間につい て、現時点での解釈を明白にすることである。その意味は、当初定義された時 から大きく変化している。IPv6アドレスに関する短い章で、IPv4との 類似および差違について主要点を指摘する。 内容一覧 1. 概要 2. 用語 3. 理想的な特性 4. IPv4アドレスの現状についての概観 4.1 アドレスは世界的に一意な配置子とは限らない 4.2 アドレスはすべてが時間的に一意とは限らない 4.3 マルチキャストとエニイキャスト 4.4 まとめ 5. IPv6の考察 付録:IPv4アドレス割当てとルーティングに関する現在の実例 安全性の考慮 謝辞 参考文献 著者アドレス 1.概要 このノートの主な目的は、32ビットIPバージョン4のアドレス空間につい て、現時点での解釈を明白にすることである。その意味は、1981年に最初 に定義された時から大きく変化している[RFC791]。 解釈を明白にすることで、プロトコル設計者、製品の実装者、インターネット サービスプロバイダおよび利用者サイトを、援助することを意図している。イ ンターネットの指数的な成長の結果として、ここ数年の間に起こった急激な変 化から起因するIPアドレスについての誤解をさけることを、目指している。 IPv6アドレスに関する短い章で、IPv4との類似および差違について主 要な点を指摘する。 2. 用語 コンピュータネットワークでは、ディレクトリ、名前、ネットワークアドレス およびルータの概念は異なるものであり、個別に分析されるものと理解されて いる[RFC1498]。ただし、”ネットワークアドレス”(以降、”アド レス”と、省略する)の概念を、少なくとの2つの意味、”識別子”と”配置 子”にさらに分ける必要がある。これは、RFC791が書かれた時点では、 十分に理解されてはいなかっただろう。 本ドキュメントでは、”ホスト”という用語を、IPv4パケットを発生し、 また取込むシステムに適用し、”ルータ”という用語をホストまたは他のルー タへIPv4パケットを転送するシステムに適用する。 本ドキュメントの目的のため、2つのホスト間で通信セションが存在している 間使用されるビット文字列を、”識別子”といい、これにより関連のある間、 ホストの一方を識別できる。通信の他方の端点が確かに存在しているものとし て、入ってくるパケットの出所を識別するため、識別子が使用される。例えば、 TCPの pseudo-header[RFC793]やIPの Security association [ RFC1825]である。伝統的に、すべてのパケットに含まれるIPv4ソ ースアドレスは、この目的で使用されている。 ”識別子”について、別の定義もよく使われることに注意のこと:このドキュ メントは、終端点の識別子の意味の一般的な問題を議論するものではない。 本ドキュメントの目的のため、特定のパケットが配送される場所を識別するた め使用されるビット文字列を”配置子”という。すなわち、目的のホストが接 続されているインターネットトポロジ上の場所を、提示する。伝統的に、すべ てのパケットに含まれるデスティネーションIPv4アドレスは、この目的で 使用される。IPルーティングプロトコルは、IPv4アドレスを配置子とし て解釈し、個々のホストの配置子に向かうルートの識別を、どのルータ(自身 の配置子を持つ)に要請するかということに基いて、ルーティングテーブルを 構築する。 識別子も配置子も一意であることが要求されるが、その要求の内容は異なる。 識別子は、相互に通信するホスト群の単位で、一意でなければならない。配置 子は、相互に通信するルータ群の単位で(これをルーティング”範囲”と呼ぶ こととする)、一意でなければならない。配置子はルーティング範囲において、 一意でなければならないが、この一意性は(ルーティング可能性でなく)、複 数の範囲に対して拡張できる。そのため以後、一意となる配置子を持つ範囲と 一意でない(重なりのある)配置子を持つ範囲とを、区別する。 識別子と配置子はいずれも生存時間の要求を持つが、この要求の内容は異なる。 識別子は、少なくとも二つのホスト間の通信の最大生存時間の間、有効でなけ ればならない。配置子は、ルーティングメカニズムに要求される期間、有効で なければならない(この期間は、通信の生存時間より、短い場合もあれば長い 場合もある)。 識別子と配置子の両方に対し、同様なアドレス空間とIPヘッダ内の同様なフ ィールド(ソースおよびデスティネーションアドレス)が、RFC791とR FC793により適用されたことは、歴史的な偶然の事実であることに、注意 すべきかもしれない。そして、伝統的にインターネットでは、ホストの識別子 はその配置子と等価であり、空間的にも一意であり(あいまいなく)、また時 間的にも一意である(定数)とされた。 一意性の条件は、ルーティング(IPv4配置子で有効となるインフラストラ クチャ)とトランスポートプロトコル(IPの接続性に依存する)を設計する 際の仮定に、大きく影響した。アドレスの空間的な一意性は、インターフェー スの識別子およびホストの識別子のいずれとしても利用でき、またルーティン グテーブルのキーとしても利用できるという意味を持っていた。アドレスの時 間的な一意性は、TCPの実装において、IPアドレス以外に他端の識別のた めに状態を管理する必要がないことを、意味していた。こうしてIPアドレス は、端点間のIPの安全性、および上位層セションとの結合の両方のために、 利用された。 一般的に言えば、IPv4アドレスを配置子として使用することは、識別子と して使うことよりも、重要である。そして、両方を兼ねて使用する場合に矛盾 があれば、配置子としての使用が優先される。すなわち、パケットを配送する のに便利なように検討されたため、配送不能なパケットの身元を確認するより も、終端点を識別することに強く関心を持っている。言葉を変えれば、ルーテ ィングプロトコルに対して強力な作業であったが、アドレス利用のその他の面 については具体的な作業はあまりないものといえる。 3. 理想的な特性 上に記述した制限はあるが、識別子と配置子の理想的な特性を考えるのは難し くない。識別子は、誕生時に割当てられ、変更されることなく、また再利用さ れることもない。配置子は、ネットワークトポロジ内のホストの位置を記述し、 トポロジが変化すれば、配置子も変更される。 残念ながら、この理想のいずれもIPv4アドレスには適合していない。この ドキュメントの続くの部分で、現在の実状のスナップショットを捉える。 4. IPv4アドレスの現状についての概観 IPv4アドレスはもはや世界的に一意ではなく、また無限の生存時間を持つも のでもないということが、事実である。 4.1 アドレスは世界的に一意な配置子とは限らない 企業間ネットワーク、別称イントラネットでは、必要に応じて複数のルーティ ング範囲を構成しながら、いかにIPv4アドレス空間のサブセットを適正に 再利用するかを、[RFC1918]では示した。二つ(もしくはそれ以上) のルーティング範囲の境界において、その間での通信を可能とする装置の残像 (spectrum)を見つけるかもしれない。 残像の一端は、純粋なアプリケーション層ゲートウエイ(ALG)である。こ の装置は、アプリケーション層のデータストリームに対する終端点として動作 し、利用者から可視のものである。例えば、ルーティング範囲Aにいる利用者 Uaがルーティング範囲Bにいる利用者Ubと通信する場合、Uaは最初に、 AとBを相互接続するALGとの間に、通信路を明示的に設定し、この通信路 を経由してUaとUbとの通信は行われる。こういったゲートウエイを、”非 透過な”ALGと称する。 別のALGの形態では、ALGを介して利用者間に透過に通信路を形成する。 上の例を用いれば、”透過な”ALGでは、Ubと通信を開始する前に、Ua はALGとの間に明示的な通信路を設定する必要はない。Uaに対して、透過 な接続性が提供されるため、UaはUbとの接続性のみを関知していればよい。 さらに、ALGを経由する通信が必ずしも、ネットワークヘッダの変更を必要 とするものでないことに、注意のこと。ALGは、認証のためセションの最初 に利用されるが、その後はALGは不要となり、通信は独自に継続される。 非透過ALG、透過ALGいずれも、(定義により)アプリケーションデータ ストリームの構文と意味を理解していることが、必要である。ALGは、それ ぞれの範囲でインターネットホストとして扱われ、ネットワーク層のアーキテ クチャから見ると大変単純なものである。すなわち、それらは通信の開始端点 または終端点として動作する。 残像の他方の一端は、ネットワークアドレス翻訳機(NAT)[RFC163 1]である。このドキュメントでは、ネットワーク層およびトランスポート層 のヘッダを変更する装置であるが、アプリケーション層のデータストリームの 構文・意味は理解しない装置としてNATを定義する(我々の用語では、RF C1631に記述されているのは、NATかつALGの両者の機能を持つ装置 となる)。 一般的に、NATはプライベートアドレス[RFC1918]を使用する法人 のネットワークとパブリックなインターネットとの間に配置され、NATによ りインターネットへ向けて出て行くパケットに含まれるソースIPv4アドレ スを変更し、またインターネットから入ってくるパケットに含まれるディステ ィネーションIPv4アドレスを変更する。二つのイントラネット間の直接の 通信といった、一部が重なり合うようなアドレスを持つルーティング領域の間 を、相互接続するのに使用される場合、NATはIPヘッダの両方のアドレス を変更する。IPヘッダに含まれるアドレスを変更するため、NATはトラン スポート層の(例えばTCP、UDPの)擬似ヘッダチェックサムを変更しな ければならない。アドレスの重複するルーティング領域の相互接続の際、NA Tによってなされるネットワークおよびトランスポートヘッダに対する一連の 操作は、透過ALGによるネットワークおよびトランスポート層に対する一連 の操作の(適切な)サブセットであることが、しばらく考えて見れば、分かる だろう。 定義によりNATはアプリケーションデータストリームの構文および意味を理 解していない。それゆえ、NATはアプリケーション層でIPアドレスを運ぶ ようなアプリケーション(例えば、FTPのPORTまたはPASVコマンド) には、適用できない。一方、NATはアプリケーション層でIPアドレスを運 ばない限り、どんなアプリケーションにも対応できる。このことは、ALGが 独自のアプリケーションにしか対応できないことと対照的である。 NATにもALGにも、それぞれ限界があり、その利便性を制限していること が分かる。単一の装置でNATとALGの機能が実現できれば、幾分かは便利 だろうが、すべてに対応するのは不可能である。IPアドレスを運ばないアプ リケーションに対してはNATの機能を適用し、IPアドレスを運ぶアプリケ ーションを扱う場合、ALGの機能に頼ることになる。例えば、そういう装置 では、FTPデータコネクションの取り扱いではNAT機能を利用するが、F TP制御コネクションの扱いではALG機能を利用する。ただし、装置がAL Gの機能を介してアプリケーションをサポートできず、NAT機能で処理しよ うとする場合、IPアドレスを運ぶアプリケーションの処理に完全に失敗する ことになる。 ALGもしくはNATいずれによる通信でも、ネットワークヘッダ(特に、ソ ースとディスティネーションアドレス)、およびトランスポートヘッダの変更 を伴う。IPセキュリティー認証ヘッダは、ネットワークヘッダ中のアドレス がエンド間で保持されるものと想定しているため、ALGまたはNATの仲介 により通信するホスト間のIPセキュリティーに基づいた認証のサポートは、 適正でなくなる。信頼性のため使用される場合、IPセキュリティーはトラン スポート層のエンド間で完全に暗号化されるため、ALGまたはNATが要求 通りに暗号化パケットを変更できるか疑わしい。別の言い方をすると、IPセ キュリティーの特別な強化が検討されない限り、認証についても、信頼性につ いても、ALGおよびNATの適用は、二つの自明なIPセキュリティードメ イン間の範囲に制限される。 ALGまたはNATのいずれかを介するルーティング範囲間の相互接続は、D NS[RFC1035]に依存する。特に、(相互接続される)ルーティング 範囲の組に対して、ネットワーク層のアドレスが一意でないとしても、完全に 限定されたドメイン名(fqdn)は、その組全体を通して一意でなければな らない。ただし、NATまたはALGを運用しているサイトは、おそらく二つ のDNSサーバを動作させる必要がある。NATまたはALGの、一つは内側 に、一つは外側におき、同一の問い合わせに、それぞれ異なる応答を返す。こ れは[kre]の文献で議論されるだろう。DNSの安全性[RFC2065] と動的なDNS更新[dns2]については、NAT・ALGの境界でおそら く有効とはならないため、外部DNSサーバはなんらかの別のメカニズムによ り、テーブルの少なくとも一部を獲得することを想定せざるを得ない。 要約すると、RFC1918以降もアドレスの空間的な一意性は実際には変更 されておらず、複数の空間があることが認識されている。すなわち、各空間は 依然イントラネットのようなルーティング範囲であり、(上で議論した)NA TやALGにより他のイントラネット、またはインターネットと接続する可能 性がある。アドレスの時間的な一意性は、RFC1918によって変化してい ない。 4.2 アドレスはすべてが時間的に一意とは限らない アドレスの意味がアドレス空間のどこかで変化するのであれば、どこででも変 化するのと同様なことである。事実既に、このことは起こっている。 IPv4アドレスブロックは、何年もの間、年代順に割り当てられてきた。す なわち、ネットワークトポロジに対しては、ランダムとなっている。これによ り、ルーティングテーブルは継続的に成長を続けることになった。これは測定 できるものでない。今日、階層ルーティング(CIDR[RFC1518]、 [RFC1519])が、ルーティング範囲内、特にインターネットにおいて ルーティング規模を改良するメカニズムとして適用されるようになった(CI DRについては、付録でさらに詳しく記述する)。 CIDRの規模に対応する能力は、アドレスの割当てが、可能な限りネットワ ークトポロジを反映しているという想定に基づいている。アドレス情報の集合 に対する境界に、単一の組織が完全に含まれるよう要求しているわけではない − 複数の組織にまたがっても構わない(例えば、プロバイダとその加入者)。 加入者がプロバイダを変える場合、インターネットルーティングシステムの付 加的なオーバヘッドが加わるのを避けるため、加入者に別の番号を必要とする かもしれない。 プロバイダを変えることは、再番号割当ての理由の一つとなる。情報提供のド キュメント[RFC1900]では、何故再番号割当てが、急増するイベント となっているかを示している。DHCP[RFC1541]とPPP[RFC 1661]の両方では、動的アドレスの配布の利用を推奨している。 要約すると、DHCPとPPPの開発とその採用、および再番号割当てが一般 的な事象となるとの予測から、IPアドレスの意味は大きく変化した。空間的 な一意性は同様であり、アドレスは依然有効な配置子である。時間的な一意性 はもはや保証されない。それは短期的なものであり、場合によってはTCPの コネクション時間より短いかもしれない。この場合、IPアドレスは適切な識 別子として機能しない。このことはエンド間のセキュリティーに影響を与え、 現在の形態のTCPを変えるものである。 4.3 マルチキャストとエニイキャスト マルチキャスト[RFC1112]については、IPアドレスの意味に対する 議論をソースアドレスとデスティネーションアドレスに分けなければならない。 デスティネーションマルチキャストアドレス(すなわち、トポロジ的に広がっ たホストの一群に対する配置子)は、NATを超えることができ、イントラネ ット(またはパブリックなインターネット)に限定される必要はない。その生 存時間はやはり短いものとなる。 エニイキャストアドレスの概念は、等価な機能を実現するシステムの一団を配 置する意味を持つアドレスである。そういったアドレスは配置子以外の何者で もない。ホストを一意に識別することはないため、このドキュメントで定義し ている識別子として提示されるものではな。この場合、IPアドレスの有効な 空間的な一意性、または有効生存時間は、TCPコネクションを設定するのに 要する時間より短いかもしれない。 ここでTCPとは単に、関連性の意味を示すものとしている − 多くのUDP ベースのアプリケーション(またはIP上にある他のシステム)は、ソースと デスティネーションに基づいて、最初のパケットを受信または送信後、状態を 管理する。時間的な一意性の不在によりすべてが影響を受けるが、空間的な一 意性の変化に対してはルーティングのインフラだけが影響を受ける。 4.4 まとめ 動的なアドレス割当と増大するネットワークの再番号割当てにより、IPv4 アドレスの時間的な一意性は全世界で保証されることはない。その利用を識別 子として扱うのは、大いに疑問である。イントラネットの増大により、空間的 な一意性も、もはやルーティング範囲を超えて保証されない。ルーティング範 囲を超えた相互接続は、ALGまたはNATを経由して可能となる。原理的に は、それらの相互接続は、イントラネットが直接接続される場合よりも、少な い機能性しか持たない。実際のところ、個々の環境に依存して、機能性の違い が問題となるかかもしれないし、ならないかもしれない。 5. IPv6の考察 時間的な一意性(識別子のようなふるまい)に関する限り、IPv6のモデル [RFC1884]は、IPv4モデルの現在の状態に大変よく似ていて、そ れ以上のものではない。IPv6は、IPv6ホストのアドレスを自動コンフ ィギュレーションするためのメカニズムを提供する。与えられたプリフィック スの全てのホストについて、グローバルなIPv6アドレスへの変更を必要と するような、プレフィックスの変更が期待されている。これにより、エンド間 のセキュリティのため、およびTCP状態のようなセションの結合のために使 用される永続性のある識別子を見つけるという従来の問題は、IPv6ではよ り大きいものとなる。 IABではこのことを不運なことと捉えており、IPv6への遷移は、上位層 のエンド間プロトコルに時間的に一意な識別子を提供するための理想的な機会 であるとしている。これらの識別子の実際の性質については、将来の研究が必 要である。 空間的な一意性(配置子のようなふるまい)に関しては、IPv6アドレス空 間は十分大きく、RFC1918のアプローチやアドレス翻訳を必要とするよ うなアドレス不足は考えられない。IPv6アドレスの不足は起きないだろう が、IPv6のリンク独自の、およびサイト独自のアドレスを獲得するための 適正なメカニズムがある[RFC1884 2.4.8節]。IPv6のこれらの特 性は,IPv6に対し分割されたルーティング範囲を、妨げることはない。そ のように要求された場合(結果として、複数のセキュリティドメインとなる)。 現時点では、複数のIPv6ルーティング範囲が必要となる局面を認識してい ないが、IPv6ルーティング範囲が一つとなるか、複数となるかに対する回 答は決定し難い。複数のIPv6ルーティング範囲があると仮定すると、それ らの範囲間はALGやNATを介して相互に接続されるだろう。このALGや NATに関する考察は、IPv4に対するものと等しい。 付録:IPv4アドレス割当ておよびルーティングの現在の実例 最初IPアドレスの構造およびIPルーティングは、ネットワーク番号クラス (クラスA/B/Cネットワーク)の考えから設計された。90年代の初期、 インターネットの成長は、インターネットルーティングシステムの適用範囲、 およびIPアドレス空間の利用における重大な改良を要求していた。IPアド レス空間のクラス構造およびそれに関連するクラスルーティングは、要求に見 合うには適切でなくなり、そのため、1992から1993年の間に、インタ ーネットではクラスのないドメイン間ルーティング(CIDR)を開発した[ RFC1380]、[RFC1518]、[RFC11519]。CIDRは 新しいアドレス割当てアーキテクチャ、新しいルーティングプロトコル、さら にIPアドレスの新しい構造を包含するものである。 CIDRは、個々のサブネットやネットワークのレベルを超えて、階層ルーテ ィングの考えを拡張することで、インターネットルーティングシステムの規模 を改良する。これにより、ルーティング情報の集合は、個々のサブネットやネ ットワークのレベルに限定されず、個々のサイトやインターネットサービス提 供者のレベルにおいても許されるようになった。こうして、組織(サイト)は 組織内のすべての相手先に対して、集合を行うものとして動作する。同様に、 プロバイダは、その加入者(プロバイダに直接接続する組織)内のすべての相 手先に対して、集合を行うものとして動作する。 階層ルーティングの考えを個々のサイトやプロバイダのレベルにまで拡張する こと、これらのサイトやプロバイダがルーティング情報の集積場所として動作 することを認めることは、アドレス割当ての手続きとルーティングプロトコル の両者の変更を必要とする。CIDR前の日々において、個々のネットワーク 番号のレベルを超えてアドレス情報を集積する必要性を十分検討することなく、 サイトへのアドレス割当てが行われたため、CIDRベースの割当てでは、サ イトやプロバイダがアドレス情報の集積役として動作することができるように アドレス割当てを行うことが推奨された。こういった割当てを、”アドレス集 積者ベース”という。”集積者ベース”のアドレス割当ての利点は、CIDR では、個々のサイトやプロバイダのレベルでルーティング情報を集積するため の能力を提供するドメイン間ルーティングプロトコル(BGP−4)[RFC 1771、RFC1772]を紹介している。 CIDRは、ネットワーククラスの考えを省き、それを連続した可変サイズの (2の階乗)アドレスブロックの考えに置き換えていることで、アドレス空間 の利用率を改良している。これは、要求されるアドレス空間の量と割当てられ るアドレス空間の量の適切なバランスを可能とする[RFC1466]。これ は”集積者ベース”のアドレス割当てを促進するものである。ネットワークク ラスの考えを省略することは、ルーティングプロトコル(イントラおよびドメ イン間の両方で)およびIPフォワーディングの新しい能力を必要とする。特 に、CIDR可能なプロトコルは、可変長のアドレスプリフィックスとして示 される到達性(アドレッシング)情報を処理するのに必要であり、フォワーデ ィングは、”最長適合”アルゴリズムの実装に必要である。ルーティングプロ トコルのCIDR連係は、[RFC1817]で記述される。 CIDRの規模の能力は、アドレス割当てが可能な限りネットワークトポロジ を反映していることに基づいている。特にサイトレベルで、またプロバイダと の相互接続で、サイトやプロバイダが集積者として機能できるようにしている。 サイトがプロバイダを変更する場合、インターネットルーティングシステムへ の付加的なオーバヘッドが加わるのを避けるため、サイトは再番号割当てが必 要となる。CIDRではプロバイダを変更するすべてのサイトが再番号割当て をする必要はないが、プロバイダを変えるサイトがまったく再番号割当てをし ない場合、処理を必要とするルーティング情報の量の過剰により、インターネ ットルーティングシステムが崩壊しかねないということを強調しておくことが 重要である。 ”集積者ベース”のアドレス割当てのメンテナンス(大規模なルーティングを 促進するため)、およびサイトがプロバイダを変更する可能性を支援する必要 (競争の促進のため)から、再番号割当てのサイトに対する実際的な解決法が 要求される。急速に成長するインターネットルーティングシステムにおいて、 オーバヘッドを含めておく必要性は、再番号割当てをもっと当たり前のことと することと同様である[RFC1900]。 インターネットルーティングシステムの大規模化の要求、および規模に対する 基本メカニズムとしてCIDRを利用することは、アドレス割当てとインター ネットの管理ポリシーを進化させるものである。この進化は、”アドレス所有” ポリシー[RFC2008]に対し、別の方法として”アドレス貸し出し”の ポリシーを追加することとなる。 IPアドレシングとルーティングは、IPが最初に規定されて[RFC791] から、間断なく進化してきた。アドレッシングとルーティング原理のいくつか は既に過去のものとなり、いくつかは保持されているが、また新しい原理が紹 介されている。現在の(CIDRに基づく)インターネットルーティングおよ びアドレスは、ルーティング可能なグローバルインターネットを管理するため 階層の利用へと広がる革命的なステップである。 安全性の考慮 The impact of the IP addressing model on security is discussed in sections 4.1 and 5 of this document. 安全性に関するIPアドレッシングのモデルの影響は、本ドキュメントの 4.1 および 5節で議論されている。 謝辞 このドキュメントは、IABで開発された。建設的なコメントが Ran Atkinson, Jim Bound, Matt Crawford, Tony Li, Michael A. Patton, Jeff Schillerか ら寄せられた。それ以前の Noel Chiappa との私的なやり取りで、配置子と識 別子の概念を明らかにできた。 参考文献 [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC 790] Postel, J., "Assigned Numbers", September 1981. [RFC 959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC 1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, September 1989. [RFC 1380] Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992. [RFC 1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, May 1993. [RFC 1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993 (originally published 1982). [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993. [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993. [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC 1772] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995. [RFC 1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, September 1995. [RFC 1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, September 1995. [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996. [RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [RFC 1933] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [RFC 2008] Rekhter, Y., and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", RFC 2008, October 1996. [kre] Elz, R., et. al., "Selection and Operation of Secondary DNS Servers", Work in Progress. [RFC 2065] Eastlake, E., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997. [dns2] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS UPDATE)", Work in Progress. 著者のアドレス Brian E. Carpenter Computing and Networks Division CERN European Laboratory for Particle Physics 1211 Geneva 23, Switzerland EMail: brian@dxcoms.cern.ch Jon Crowcroft Dept. of Computer Science University College London London WC1E 6BT, UK EMail: j.crowcroft@cs.ucl.ac.uk 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