IPv6アドレス割り当てに関するIAB/IESG勧告

2000年9月1日

はじめに

　アデレードのIETFにおけるIETFとRIRの専門家による討議で、家庭と小企業に対しては/48プレフィックスでなく /56プレフィックスを割り当てるのが適切かもしれないという提案がなされた。しかし、その後の分析で、 /48を一律に使用するほうがはるかに有利であることが判明した。本文書の内容は、ピッツバーグのIETFにおけるその後の討議の成果も盛り込んだ最新情報である。

　本文書は、IPv6理事会、IABおよびIESGが作成したもので、 RIRに対するIABとIESGからの勧告である。

背景

　アドレスの割り当ては、健全な保護方法および知識とある程度の利用しやすさとのバランスをとることを技術面での方針として実施される。一方では、有限の可能性のある資源の利用を管理する場合には、予想寿命に達する前に枯渇することがないように賢明に保護することが必要である。他方では、IPv6アドレス空間はIPv4アドレス空間ほど貴重な資源では決してないため、不当に保護すると他の要因ですでに勢いを失っている市場がさらに失速することになる。したがって、市場の発展の観点からは、実際に必要なだけの数のIPv6アドレスをユーザやISP (インターネットサービスプロバイダ)が取得することが非常に容易であり、リナンバリングがすぐに必要になったりスケーリングの効率が低下する可能性がゼロであることが望ましい。

　IETFはビジネス上の問題や関係についてコメントしないが、一般には、技術的分配ポリシーはビジネスに大きな影響を与える可能性があると、われわれは認識している。アドレス分配計画に対し強く求められることは、ビジネス上の関係やビジネスモデルに基づいたりそれらに過度に影響を与えたりしないようにすることである。

　現時点でIPv6アドレスは、 64ビットの「ネットワーク番号」と64ビットの「ホスト番号」から構成されると定義されている。この構成を採用した技術上の理由はいくつかある。 1993年に合意されたIPv6の要件は、約2⁴⁰のネットワークと2⁵⁰のホストをアドレッシング可能にする計画を含んでいたが、 64/64の分割はこれを効果的に達成する。ホストアドレスの割り当てに使用される手続き (ホストに対するネットワークのプレフィックスのルータ通知[RFC2462]など)は、ローカルにユニークな番号をホスト部分に置くものだが、この分割に依存している。ホスト番号を明らかに選択している例 (IEEE Macアドレス、E.164番号、E.214 IMSIなど)は、サブネットのナンバリングのためにこの範囲のビットを使用できるという想定をすべきでないことを示唆している。現在の世代のMAC層とE.164番号は、最大64ビットのオブジェクトを指定するからである。したがって、サブネット番号にはネットワーク部分のビットを使用すると想定しなければならない。これは、個々のホストアドレスをルーティングするIS-ISレベル1(エリア内) ルーティングなどのルーティングプロトコルを除外するものではない。そのゾーンの外部では、それに依存しないこともあることを、述べているのである。

　IETFはまた、ネットワークリナンバリングの影響を極力減らすために多大な努力を払ってきた。それにもかかわらず、IPv6ネットワークのリナンバリングは、気づかれずに実施されるようにも、痛みをまったく伴わずに実施されるようにもなっていない。したがって、リナンバリングは許容できる出来事とみなすべきだが、無理なく回避できる場合には回避すべきである。

　IETFのIPNGワーキンググループは、再帰的にサブネット化されることのある単一のエッジネットワークに与えるアドレスブロックを48ビットのプレフィックスにするように勧告してきた。これに従えば、このようなネットワークのそれぞれに対し、ルーティングに使用する2¹⁶のサブネット番号と、各ネットワークの内部で使用する膨大な数のユニークなホスト番号とが与えられる。これはほとんどの企業にとっては十分な数であり、集約するエンティティに対しアドレスブロックを分配する十分な余裕を生み出すとみなされている。

　しかしながら、再帰的にサブネット化される可能性が高いことがどのエッジネットワークについてもいえるかは明らかでない。たとえば、家庭に置かれる個々のPCや携帯電話ネットワーク上の単一のセルは、サブネット化されることもあればされないこともある (パーソナルネットワークやホームネットワーク、自動車ネットワークのゲートウェイとしてたとえば働くかどうかによって異なる)。したがって、サブネット化を必要としない場所にネットワーク番号が分配される場合は、 64ビットのプレフィックス1つを与えることはISPにとって許容できるかもしれない。この場合、このプレフィックスは、同じISPルータへのダイヤルイン接続の間でおそらく共有されることになる。ただし、この決定がとられる可能性があるのは、客観的に見て/48の不足が起こらないことがわかっていて、パーソナルネットワークやホームネットワーク、自動車ネットワークが一般的になることが予想される場合である。実際、家庭(ホーム)か、モバイル(自動車または個人)か、または任意の規模の企業かとは無関係に、すべてのIPv6加入者が常時オン状態の複数のホストと、さらにサブネット化される可能性のある少なくとも1つのサブネットと、そのために必要なある程度の内部ルーティング機能とを結局は持つことが、一般に期待されている。注意すべき点は、モバイル環境では、モバイルサイトをネットワークに接続する装置は、実際には第三世代の携帯電話になるかもしれないことである。言い換えれば、加入者割り当て装置が常にホストになるということはないが、サイトになる可能性は常にある。

アドレス分配に関する勧告

　RIRコミュニティはIABとともに、初期の割り当てでサービスプロバイダに対し分配するアドレスプレフィックスの長さは29～35ビットのオーダーが適当と決定した。これは、2¹³(8K)～2¹⁹(512K)の加入者ネットワークを個々の分配でサポートできるようにするものである。割り当ては、既存の加入者ネットワークを強制的にリナンバリングしなくても、初期のプレフィックスがそれ以降のより大きな割り当てによって包含されうるように実施される。これは管理可能でかつスケーラブルなバックボーンルーティングのための技術的要件を満たす一方で、個々の分配の拡大を管理下で行えるようにする、とわれわれは考えている。

　同じタイプの規則を、エッジネットワークにおけるアドレスの割り当てに使用できるだろう。エッジネットワークがサブネット化されるかはっきりしない場合は、最初の64ビットプレフィックスを8..256のブロックから割り当てることによって、リナンバリングしなくてもある程度まではその割り当てを拡大できる余裕を確保することを、エッジネットワークに対し奨励することがある。しかしながら、以下に述べる理由により、われわれは、非常に大規模な加入者(複数の/48を受け取る可能性のある加入者)と、一時的であることがはっきりしている加入者やサブネット化への関心がまったくない加入者 (/64を受け取る可能性のある加入者)とを除くすべての加入者に対して、 /48の位置の固定境界を使用することを推奨する。注意すべき点は、将来の拡大が予想される場合は、 /48を与えないメリットはほとんどないと思われることである。以下では、/48を一律に使用することを支持する理由を述べ、このように使用してもまったく問題なくIPv6アドレス空間全体を責任を持って管理できることを示す。

　固定境界を支持する理由を次に示す。

ISPを変更してもコストのかかるサブネット内部の再構成や整理統合が必要にならないようにするには、ISPに依存しない境界を持つようにするしか方法がない。
サイトのリナンバリングを単純明快にできる。すなわち、あるプレフィックスから別のプレフィックスへサイトをリナンバリングするときには、プレフィックスの長さが一致しないと、2つのプレフィックスの並列実行を含むプロセス全体が非常に複雑になる(もちろん、そのサイトの規模と複雑度によって異なる)。
IPv6サイトのマルチホーミングについては、IPv4のマルチホーミングですでに使用されている手法などのさまざまなアプローチをとることができる。未解決の主な問題は、経路集約と最適経路選択の両方または一方を過度に損なうことなく大規模なスケーリングを行うソリューションを見つけることである。この分野についてはやり残されている研究がかなりあるが、それぞれ特有の利点と欠点を持ついくつかのアプローチが実際に利用されるようになると思われる。それらの一部(すべてではない)は、固定プレフィックス境界の場合にいっそう効果を発揮するだろう。(マルチホーミングについては、この後で詳述する。)
加入者のネットワークを容易に拡大できる。-- アドレス空間を増やすことをいつもISPに頼む必要はなくなる(/48では十分でない比較的少数の加入者は除く)。
/48を超えるアドレス空間をサイトが要求する場合以外は、ISPとレジストリはアドレス空間に対するサイトのニーズを判断しなくて済む。次に示すいくつかの利点がある。
ISPとレジストリは、顧客のネットワークのアーキテクチャと拡大計画の詳細について尋ねる必要がなくなる。
ISPとレジストリは、アドレス消費の度合いを顧客のタイプ別に判断する必要がなくなる。
評価と判断の必要性を減らすことによって、レジストリの運用効率が高まる。
アドレス空間が顧客にとって貴重な資源ではなくなるため、アドレス透過性の回復のためにIPv6の機能を無効にするv6/v6 NATを加入者がインストールする必要性はほとんどなくなる。
サイトは逆DNSゾーンを1つ維持すれば、すべてのプレフィックスをカバーできるようになる。
各プレフィックスのもとで同じサブネット化構造を使用できる場合に限り、各サイトはアドレスから名前への全プレフィックスのマッピングに同じゾーンファイルを使用できる。また、RFC 2874の規則を使用すれば、逆マッピングデータを「フォワード」(名前キー付き)ゾーンに移すことができる。

　固定境界を/48の位置にする利点を次に示す。

ロケータと識別子を分離するためのGSE (Global, Site and End-System Designator、別名「8+8」)提案は、グローバルアドレッシングとサイトアドレッシングの間の固定境界を/48の位置に想定しているが、この提案を改善する技術的オプションを利用できるようになる。GSE手法の採用は数年前に先送りされたが、この手法の強力な支持者は依然としている。また、IRTFネームスペース研究グループが、GSEと密接に関係するテーマを積極的に調べている。GSEかGSEの派生物が将来、IPv6と一緒に使用される可能性は、依然としてある。
サイトのローカルプレフィックスはfec0::/48であるため、グローバルサイトプレフィックスが/48であれば、サイトはSLAフィールドでグローバルトポロジとサイトのローカルトポロジとの間の単純な1対1マッピングを容易に維持できる。
同様に、6to4提案が標準化される場合は、ネーティブプレフィックスが/48であれば、構成の点では/48である6to4プレフィックスからネーティブIPv6プレフィックスへの移行が単純化される。

　注意すべき点は、これらの理由はどれも、家庭、自動車などは16ビットのサブネット空間を本質的に必要とするようになるという期待を暗示してはいないことである。

アドレス空間の保護

　/48をすべての加入者に与えるとアドレス空間の浪費にならないかという疑問は、当然ながら生じる。客観的な分析は、そのようにはならないことを示している。集約可能グローバルユニキャストアドレス(TLA)形式のプレフィックスに属する/48プレフィックスは、実際には45個の可変ビットを含んでいる。すなわち、使用可能なプレフィックスの数は2⁴⁵、つまり約35兆(35,184,372,088,832)ある。 1人にプレフィックス1つを割り当てるという極限のケースを考えると、 TLA空間の利用率は妥当な仮定のもとでは最高で約0.03%になるとみられる。

　もっと正確に言えば、

RFC 1715では、各種ネットワークでのアドレス空間割り当ての経験に基づいて、「H比」が規定されている。これを45ビットのアドレス空間に適用し、世界の人口が2050年までに107億人になると見積もる(http://www.popin.org/pop1998/参照)と、必要な割り当て効率はlog_10(1.07*10¹⁰) / 45 = 0.22になる。これは、RFC 1715に示されている電話番号やDECnetIVまたはIPv4アドレスの効率よりも低い。すなわち、懸念を生む原因にはまったくならない。
IPv4や他のいくつかのアドレス空間の経験と、また、*1人当たり*80ビットのアドレス空間を実現するというインターネットに関する非常に野心的なスケーリング目標とに基づいて、この分析が正しいことをわれわれは強く確信している。たとえそうであっても、要求を過小評価してきたという歴史は十分承知しているので、アドレス空間の85%以上(すなわち、集約可能グローバルユニキャストアドレス(TLA)形式のプレフィックスに属さない空間の大部分)は残しておくことにした。したがって、この分析が間違っていることがいつか判明しても、われわれの後継者はずっと制限の強い割り当てポリシーを残りの85%に対し課することができる。
非ルーティングホストによる一時的使用の場合(たとえば、プライバシー上の理由から一時的アドレスを好むスタンドアロンなダイヤルアップユーザの場合)は、/64のプレフィックスで問題ないかもしれない。しかし、「静的な」IPv6アドレス空間を必要とする加入者や、複数のサブネットを持っているか持つ計画のある加入者に対しては、前述の理由から、一時的に与える/48であっても、/48を与えるべきである。

　要約すれば、われわれが主張しているのは、 IPv6アドレス空間を慎重に管理することは不可欠だが、どんな規模のIPv6サイトにも一様なサイズのプレフィックスを使用するという便利で簡単な方法を採用してもまったく問題なくこの管理を実施できるということである。それほどの数であるから、アドレス空間を使い尽くしてしまって、初期の顧客に与えたアドレス空間が不当に大きくなってしまったり、アドレスの保護と経路集約とが悪影響を及ぼし合う、制限の強すぎるIPv4の状況に戻ってしまったりするリスクは客観的に見てなさそうである。

マルチホーミング問題

　マルチホームネットワークの領域では、 IPv4で使用されている手法をすべて適用できるが、知られているようにこれらの手法にはスケーリングに関する問題がある。特に、同じプレフィックスが複数のISPによって通知される場合は、ルーティングテーブルはマルチホームサイトの増加とともに肥大化する。 IPv6でこれを克服するための対策として、現時点でわれわれにはルーティングテーブルに関する最初の提案しかないが、活発な研究がIETFのIPNGワーキンググループで進行中である。既存の提案や新しい提案がもっと完全な形になるまでは、 IPv4で働くことがわかっている既存の手法がIPv6で使用され続けるだろう。

　理想的なマルチホーミングに関する提案は、 (少なくとも)次の重要事項を含んでいる。任意のマルチホームネットワークとのルーティング接続をグローバルに実現すること。アドレス空間を保護すること。高品質の経路を少なくとも前述のシングルホームホストのケースと同様に、そのネットワークのいずれかのプロバイダを介して生成すること。マルチホームネットワークを複数のISPに接続できるようにすること。これらのネットワークのいずれかの適切なサブセットを使用するために、偏った操作をルーティングに本質的に加えることがないこと。経路集約を過度に損なうことがないこと。非常にたくさんのマルチホームネットワークに拡大すること。

　現在検討されている1つのクラスのソリューションは、各サイトで2つ(または3つ以上) のプレフィックスを永続的に並列に実行するというものである。固定プレフィックス境界がない場合、このようなサイトは複数の異なる内部サブネットナンバリング戦略 (各プレフィックス長について1つの戦略)を持つことを要求されるかもしれないし、サイトが戦略を1つだけ必要とする場合は、そのサイトのISPのどれかから受け取った最長のプレフィックスによって定義された最も制限の強い戦略を使用することを強制されるかもしれない。このアプローチでは、マルチホームネットワークは上流プロバイダのそれぞれから与えられたアドレスブロックを持つことになるだろう。各ホストは、上流プロバイダ群から選択されたアドレスを1つだけ持つか、上流プロバイダのそれぞれから1つずつ与えられたアドレスを持つことになるだろう。最初のケースは本質的にはRFC 2260の範疇であり、スケーリングに限度があることが知られている。

　2番目のケース(各ホストが複数のアドレスを持つケース)では、上流プロバイダの数がそれぞれmとnである2つのマルチホームネットワークが通信する場合、接続を開始する側が、相互に接続するためにn*m個の可能なアドレスペアからアドレスペアを1つ選択し、その過程でその接続の間使用するプロバイダ(したがって適用可能な経路)を選択する。周囲のビットレートやロスレート、遅延は経路ごとに異なるとした場合、どちらのホストもルーティング情報やメトリック情報を持たなければ、開始する側のホストが最適アドレスペアを選択する確率は1/(m*n)にすぎない。無作為より優れたアドレス選択に関する研究はIETFで進行中だが、まだ完了していない。

　既存のIPv4インターネットが存在できるのは、どの上流プロバイダのアドレスとも異なるアドレスを持ち、そのアドレスがすべての上流プロバイダにグローバルに通知されるネットワークでは、ルーティングネットワークは適用可能なポリシーの範囲内で適度に良い経路を選択できるからである。現在のルーティングポリシーはQoS(サービス品質) ポリシーでなく到達可能ポリシーである。これは、これらのポリシーは、最適な遅延やビットレート、ロスレートを必ずしも選択するわけではないが、経路は実際に使用されるメトリックの範囲内で最善のものになることを意味する。したがって、スケーリングに関する問題を別にすれば、これはIPv6ネットワークについても正しく働くだろうと結論づけられるかもしれない。

フレッド・ベーカー | 519 Lado Drive
IETF委員長         | Santa Barbara California 93111
www.ietf.org       | オフィス:   +1-408-526-4257
                   | 携帯: +1-805-886-3873
                   | ファックス:  +1-413-473-2403

IPv6アドレス割り当てに関するIAB/IESG勧告

はじめに

背景

アドレス分配に関する勧告

アドレス空間の保護

マルチホーミング問題

このページを評価してください