本文書は RFC1900 を日本語に訳したものであり、原文と語彙あるいは解釈の
相違が生じる場合は原文を正しいものとする。訳者および日本語訳に関わった
全ての関係者は、本文書によって読者が被り得る如何なる損害の責任をも
負わない。

 					   関野  sekino@j-energy.co.jp
						      （株）シーテック
========================================================================
Network Working Group                                       B. Carpenter
Request for Comments: 1900                                    Y. Rekhter
Category: 情報伝達                                                   IAB
                                                               1996年2月
 
 
                          リナンバリング 作業の必要性 
 	                   < Renumbering Needs Work >
			 
 
このメモの状態

このメモはインターネットコミュニティーへの情報提供が目的であり、インター
ネット標準を定めるものではない。このメモの配布は自由にできる。


概要 

  リナンバリング、すなわち様々なネットワーク components の IP アドレス
情報を変更する作業は、広く一般的に行なわれるようになってきた。インター
ネットアーキテクチャーボード (IAB) はこの変更の促進を展開する必要があ
ることを強調し、そういった変更を促進したいと考えている。



１．背景

  IP ネットワーク上のホストは IP アドレスによって識別され、また、サブ
ネットの IP アドレスプレフィクスはルーティングプロトコルによって通知さ
れる。こういったホストやサブネットに関する IP アドレス情報の変更は「リ
ナンバリング」として知られる。

  リナンバリングは様々な理由で実施される。例えば、ある IP ホストが、あ
るサブネットから別のサブネットに移動すると、ホストの IP アドレスの変更
が必要となる。通信量が過負荷とならないようにするために、ひとつのサブネッ
トを物理的に分けようとする際もリナンバリングが必要となる。リナンバリン
グが必要となるもう一つの例は、ある組織がネットワーク番号の付け方の方針
を変更する際である。こういった変更はホストのアドレスの変更にとどまらず、
サブネットのリナンバリングをも意味している。上にあげたのはリナンバリン
グが発生しうる状況のたった３つの例に過ぎない。

  インターネットに IP での接続性を要求する組織にはリナンバリングはます
ます必要となっているが、リナンバリングだけを実行しても、アドレス情報が
十分に集約されることにはならない。存続のための代替策がとられなければ、
もしくはとられるまでの間は、インターネットのルーティングシステムを存続
させ続けながら、かつインターネットの絶え間のない発展を続けさせるために、
クラスレスインタードメインルーティング (CIDR) を広く採用することが極め
て重要である。このためにそういった組織が大きなアドレスブロックに属する
アドレスを利用することが望まれる。このブロックとはそのアドレスの集約者
（aggregator）であるサービスプロバイダに割り当てられたものである。ルー
ティング情報の成長を押えるためには、ある組織が新しいサービスプロバイダ
に変更する場合、その組織のアドレスは変更されなければならない。時によっ
てはサービスプロバイダ自体が新しいより広いブロックのアドレス空間に移行
しなければならなくなるかもしれない。どちらの場合にしても、ルーティング
情報の成長を押えるためには、そのことに関心のある組織はサブネットとホス
トのリナンバリングをしなければならない。もし、その組織がリナンバリング
しなければ、潜在的な結論として (a) IP 接続性が（internet のサイズより
も小さく）制限される、(b) インターネットサービスプロバイダが保持しなけ
ればならない組織のルーティング情報に関するオーバヘッドを埋め合わせるた
めの余分なコストが発生する、のいずれか、もしくは両方が考えられる。

  現在のところ、リナンバリングは一般に金のかかる、退屈な、そしてエラー
を起こしやすい作業である。普通、この作業にはその地域でのエキスパートの
従事と大変な量の事前計画が要求される。リナンバリングを容易にするツール
はほとんど存在せず、広く入手可能ではなく、広く使われてはいない。リナン
バリングのためのその場しのぎの様々な対策が開発され使われてはいるが、全
体的に見て状況は満足の行くものとは程遠い。リナンバリングの手順を記述し
たドキュメントはないに等しい。インターネットの様々な所でリナンバリング
が行なわれているが、ドキュメントによる経験の共有は行なわれていないに等
しい。


２．DNS 対 IP アドレス

  インターネットの構造の中で、個々のホストはそのホストのネットワークイ
ンターフェイスに割り当てられた IP アドレスによって特定できる。このドメ
インネームシステム (DNS) には読みやすい名前を IP アドレスに関係付ける
手段を提供してくれる。DNS の名前空間は IP アドレスの空間から独立してい
る。DNS の名前は普通ホストの所有者や機能に関係付けられているが、アドレ
ス付けやルーティングのメカニズムとは関係ない。DNS での名前の変更は機能
や所有者が実際に変更されたしるしであるかもしれないが、IP アドレスの変
更は純粋に技術的なことである。

  ドメイン名の見地から情報を表現することにより、実行するまではある特定
のネットワークのエンティティとその IP アドレスを関係づけることを延期す
ることができる。企業のドメイン名とサーバーや多くのユーザシステムのため
の公式フルドメイン名（FQDN、RFC 1594 参照）は IP アドレスに比べてかな
り長生きしかつより安定していることが期待される。関連づけを延期すること
により、 IP アドレスと特定のネットワークエントリーの間の（アドレス情報
変更による）対応付けの変更のリスクを避けることができる。さらに、（IP 
アドレスよりもむしろ）FQDN に依存することによってまた、リナンバリング
のためにアドレス情報の変更に必要な変更を DNS に局所化させることもでき
る。

  いくつかのケースでは、デスクトップ／ポータブルのシステムのアドレスと 
FQDN 両方とも、動的に割り付けられる。これを取り扱えるのは高度にかしこ
い動的な DNS 更新のメカニズムだけである。

３．推奨   

  リナンバリングをより実行可能とするために、IAB は以下を推奨している。
すなわち、全ての設計とインプリメンテーションは人間が運用する不揮発性の
記憶装置にIP アドレスが格納されるようなケース（コンフィギュレーション
ファイルのような）を最小限にすることである。TCP/IP プロトコルで参照さ
れるコンフィギュレーション情報は可能な限り IP アドレスよりもむしろ 
FQDN で表現されるべきである。IP アドレスをアプリケーション内に直接埋め
込むことには反対である。DNS コンフィグレーションの一部として以外には、
名前からアドレスへの対応付けのリストを保持するファイルには反対で、可能
な限り避けられなければならない。

  DNS よりむしろ IP アドレスを記述したコンフィギュレーションファイルを
必要とするような過去の遺産であるアプリケーションを上記での推奨を満たす
ようにアップグレードできない時期は存在する。このような場合は、DNS のルッ
クアップするによってアドレスの置換えることにより、ドメイン名を使用する
他のファイルから自動的にコンフィギュレーションファイルが生成されるよう
推奨する。

  ホストシステムの IP アドレスを基にしたライセンシング技術（licensing
technology）を利用することでリナンバリングは非常に難しくなる。だから、
そういった技術の利用は強く思いとどまるべきである。

  ホストのリナンバリングを容易にし自動化するツールキットの開発とその展
開は非常に重要である。ダイナミックホストコンフィグレーションプロトコル 
(DHCP) は明らかにそういったツールキットの本質部分である。IAB は DHCP 
のインプリメンテーションと広い範囲での展開を強く奨励する。動的ルータ検
出と (RFC 1256) とサービスロケーション（現在 IETF で作業中）もまたそう
いったツールキットの中に属する。十分な認証ができるドメインネームシステ
ム (DNS) の動的な更新能力のサポートはホストのリナンバリングをさらに促

進する。 IAB は、真の自動コンフィギュレーション可能な TCP/IP ホストを
提供するために DHCP と動的更新能力の統合を目標として、IETF 内でこの分
野の標準化に向けた作業の進展を奨励する。

  IAB はインターネットコミュニティ内でリナンバリングの経験を共有し、リ
ナンバリングの経験を文書化することを強く奨励する。 IAB は IETF（及び特
にそのOperational Requirements Area）がそういったドキュメントを作成す
る最も適当な場であると提案する。IAB は PIER (Procedures for
Internetand Enterprise Renumbering) ワーキンググループの作成を歓迎する。


４．セキュリティに関する考察

  セキュリティアソシエーションが有効な間、アドレスが変わらない限りリナ
ンバリングはインターネットのセキュリティ構造と共存できると考えられる。


謝辞

  このドキュメントはIABとの共同の製作物のひとつである。特に Michael
Patton、Steve Bellovin、Jeff SchillerやBill Simpson その他何人かの方々
から有用なコメントをいただいた。


著者のアドレス

   Brian E. Carpenter
   Group Leader, Communications Systems
   Computing and Networks Division
   CERN
   European Laboratory for Particle Physics
   1211 Geneva 23, Switzerland

   Phone:  +41 22 767-4967
   Fax:    +41 22 767-7155
   Telex:  419000 cer ch
   EMail: brian@dxcoms.cern.ch


   Yakov Rekhter
   cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134

   Phone: (914) 528-0090
   EMail: yakov@cisco.com