Cisco SBA BN IPv6 アドレッシング ガイド August 2012

SBA
BORDERLESS
NETWORKS
DESIGN
OVERVIEW
IPv6 アドレッシング ガイド
S M A R T
B USI NE S S
A R C HI TEC TURE
August 2012 Series
はじめに
このガイドの対象読者
この Cisco® Smart Business Architecture（SBA ）ガイドは、次のような役割を果た
す方を対象としています。
• ソリューションを実装するための標準の手順を必要とするシステム エンジニア
• Cisco SBA を実装するための作業明細書を作成するプロジェクト マネージャ
コマンドの読みとり方
多くの Cisco SBA ガイドでは、Cisco IOS 、Cisco NX-OS 、command-line
interface（CLI）で設定するその他のオペレーティング システムを実行するシスコ ネット
ワーク デバイスを設定する方法の詳細について説明しています。 ここでは、入力する必
要のあるコマンドの指定に使用する規則について説明します。
• 新しいテクノロジーを販売したり、実装のドキュメントを作成したりする販売パート
CLI で入力するコマンドは、次のようになります。
• クラスでの指導用またはオンザジョブ トレーニング用の資料を必要とするトレーナー
変数の値を指定するコマンドは、次のようになります。
ナー様
通常、Cisco SBA ガイドを使用して、エンジニア間および設定間の一貫性を向上させ、
導入ジョブのスコープとコストを改善させることができます。
リリース シリーズ。
シスコは、SBA ガイドの更新と改善を定期的に実施しています。 シスコは、一連の SBA
ガイドの展開に伴い、これらのガイドを 1 つの包括的なシステムとしてまとめてテストして
います。Cisco SBA ガイドの設計の相互互換性を確保するためには、同じシリーズに属
するガイドを使用する必要があります。
シリーズのリリース ノートには、シリーズへの追加および変更の概要が記載されています。
すべての Cisco SBA ガイドの表紙と各ページの左下には、シリーズ名が記載されていま
す。 シリーズは、リリースした年月に基づいて、次のように名前が付けられます。
month year Series
たとえば、2012 年 8 月にリリースしたガイドのシリーズには、
「August 2012 Series」
という名前が付けられます。
次のサイトで SBA ガイドのシリーズを参照できます。
お客様のアクセス：http://www.cisco.com/jp/go/sba/
販売パートナー様のアクセス：http://www.cisco.com/go/sbachannel/
August 2012 Series
configure terminal
ntp server 10.10.48.17
定義する必要のある変数を持つコマンドは、次のようになります。
class-map [highest class name]
スクリプトの場合やコマンド プロンプトが含まれている場合のインタラクティブな例で表
示されるコマンドは、次のようになります。
Router# enable
行が折り返される長いコマンドには下線が引かれます。 1 つのコマンドとして入力します。
wrr-queue random-detect max-threshold 1 100 100 100 100 100
100 100 100
システム出力またはデバイス コンフィギュレーション ファイルの注目すべき部分は、次の
ように強調表示されます。
interface Vlan64
ip address 10.5.204.5 255.255.255.0
コメントと質問
ガイドについてコメントがある場合や質問がある場合は、 SBA フィードバック フォームを
使用してください。
新しいコメントが投稿されたときに通知を受け取りたい場合は、SBA のお客様およびパー
トナー ページから RSS フィードが利用できます。
はじめに
目次
この SBA ガイドの内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Cisco SBA ボーダレス ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . 1
成功へのルート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
はじめに. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
アドレス指定の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
アドレスの表現 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
アドレスのタイプ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
IPv6 アドレスの割り当てポリシー . . . . . . . . . . . . . . . . . . . . . . . . . . 6
アドレス計画 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
アドレス ブロックに関する推奨事項 . . . . . . . . . . . . . . . . . . . . . . . . 11
ネットワーク レベルの設計に関する考慮事項 . . . . . . . . . . . . . . . . . . 11
August 2012 Series
サブネット計画：最初のアドレス ブロック要求 . . . . . . . . . . . . . . . . . . 12
サブネット計画：集約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
サブネット計画：拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
サブネット計画：プレフィクス長 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
アドレス指定計画の構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
インターフェイス ID の割り当て . . . . . . . . . . . . . . . . . . . . . . . . . . 20
IP Address Management（IPAM） . . . . . . . . . . . . . . . . . . . . . . 23
IPv6 アドレス計画のケース スタディ . . . . . . . . . . . . . . . . . . . . . . . 23
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
リソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
IPv6 リソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
アドレス関連リソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
目次
この SBA ガイドの内容
Cisco SBA ボーダレス ネットワーク
Cisco SBA は、フルサービスのビジネス ネットワークの設計と迅速な導入を支援します。
Cisco SBA を使用した展開は、模範的ですぐに使える設定であり、スケーラビリティと
柔軟性を備えています。
Cisco SBA は、LAN、WAN、ワイヤレス、セキュリティ、データセンター、アプリケーショ
ン最適化、およびユニファイド コミュニケーション テクノロジーを 1 つの包括的なシステ
ムとしてまとめてテストし、これらを取り入れています。このコンポーネント レベルのアプロー
チにより、複数のテクノロジーのシステム統合が簡略化されるため、技術的な複雑さについ
て心配することなく、企業の問題を解決できるソリューションを選択できるようになります。
Cisco SBA ボーダレス ネットワークは、接続ユーザが最大 10,000 人までの企業を対
象とした包括的なネットワーク設計です。SBA ボーダレス ネットワーク アーキテクチャに
は、有線およびワイヤレス ローカル エリア ネットワーク（LAN）アクセス、ワイド エリ
ア ネットワーク（ WAN）接続、WAN アプリケーション最適化、およびインターネット エッ
このガイドについて
この設計の概要では、次の情報を提供します。
• Cisco SBA 設計の概要
• 設計を形成している要件の説明
• 設計を利用することで組織が得られるメリットの説明
次のサイトで Cisco SBA ガイドのシリーズを参照できます。
お客様のアクセス：http://www.cisco.com/jp/go/sba/
販売パートナー様のアクセス：http://www.cisco.com/go/sbachannel/
ジ セキュリティ インフラストラクチャが組み込まれています。
成功へのルート
このガイドの設計を確実に実装するには、このガイドが従属しているいずれかのガイド（以
下のルートで、このガイドの左側に表示されている）を最初に読む必要があります。この
ガイドでは、具体的な前提条件が該当する箇所で引用されています。
Prerequisite Guides
You Are Here
Dependent Guides
BORDERLESS
NETWORKS
LAN Design Overview
August 2012 Series
IPv6 Addressing Guide
LAN Deployment Guide
Additional
Deployment Guides
この SBA ガイドの内容
1
はじめに
グローバルなインターネットの継続的な成長に伴い、ユーザ、アプリケーション、アプラ
イアンス、サービスは増加を続けています。そして、これらをサポートする新しいテクノ
ロジーに対応するために、アーキテクチャ全体には進化が求められています。 Internet
Protocol Version 6（IPv6）は、これらの要件を満たし、ネットワークのアドレッシング
ルールがアプリケーションに対して透過的であるグローバルな環境を実現するように設計
されています。
IPv6 の開発は、1990 年代初めから初期リリースの RFC で行われています。この
開発は主に、IPv4 アドレス空間はリソースが限られており、最終的には枯渇すると
いう認識から行われるようになりました。2011 年 2 月 3 日に、Internet Address
Numbers Authority（IANA ）は、IPv4 アドレスの中央プールが枯渇したことを発表し
ました。地域レジストリは現在それぞれの地域プールに残っているものを配布していま
すが、早晩底をつきます。よく知られた IPv4 アドレス枯渇追跡サイトは http://www.
potaroo.net/tools/ipv4/ で確認できます。現在、Asia Pacific Network Information
Center（ APNIC）は 2012 年 4 月、European IP Networks（RIPE）は 2012 年
8 月、American Registry for Internet Numbers（ ARIN）は 2013 年 7 月、Latin
American and Caribbean Internet Addresses Registry（LACNIC）は 2014 年 1
月、African Network Information Center（ AFRINIC）は 2014 年 10 月に、それぞ
れ IPv4 アドレスの手持ちがなくなると予想されています。
現在の環境への IPv6 の統合を組織に真剣に考えさせる要因がいくつかあります。
• ビジネスの継続性
• インターネットの発展
• 行政の対応
• IT のコンシューマライゼーションと新しいアプリケーション
ビジネスの継続性の観点からは、IPv6 はネットワークの成長と、サービスの消費者の環
境を問わずサービスを提供できる能力に関係します。成長の必要性はインターネットの発
展に直接つながります。
August 2012 Series
インターネットは、より高いモバイル ユーザ ベースにクラウドベースのサービスを可能に
するためのプラットフォームとして成長しています。複数の予測で、2020 年にはネットワー
ク接続デバイスが 500 億台に達することが示されています。この数字は大きすぎるよう
に感じますが、ネットワークがスマート ビルディングやオフィス、スマート グリッド、仮
想化、モビリティに対応している状況を考えてください。
これらの新しいネットワーク アクセス ポイントがすべて、メインストリーム アプリケーショ
ンやオペレーティング システムへの IPv6 のコンシューマライゼーションをもたらしていま
す。新しいオペレーティング システムはすべて IPv6 をサポートしています。IPv6 はデフォ
ルトで有効になっており、多くの場合は優先的に選択されます。スマートフォンのような新
しいインターネット デバイスは、デフォルトで IPv6 を実行します。IPv6 の統合には複数
の要素が関係します。
• 組織はユーザに個人所有のデバイスの選択を認めています（BYOD：Bring Your
Own Device）。このようなデバイスでは、前に説明したように、IPv6 のネイティブ
な実行が増加しています。
• モバイル事業者がモバイル デバイス（スマートフォンやタブレット）で IPv6 に対応し
た 2012 年以降、IT インフラストラクチャがこのようなデバイスを管理された環境に
受け入れることが重要になっています。
• 組織は Windows 7 と Server 2008 、Apple MacOSX、Linux を採用するよう
になっており、これらはすべて IPv6 をネイティブにサポートしています。
IPv6 統合計画の立案に利用できるリソースがいくつかあります。IETF の複数の RFC と
ドラフトでは、統合計画が示されています。テクノロジーの背景と統合計画が示されてい
る複数の書籍を入手できます。本書の最後のリソース セクションでは、IPv6 についてさ
らに調べるのに役立つ RFC と書籍が示されています。
これらのさまざまなドキュメントや書籍では、アドレス指定計画の作成について言及してい
ますが、詳しい説明はありません。本書では、 IPv6 のアドレス指定計画の立案方法につ
いて説明します。
はじめに
2
アドレス指定の概要
末尾のゼロを残して先頭のゼロを削除するロジックのたとえとして、次のような場合を考
えます。 160 ドルは $0160 と表現でき（160 ドル）、$160 と短縮できますが（やはり
160 ドル）、苦労して得たお金を手放すのでもなければ、$16（16 ドル）とは短縮できま
せん。
これらのルールを考慮すると、前に示した次のアドレスは以下のように短縮できます。
IPv4 と IPv6 の最も顕著な相違点の 1 つは、アドレス空間のサイズです。IPv4 は 32
ビットで、約 40 億のホスト（4 X 109）に対応します。IPv6 は 128 ビットで、約 340
アンデシリオン（340 X 1036）個のアドレスを使用できます。
アドレスの表現
最初に説明するのは、128 ビットの表現方法です。番号空間のサイズのため、IPv6 アド
レスの表現には 16 進数とコロンが選択されています。IPv6 アドレスの例を次に示します。
2001:0db8:130f:0000:0000:7000:0000:140b
次の点に注意してください。
• 大文字小文字は区別されません。小文字「a」は大文字「A」と同じ意味です。
◦
RFC 5952 では小文字の使用が推奨されています。
• コロンの間の各グループには 16 ビットが含まれます。
◦
8 フィールド X 16 ビット / フィールド = 128 ビット
前記のアドレスに対して許容される短縮表現がいくつかあります。
• 各 16 ビット グループ内の先頭にあるゼロは省略できます。したがって、ゼロだけの
フィールドは 1 個の 0 で表すことができます。
• 各 16 ビット グループ内の末尾のゼロは省略できません。
「::」に省略できます。この短縮表現は、アドレス
• 連続するゼロだけのフィールドは、
内で 1 回だけ使用できます。アドレスを可能な限り短縮するため、:: を使用する必要
があることに注意してください。
August 2012 Series
2001:0db8:130f:0000:0000:7000:0000:140b
先頭のゼロを除去したアドレスは次のようになります。
2001:db8:130f:0:0:7000:0:140b
末尾のゼロは除去できません。
2001:db8:130f:0:0:7000:0:140b
連続するゼロのフィールドを短縮して、最終的なアドレスは次のようになります。
2001:db8:130f::7000:0:140b
最終的な例で 7 の後にあるゼロは重要であり、次のフィールドと結合して 2 個のコロン
に短縮できないことに注意してください。ゼロのグループが複数あったとしても、 2 個の
コロンを使用できるのは 1 回だけです。
アドレス表現の最後の部分は、プレフィクスの表記に関係します。標準的な IPv6 アドレ
スは、64 ビットを使用してネットワークを表し、残りの 64 ビットでインターフェイス ID
またはホストを表します。前記のアドレスを例として使うと、ネットワーク フィールドとホ
スト ID フィールドは図 1 のように分かれます。
図 1 - IPv6 アドレスの分割
Network - 64 Bits
Interface ID - 64 Bits
2001:0db8:130f:0:
0:7000:0000:140b
2164
ここでは、IPv6 でのアドレス指定の基礎について説明します。このアドレス指定の概要は
復習の意味のものであり、 IPv6 でのアドレス指定に関する総合的な解説ではありません。
IPv6 のアドレス指定アーキテクチャの詳細な説明については、RFC4291（http://www.
ietf.org/rfc/rfc4291.txt ）を参照してください。
Classless Interdomain Routing（CIDR ）プレフィクス表現を使用して、IPv6 アドレス
を表します。次に示すのはこの表記法の例です。
2001:db8:130f::870:0:140b/64
/64 は、最初の 64 ビットがネットワークの表現に使用され、後の 64 ビットがインターフェ
イス ID の表現に使用されていることを示します。
アドレス指定の概要
3
重要な違いは、1 つの IPv6 インターフェイスに複数の IPv6 アドレスが関連付けられる
可能性があることです。このモデルは、IPv4 とは非常に異なります。IPv4 では、通常、
インターフェイスは 1 つのアドレスを割り当てられるだけです。 IPv6 のインターフェイス
は、常にリンク ローカル アドレスを持ちます。IPv6 のインターフェイスは、1 つ以上の
ユニーク ローカル アドレスまたはグローバル ユニーク アドレスも持ちます。
技術的なヒント
RFC 5952 は、IPv6 アドレスの表現に関するガイドラインを規定しています。
アドレスのタイプ
RFC 4291（IP Version 6 Addressing Architecture）では、IPv6 アドレスの種類が
示されています。
• ユニキャスト
• エニーキャスト
• マルチキャスト
ユニキャスト
ユニキャスト アドレスは、1 つのインターフェイスに対する ID として定義されます。通常、
ユニキャスト アドレスは、特定のエンド システムが別の特定のエンド システムと通信す
る必要があるときに使用します（たとえば、ピアツーピアの会話）。IPv6 ユニキャスト ア
ドレスを割り当てるときは、スコープをグローバル、ユニーク ローカル、リンク ローカル
から選択します。
リンク ローカル アドレスは、単一のリンクでの通信に使用されます。リンク ローカル ソー
ス アドレスまたは宛先アドレスを持つパケットは、そのリンクのルータでは転送されませ
ん。リンク ローカル アドレスは、そのリンクでのみ意味を持ちます。すべてのリンク ロー
カル アドレスは、fe80::/10 プレフィクスで始まることにより識別できます。前に説明した
ように、すべての IPv6 インターフェイスにはリンク ローカル アドレスが割り当てられて
います。
図 3 で、最後の 64 ビットがインターフェイス ID として指定されていることに注意してく
ださい。IPv6 では、IPv6 アドレスの「ホスト」部分はインターフェイス ID と呼ばれます。
インターフェイス ID は、リンク ローカル、ユニーク ローカル、グローバル ユニークのい
ずれかにかかわらず、すべての IPv6 アドレスの一部です。
インターフェイス ID を割り当てるには、手動、自動 / ステートレス、Dynamic Host
（DHCP）など、複数の方法があります。これらの方法については、
Configuration Protocol
このガイドの「インターフェイス ID の割り当て」で詳しく説明します。
図 3 - リンク ローカル アドレスの表現
128 Bits
0
図 2 では、定義される各アドレスのスコープを示します。
図 2 - IPv6 のアドレス スコープ
1111 1110 10
Interface IDLink-Local
64 Bits
2166
fc80::/10
10 Bits
Unique-Local
Link-Local
2165
Global
August 2012 Series
ユニーク ローカル アドレスは、特定のリンクの外部に到達できますが、限られたスコー
プまたはドメインの内部でのみ意味を持ちます。ユニーク ローカル アドレスは、インター
ネット経由でのルーティングを意図されていません。特定のサイトまたはカスタマー ドメ
インの内部でルーティング可能である必要があります。ユニーク ローカル アドレスは、
IPv4 での RFC 1918 アドレスに似ています。ユニーク ローカル アドレスと RFC 1918
空間の主な違いは、ユニーク ローカル アドレス空間はグローバルに一意であることが意
図されていることです。
アドレス指定の概要
4
でなければならないので影響はほとんどありません。問題は、組織はプレフィクスを生成
するときに ULA アドレス ブロック生成アルゴリズムに従う必要がないことです。組織 X
と Y はどちらも fd00:dead:beef::/48 を使用できます。イングレスとイーグレスにそれ
ぞれフィルタを設定して、 ULA プレフィクスを拒否し、予想外のことがないようにする必
要があります。
ユニーク ローカル アドレスは、すべてが fc00::/7 アドレス ブロックからなので認識でき
ます。図 4 はユニーク ローカル アドレスを分解したものです。アドレスがローカルに割り
当てられている場合、 L ビットは 1 に設定されます。0 ビットは、将来の使用のために、
RFC4193 によって確保されています。L ビットのこの定義により、fc00::/7 ブロックは
次の 2 つのブロックで構成されます。
• fc00::/8：将来の使用のために予約
RFC 4193 では、40 ビットのグローバル ID を割り当てる方法が指定されています。
RFC で定義されている準ランダムなアルゴリズムにより、一意性の可能性が非常に高い
グローバル ID が提供されます。ユニーク ローカル アドレスを生成するためのアルゴリズ
ムは、インターネットの複数の場所で実装されています。たとえば、http://www.sixxs.
net/tools/grh/ula/ を参照してください。
図 4 - ユニーク ローカル アドレスの表現
128 Bits
Subnet ID
Host
45 Bits
16 Bits
64 Bits
001 Global Routing Prefix
Subnet
3 Bits
Interface IDLink-Local
表 1 では、地域レジストリに対する現在のグローバルに一意なブロック割り振りのサブ
セットを示します。詳細なリストは、 Internet Assigned Numbers Authority（IANA ）
の Web サイト（http://www.iana.org/assignments/ipv6-unicast-addressassignments/ipv6-unicast-address-assignments.xml）にあります。
IPv6 のアドレス ブロック
2001:/16
地域レジストリ
2400:0000::/12
APNIC
2600:0000::/12
ARIN
2800:0000::/12
LACNIC
2A00:0000::/12
RIPE NCC
2C00:0000::/12
AfriNIC
各種
IPv6 アドレス空間には複数の予約ブロックまたは特殊用途ブロックが複数の RFC にお
いて定義されています。RFC 5156 には、現在定義されている特殊用途アドレスのリスト
40 Bits
があります。一部の一般的なブロックとその用途は次のとおりです。
Interface IDLink-Local
1111 110
Subnet ID
fc00::/7
16 Bits
• ::1：ループバック インターフェイス用に予約（RFC 4291）
• ::：未指定アドレス（RFC 4291）
• 2001:db8::/32：ドキュメント用（RFC 3849）
2167
Global ID
7 Bits
Provider
表 1 - 地域レジストリに対するグローバルに一意なブロックの割り振り
• fd00::/8：ローカルに割り当てられたユニーク ローカル アドレス
L Bit
図 5 - グローバル アドレスの表現
• 2002::/16：6to4 自動トンネリング用（RFC 3964）
• 2001::/32：Teredo トンネリング メカニズム用（RFC 4380）
グローバル アドレスはインターネット全体から到達できます。グローバル アドレスは地域
レジストリ（ RIPE、ARIN 、APNIC など）によって割り振られます。現在、グローバル ア
ドレスはすべて 2000::/3 ブロックから割り当てられています。
August 2012 Series
2168
Unique Local Address（ULA ）空間の意図されたグローバルな一意性は、RFC 1918
アドレスと RFC 4193 アドレスの間の大きな違いです。RFC 1918 アドレスは組織内で
広く使用されるため、インターネットではルーティングできません。ULA 空間のグローバ
ルな一意性はルート リークをもたらす可能性がありますが、原則として ULA 空間は一意
アドレス指定の概要
5
ユニーク ローカル アドレスは、 RFC 4193（ユニーク ローカル IPv6 ユニ
キャスト アドレス）で規定されています。
マルチキャスト
マルチキャスト アドレスは、通常は異なるノードに属する一連のインターフェイスに対する
ID として定義されます。マルチキャスト アドレスを使用すると、同種のコンテンツ（ビデ
オなど）の受信に関心のあるインターフェイスのグループを示すことができます。この場合
の会話モデルは 1 対多モデルです。マルチキャスト アドレスは ff00::/8 ブロックから割
り当てます。
また、マルチキャスト アドレスにはスコープが割り当てられています。このスコープは、ユ
ニキャスト アドレスに対して定義されているスコープとよく似ています。
• リンク ローカル：リンク ローカル マルチキャスト アドレスは、リンク上のシステムの
みを対象とし、ネットワーク機器でそのリンクの外に転送できません。この動作は、
リンク ローカル ユニキャスト アドレスと同じです。
• 組織：組織のマルチキャスト アドレスは、組織内での使用を意図されています。これ
• ff02::2：リンク ローカル、すべてのルータのアドレス
• ff02:0:0:0:0:1:ffXX:XXXX：リンク ローカル、送信要求ノード アドレス
図 6 - マルチキャスト アドレスの表現
8 Bits
4 Bits
4 Bits
112 Bits
FF
Flags
Scope
Group-ID
Link-Local
1111 1111
F
F
8 Bits
R P T Scope
8 Bits
Flags
T for Lifetime, 0 if Permanent, 1 if Temporary
P for Unicast-based Assignments
R for Embedded RP
Others Are Undefined and Must Be Zero
Scope
1 = Interface-Local
2 = Link
3 = Admin-Local
5 = Site
8 = Organization
E = Global
0, 3, F = Reserved
2169
技術的なヒント
• ff02::1：リンク ローカル、すべてのノードのアドレス
らのアドレスは、ユニキャスト ユニーク ローカル アドレスと似ています。
• グローバル：グローバル マルチキャスト アドレスは、ユニキャスト グローバル ユニー
ク アドレスと同様にインターネット経由で使用できます。
IPv6 マルチキャスト アドレス用に追加定義されたスコープがいくつかあります。
• インターフェイス ローカル：インターフェイス ローカル マルチキャスト アドレスは、
ノード内でマルチキャストを送信するためのものです。
• サイト ローカル：サイト ローカル マルチキャスト アドレスは、単一のサイト内での
使用を意図されています。
図 6 は、IPv6 マルチキャスト アドレスの形式を示したものです。
ユニキャスト アドレス空間と同様に、予約された、または特殊な用途を持つマルチキャス
ト アドレスがあります。よく利用されるマルチキャスト グループとその用途を次に説明し
ます。現在割り当てられているマルチキャスト アドレスの詳細なリストについては、http://
www.iana.org/assignments/ipv6-multicast-addresses を参照してください。
IPv6 システムでよく利用される永続的に割り当てられたマルチキャスト アドレスとしては、
次のようなものがあります。
August 2012 Series
エニーキャスト
定義されている IPv6 アドレスのタイプの最後のものはエニーキャストです。1993 年頃
に RFC 1546 で IPv4 用に定義されたものですが、Domain Name System（DNS）
ルート サーバのプロビジョニングを除き、ほとんど使用されていません。13 個のルート
サーバの各アドレスがインターネット全体の多数のマシンによってバックアップされていま
す。エニーキャスト アドレスは、異なるノード上の複数のインターフェイスに割り当てられ
た ID と定義されます。エニーキャストの通信モデルは 1 対多数の中の最も近いものです。
つまり、エニーキャスト通信モデルでは、ホストは可能性のある多数のノードの中で最も
近いものと通信します。最も近いとは相対的な用語であり、通常、選択条件に基づいて最
も近い、つまり最適なエニーキャスト アドレスを決定する方法は、ルーティング プロトコ
ルとそれに関連するメトリックに委ねられます。エニーキャスト通信のよい例は DNS クエ
リーです。www.xyz.com のアドレスを知る必要があるホストは、どの DNS サーバが応
答するかということには関心がありません。クエリーを作成したホストは、トポロジで最
も近いサーバに送られます。応答していた DNS サーバがオフラインになると、次に近い
サーバが要求を受け取ります。エニーキャスト アドレスとユニキャストはアドレスで区別で
きません（たとえば、エニーキャスト アドレスにするように定義されたビットはありません）。
アドレス指定の概要
6
IPv6 アドレスの割り当てポリシー
アドレス割り振りモデル
現在は、IANA が地域レジストリにアドレス ブロックを割り振っています。さらに、レジ
ストリがサービス プロバイダーにアドレス ブロックを割り当てます。個々のカスタマーに
アドレスを渡すのは、サービス プロバイダーの責任です。現在のポリシーは地域によって
異なり、最もよくあるケースでは、エンド ユーザは地域レジストリに IPv6 アドレス空間
を直接要求するのではなく、サービス プロバイダーから IPv6 アドレス空間を入手する必
要があります。
図 7 では、この初期ポリシーのしくみを示します。この割り当てモデルは、一般に、
Provider Aassigned（PA ）割り当てまたは Provider Dependent（PD）割り当てと呼
ばれます。図 7 で示されているプレフィクスの長さは推奨値です。これらの初期推奨値は
RFC 3177（IAB/IESG Recommendations on IPv6 Address Allocations to Sites）
に従っています。この RFC 3177 は RFC 6177（IPv6 Address Assignment to End
Sites）に置き換えられています。レジストリとサービス プロバイダーは、それぞれの地
域およびカスタマーに対して設けたプロセスと手順を使用して、ブロックを割り当てること
ができます。
図 7 - プロバイダー依存のポリシー
きます。たとえば、大規模なエンタープライズ ISP カスタマーは /40 の割り当てを必要
とし、個人カスタマーは /60 の割り当てを必要とします。
地域レジストリが設けるこのポリシーの例外により、エンド カスタマーはレジストリに直
接 IPv6 アドレス空間を要求できます。この例外は、プロバイダー非依存（PI）アドレス
指定と呼ばれます。
PI アドレス指定が必要になるのは、複数のサービス プロバイダーを分離するためにマル
チホーミングを望むエンド カスタマーや、アドレス空間を要求するときに自分のリソースを
管理したい組織に対応するためです。提案されているプロバイダー依存割り振りモデルで
は、カスタマーは各サービス プロバイダーからアドレス ブロックを割り当てられます。組
織が異なるサービスに切り替える場合は、組織全体のアドレスを再設定する必要がありま
す。そのような組織が複数のサービス プロバイダーに接続している場合は、複数の異な
るアドレス ブロックを管理する必要もあります。マルチホーミングの問題に対処するには、
複数の方法が示されています。マルチホーミングは IPv6 での新しい問題ではなく、IPv4
にも存在することに注意してください。IPv6 で新しく発生したことは、IPv6 アドレス ブ
ロックの割り当て方法に関するポリシーです。
PI アドレス指定は、マルチホーミングに対する暫定的な解決策として、すべての地域レジ
ストリによって採用されています。 PI アドレス指定では、カスタマーは組織への IPv6 ブ
ロックの直接的な割り振りを要求できます。ブロックの割り振りを受けるには、カスタマー
が満たす必要のある要件があります。 IPv6 のプロバイダー非依存ポリシーのアドレス割り
当てに関する地域レジストリのポリシーは、次の Web サイトで参照できます。
• ARIN のポリシー：https://www.arin.net/policy/nrpm.html
IANA
• RIPE のポリシー：http://www.ripe.net/ripe/docs/ripe-545
ARIN
/12 to /23
RIPE NCC
/12 to /23
LACNIC
/12 to /23
ISP
/19 to /32
ISP
/19 to /32
ISP
/19 to /32
ISP
/19 to /32
SITES
/30 to /60
SITES
/30 to /60
SITES
/30 to /60
SITES
/30 to /60
• APNIC のポリシー（ポータブル割り当てと呼ばれます）：http://www.apnic.net/
policy/ipv6-address-policy
• LACNIC のポリシー：http://lacnic.net/en/politicas/manual.html
• AFRINIC のポリシー：http://www.afrinic.net/en/library/
policies/132-afpub-2007-v6-001
PI アドレス指定には潜在的な問題がいくつかあります。これについては、次の「アドレス
計画」セクションで説明します。
2170
APNIC
/12 to /23
ポリシーの例として、IANA は ARIN に対して割り当て用に 2600:0000::/12 を割り当
てています。これはモデルの最上位の階層にあたります。その後、ARIN は、2600::/29
ブロックを Sprint に、2600:300::/24 を AT&T Mobility に、2600:7000::/24 を
Hurricane Electric に割り当てています。これらのブロック割り当ては、RFC 3177 で
定義されている本来のモデルには従っていません。さらに、サービス プロバイダーは、カ
スタマーのニーズに基づいてカスタマーにブロックを割り当てます。インターネット サービ
ス プロバイダー（ISP）は、広い範囲のアドレスをカスタマーに柔軟に割り当てることがで
August 2012 Series
アドレス指定の概要
7
アドレス計画
ここでは、IPv6 のアドレス指定計画を立案するときに考慮する必要のあるガイドラインに
ついて説明します。 IPv6 のアドレスに関しては複数の RFC が作成されています。これま
でに触れた RFC 4291 や 4193 などでは、IPv6 アドレスのアーキテクチャが定義され
ています。
IPv6 のアドレス指定計画の立案は、IPv4 アドレス計画の立案と導入に関して学んだすべ
てのことを適用するよい機会です。 RFC 5375 では、アドレス指定計画を立案するときに
考慮する必要のある問題が示されています。ユニーク ローカル アドレスを使用する必要
があるかどうか、PI アドレス ブロックを取得する必要があるか、プロバイダー割り当ての
アドレスで問題ないか、といったことです。
PI アドレス指定
プロバイダー非依存空間を使用する大きな利点は、組織が特定のプロバイダーに縛り付け
られないことです。プロバイダー非依存空間を使用する組織は、プロバイダー アドレス空
間が変わるときにネットワーク全体のアドレスを付け替えることなくプロバイダーを変更で
きます。
また、 Provider Independent（PI）空間を使用すると、1 つの IPv6 アドレス ブロック
で複数のサービス プロバイダーに接続できます。このような複数の接続は、特定のサービ
ス プロバイダーのネットワークで問題が発生したときのための復元性と冗長性を提供しま
す。
また、PI モデルでは、ソース アドレス選択の潜在的な問題を心配することなく、 1 つ
のアドレス空間ブロックを導入して管理できます。組織がマルチホームで、Provider
Assigned（PA ）モデルを使用している場合は、少なくとも 2 つのアドレス ブロックを
管理する必要があります。エンド システムには複数のアドレスが割り当てられ（たとえば、
各 Service Provider（SP）ブロックから 1 つずつ）、アドレス管理のコストが増え、ソー
ス アドレス選択の問題の可能性が高くなります（たとえば、SP A の通過に問題がある場
合、エンド システムはどのようにして SP B のアドレスを使用することを知るか）。
PI アドレス指定を考慮するときの主要な問題は、組織が複数の地域レジストリに存在する
場合にどうするか、ということです。たとえば、会社 A は北米に本社サイトがあり、ヨー
ロッパとアジアにデータセンターのサイトがあるものとします。会社 A は ARIN 、RIPE、
APNIC から PI 空間を入手するのでしょうか。それとも、ARIN だけから PI 空間を入手
しますか。この質問に簡単に答えることはできません。
August 2012 Series
SP の観点からの主な焦点は、ルーティング テーブルの拡大に関係します。アドレス空間
を 128 ビットに拡大すると、ルーティング テーブルもかなり大きくなる可能性があります。
このようなルーティング テーブルの拡大と、その結果としてのサービス プロバイダーのメ
ンテナンスにより、SP は、カスタマーからプレフィクスを受け取ってピアにそれをアドバタ
イズする方法について、より詳しく検討する必要があります。
現在の SP の方法では、地域 PI ブロックのフィルタリングは行われていません（たとえ
ば、ヨーロッパの SP は、カスタマーからの PI アナウンスだけを受け付けます）。つまり、
ARIN から PI 割り当てを受ける組織は、そのブロックを分割して、ヨーロッパとアジアで
アナウンスできる必要があります。
サービス プロバイダーが PI アドレス ブロックを処理する方法に関して可能性のあるもう
1 つの問題は、受け取って伝播するプレフィクスの長さに関係します。各地域レジストリに
は、初期ブロック サイズの割り当てに関して固有のポリシーがあります。割り当てられる
プレフィクスの最小長は、プロバイダー非依存空間の場合は /48 ブロックです。カスタマー
からアナウンスを受け取るサービス プロバイダーにとっては何も問題がないかもしれませ
んが、そのピアであるダウンストリームのサービス プロバイダーでは、/48 のアナウンス
の受け取りに問題がある可能性があります。その場合、他のサービス プロバイダーが懸
念するのは、ルータが保持する IPv6 ルーティング テーブルのサイズです。
これらは、IPv6 のアドレス計画を作成するときの重要な問題です。組織は、 PI 空間につ
いて検討し、SP と話し合って SP が実施している IPv6 のプレフィクス ポリシーを明ら
かにする必要があります。SP と最初に確認する必要のある問題を次に示します。
• SP は PI アドバタイズを受け付けるか ?
• SP がカスタマーから受け付けるプレフィクスの最大長は ?
• SP がピア パートナーから受け付けるプレフィクスの最大長は ?
• SP のピア パートナーが受け付けるプレフィクスの最大長は ?
ほとんどのプロバイダーでは、カスタマーまたはピア パートナーから受け付ける最長のプ
レフィクスは /48 です。このポリシーを SP と検証する必要があります。SP のポリシーは、
ルーティング サーバを調べるか、分析サービスを使用して SP が現在の IPv6 プレフィク
ス アナウンスを処理する方法を調べることで、検証できます。ルーティング サーバと分析
サービスについては、 http://www.bgp4.as/looking-glasses を参照してください。
アドレス計画
8
PI アドレス空間の使用が推奨される場合の例を次に示します。
• 組織が複数の異なるプロバイダーに接続している
• プロバイダー非依存の IPv6 プレフィクスのアナウンスを受け付けることで、サービス
プロバイダーと合意している
プロバイダー割り当てアドレス空間について以下の例で検討することを推奨します。
• 単一の SP を使用する中小規模の組織
プロバイダー割り当てアドレス
プロバイダー割り当てアドレスは、IPv6 アドレス空間を取得するもう 1 つの方法です。プ
ロバイダー割り当てモデルでは、組織の接続先のサービス プロバイダーがその組織にアド
レス空間を提供する責任を負います。このモデルでは、組織はサービス プロバイダーと協
力して、組織で必要なアドレス空間の大きさを決定します。サービス プロバイダーにとっ
ての利点は、複数のカスタマー ブロックを 1 つのアナウンスに集約できることです。図 8
はこの概念を示したものです。
• アウトソーシングを望む小規模の IT 企業
ユニーク ローカル アドレスでのアドレス指定
IPv6 のアドレス計画を作成するときは、グローバル ユニーク アドレスと Unique Local
Addresses（ULA ）のどちらを使用するかという問題が発生します。これらの選択肢は
組み合わせることも可能です。IPv6 のエンドポイントは、複数の IPv6 アドレスを持つこ
とができ、ほとんどの場合は実際に持っているので、ユニーク ローカル アドレスとグロー
バル アドレスの両方を使用できます。インターネット接続が必要な場合は、グローバル
アドレスを使用する必要があります。
図 8 - 1 つのアナウンスへのカスタマー ブロックの集約
Customer A
2001:db8:0001:/48
重要なのは、ユニーク ローカル アドレスを導入すると、プロバイダー割り当てアドレス空
間と PI アドレス空間のどちらを使用しているかということとは関係なく、アドレス指定方
式を導入できることです。ユニーク ローカル アドレスを導入すると、グローバルな再アド
レス指定イベントの間でも、内部ネットワークは動作できます。
2001:db8:0001:0001:/64
2001:db8:0001:0002:/64
ユニーク ローカル アドレスで適用可能な用途の 1 つに、内部の通信にはユニーク ロー
カル アドレスを使用し、カスタマー ドメインの外部のデバイスにアクセスするときには
グローバル アドレスを使用する場合があります。ユニーク ローカル アドレスとグロー
バル アドレスの両方を導入する場合、RFC 3484（Default Address Selection for
Internet Protocol version 6（IPv6））ではエンド システム間の通信に適したアドレスを
選択する必要があります。他の新しい設計と同じように、この適用と動作はテスト環境で
検証する必要があります。図 9 では、この方式の使用方法の例を示します。
Announces the
/48 Prefix
ISP
2001:db8::/32
Customer B
2001:db8:0002:/48
組織にとっての PA アドレス モデルの利点は、アドレス計画作成の大部分を SP が行う
ことです。このモデルでは、組織が適切に運用するために十分なアドレス ブロックがある
ことを、SP が保証します。SP がアドレス計画の作成に関わるレベルの詳細については、
プロバイダーによって異なります。
Announces the
/32 Prefix
IPv6
Internet
Announces the
/48 Prefix
2001:db8:0002:0001:/64
2171
2001:db8:0002:0002:/64
この例では、カスタマー A と B は SP に接続し、それぞれ SP の /32 ブロックから
/48 ブロックを割り当てられています。SP は自律システムの内部でさらに特定の /48 ブ
ロックを保持できますが、ピア パートナーには /32 をアドバタイズします。
August 2012 Series
アドレス計画
9
RFC 6296 のリリースにおいて、IPv6-to-IPv6 network prefix translation が標準
化されました。この RFC により、内部インフラでは ULA アドレスだけを導入できるよ
うになります。ビジネス パートナーと通信するエッジまたはインターネット エッジでは、
IPv6-to-IPv6 Network Prefix Translation（NPTv6）対応の変換デバイスを導入でき
ます。次の図では、このシナリオの動作方法を示します。
図 9 - ULA とグローバル アドレス通信
図 10 - ULA アドレスだけを導入するシナリオ
2001:db8:1:2::21/64
fd02:2:2:2::21/64
2001:db8:1:1::3/64
fd01:1:1:1::3/64
Site 1
fd9c:58ed:7d73:2800::/64
Site 2
fd9c:58ed:7d73:3000::/64
Corporate
Backbone
Internet Connection
Branch 1
ULA Space
fd9c:58ed:7d73::/48
Branch 2
図 9 では、複数のデバイスがユニーク ローカル アドレスとグローバル ユニーク アドレ
スの両方を持っています。プリンタやネットワーク管理システムのような内部のみの通信が
発生すると、 ULA がそのセッションに使用されます。この通信は赤い線で示されていま
す。通信セッションは、それぞれ fd01:1:1:1::3 および fd02:2:2:2::21 であるエンド シ
ステムの間に確立されます。組織 / サイトの境界を越えて通信を行う必要があるときは、
グローバル ユニーク アドレスが使用されます。図 9 では、このセッションは青で示され
ています。図 9 で示されているように、この例では、インターネット境界を越える通信で
は、 2001:db8::/32 ブロックからのアドレスが使用されます。ユニーク ローカル アドレ
スを使用した場合、Path MTU Discovery（PMTUD）などの特定の機能が動作しない
ことに注意してください。ユニーク ローカル アドレスを使用して発信されたパケットは、
多くの場合フィルタリングされます。したがって、 PMTUD などの機能がすべての通信に
ついて動作するためには、グローバル ユニーク アドレスの使用を考える必要があります。
すでに述べたように、テスト環境でこの機能が正しく動作することを検証する必要があり
ます。
Corporate
Headquarters
fd9c:58ed:7d73:2::/64
ULA Internal
Global External
Requires NAT for IPv6
Internet
2173
2001:db8:3:1::3/64
2172
Corporate
Backbone
Global-2001:db8:cafe::/48
ユニーク ローカル アドレスを導入すると、マルチキャストに関して問題が発生する可能性
があります。 RFC 3484 で現在定義されているソース アドレス選択方法を使用すると、
ユニーク ローカル アドレスがグローバル アドレスに優先して選択されます。この選択に
より、インターネット向けのマルチキャスト トラフィックで問題が発生し、RPF チェック
に合格できなくなる可能性があります。 ULA は内部用であり、インターネットでの使用は
意図されていないことに注意してください。また、ULA ソース アドレスを持つパケットが
インターネット境界でのフィルタリングで除外されることもよくあります。
August 2012 Series
アドレス計画
10
NPTv6 では、プライベートな内部の組織プレフィクスをパブリックなグローバル到達可能
アドレスに変換するメカニズムが提供されます。この変換メカニズムはステートレスで、内
部アドレスと外部アドレスの間に 1:1 の関係を提供します。RFC で示されている NPTv6
の使用例には、パートナー ネットワークとのピアリング、マルチホーム、冗長性とロード シェ
アリングが含まれます。
NPTv6 は変換機能を実行しますが、現在広く使用されている Network Address
Translation（NAT ）と同じ機能ではありません。NPTv6 がステートレスであるのに対し、
NAT は実行する変換のためのステート テーブルを保持する必要があります。NPTv6 は
ポート マッピングを行いません。NPTv6 では、パケット内のレイヤ 4 ポート番号は変更
されません。NPTv6 では、インターフェイス ID は変更されません。つまり、NPTv6 で
は、内部アドレスから外部アドレスに 1 対 1 で直接マップすることしかできません。NAT
では、レイヤ 4 ポートを変更できるため、複数の内部アドレスに単一のグローバル アド
レスを使用できます。NPTv6 はステートレスな性質を備えているため、着信接続と発信
接続の両方をサポートできます。NAT はステートフルな性質を備えているため、通信確立
プロセスの一部を制御できます。変換の状態が NAT に存在しない場合、通常、着信接
続は確立できません。表 X に、NAT と NPTv6 の違いを示します。
NAT 44
NPTv6
Stateful
Stateless
1:N address mapping
1:1 address mapping
Layer 4 port manipulation
No Layer 4 port manipulation
Host address manipulation
No host address manipulation
Outbound connections
Inbound and outbound connections
RFC 5520 には、ソース アドレスの選択と ULA の使用に関するその他のいくつかの考
慮事項が記載されています。インターネット ドラフトは、標準化プロセスを通じて RFC
3484 およびソース アドレス選択プロセスの更新に取り組んでいます。詳細については、
draft-ietf-6man-rfc3484bis-01 および draft-ietf-6man-rfc3484-revise-05 を
次に、ULA を検討する際の指針と推奨事項をいくつか示します。
• ULA は、グローバル ユニーク アドレス指定を変更する必要がある場合に、ネットワー
ク全体の番号を再割り当てする際に役立ちます。 ULA を使用すると、すべてを更新
しているときに内部の通信を継続できます。
• ULA は、内部のネットワーク管理機能に使用してください。ただし、グローバル ユ
ニーク アドレスをループバック インターフェイスに使用して、Path MTU Discovery
（PMTUD）などの機能が正常に動作するようにしてください。
• ULA は、内部専用リソース（プリンタなど）へのアクセスに使用してください。
• NPTv6 の機能と NAT の機能は同じではありません。
◦
NPTv6 では、内部および外部の IPv6 プレフィクスに対してステートレスな 1
対 1 のマッピングが提供されます。
◦
NAT のような 1 対 N のマッピングは提供されません。
◦
NAT で提供されると考えられるセキュリティ上の利点は、NPTv6 にはありませ
ん。
セキュリティ上の推奨事項は、組織へ送られる ULA アドレスをすべての外部境界でフィル
タリングすることです。エクストラネット パートナーなどとの事前の取り決めによって特に
許可されていない限り、ULA ソース アドレスまたは ULA 宛先アドレス持ち、ネットワー
クの外部から送信されたトラフィックはすべて、ネットワークに入るのを禁止する必要があ
ります。
アドレス ブロックに関する推奨事項
ベスト プラクティスとして、組織は、主に関連する地域レジストリからプロバイダー非依
存空間を取得することを推奨します。PI 空間によって提供されるポータブルなアドレス空
間により、組織は、RFC 6296 で特定されている潜在的な変換の問題と RFC 5220 で
特定されている送信元選択の問題を回避しながらさまざまな SP に接続できます。組織
は、単一の ISP を接続に使用する場合でも、PI モデルを追求する必要があります。
ネットワーク レベルの設計に関する考慮事項
IPv6 アドレス空間のサイズは膨大であるため、ネットワーク エンジニアは極めて柔軟に
アドレス計画を設計できます。アドレス指定を構築する際には、2 つの考慮事項があります。
1 つはサブネットのサイズ設定と割り当てを行う方法で、もう 1 つはインターフェイス ID
を割り当てる方法です。このセクションでは、IPv6 サブネット化方式を構築する方法につ
いて説明します。
参照してください。
August 2012 Series
アドレス計画
11
サブネット計画：最初のアドレス ブロック要求
アドレス指定計画を構築する際には、IPv6 アドレス ブロックに対する最初の要求に注意
する必要があります。このステップは、組織がプロバイダー割り当て空間またはプロバイダー
非依存空間の使用を検討している場合に行われます。
次に、 IPv6 アドレス ブロックの初期サイズを設定する際の考慮事項をいくつか示します。
• 現在のネットワーク全体のサイズと将来の拡張：組織は、要求する IPv6 アドレス ブ
ロックのサイズを見積もる際には、ネットワークのサイズを考慮する必要があります。
ネットワークのサイズを見積もる際には、サブネットの数を考慮する必要があります。
これは、エンド システムの数に基づく IPv4 計画と異なる点です。組織は /32 の要
求を正当化できるほど大きいですか。/44 ブロックは機能しますか。組織はすべてを
/48 に適合させることができますか。
• マルチホーミング戦略：組織は、IPv6 アドレスに対する最初の要求を構築する際には、
単一または複数のサービス プロバイダーに接続するときの冗長性と障害のシナリオに
関するアプローチを考慮する必要があります。
• 多国籍組織の考慮事項：多国籍組織は、現在の割り当てポリシーによって厳格な階
層が課されているため、 IPv6 アドレス ブロックを要求するときのアプローチを考慮
する必要があります。
以下では、組織が最初の IPv6 ブロック要求を構築する際に従う必要がある推奨事項に
ついて説明します。
初期ブロックの要求のサイズを設定するには、現在のネットワークのサイズ（サブネットの
数など）と予想される将来の拡張を考慮する必要があります。もう 1 つの考慮事項は、
フェールオーバー、トラフィック エンジニアリング、および冗長性を処理する方法です。サー
ビス プロバイダーは、受け入れおよびアドバタイズを行うプレフィクス長に関するポリシー
を絶えず更新しています。サービス プロバイダーは、組織に /48 を割り当てる現在の推
奨事項とポリシーに従って、 /48 を最長のプレフィクス長として受け入れ、それを他のプロ
バイダーにアドバタイズすると考えられます（一部のプロバイダーは、ネットワーク内に完
全に含まれているユーザ用にそれより長いプレフィクスを受け入れ、長いプレフィクスを集
約したものをアドバタイズします）。このポリシーには、組織が冗長性を処理する方法に関
するヒントが含まれています。 IPv4 を使用する場合、組織は割り当てられた /16 アドレ
ス ブロックを /17 アドレス ブロックに分割し、その長いアドレス ブロックをアドバタイズ
して、サービス プロバイダーとともに何らかのルーティング ポリシーとトラフィック エン
ジニアリングを適用できます。その後、より具体的なルートを通知しているピアに何かが
起こった場合には、/16 を送信して冗長性を処理できます。
/48 プレフィクスは、サービス プロバイダーが他のプロバイダーに通知すると考えられる
最長のプレフィクス長です。組織が何らかのトラフィック エンジニアリングを行う必要があ
り、冗長性とフェールオーバーに関する懸念を抱いている場合は、最初のブロック要求を
/48 よりも大きくし（ /44 など）、集約が引き続き行われるように連続するアドレス ブロッ
クから要求する必要があります。この状況は、前に説明した IPv4 のシナリオに似ています。
/40 ブロックを受信した組織は、より具体的な /48 ブロックを通知して、それらのロケー
ションに直接トラフィックを引き込むことができます。同時に、プライマリ パスに何かが
起こった場合には、/40 集約を通知して冗長性を処理できます。
本書の執筆時点では、長さ /48 の PA プレフィクスのフィルタリングについて論争があり
ます。そのため、アドレス指定ポリシーを検討する際には、この点を考慮してください。詳
細については、http://mailman.nanog.org/pipermail/nanog/2012-March/046419.
html を参照してください。
複数のレジストリにまたがる組織は、参加している各レジストリからアドレスを取得するこ
とを検討する必要があります。この戦略を使用すると、組織は各レジストリが備えている
可能性があるさまざまなポリシーに対応できます。また、このアプローチでは、冗長性と
トラフィック エンジニアリングに柔軟に取り組むことができます。
上記の考慮事項は、プロバイダー割り当て空間とプロバイダー非依存空間の両方のサブネッ
ト計画の構築に適用できます。組織がプロバイダー割り当て空間またはプロバイダー非依
存空間のどちらを使用しているかは重要ではありません。
PI アドレス空間は、初期の IPv6 アドレス計画を構築する際のもう 1 つの考慮事項です。
組織は、PI アドレス空間が組織のニーズを満たすかどうかを検討する必要があります。組
織の冗長性およびトラフィック エンジニアリングの要件は、プロバイダー割り当てアドレス
で十分に対応できるものですか。対応できない場合は、PI アドレス空間で解決できる可
能性があります。
先に述べたように、組織は、主に関連する地域レジストリからプロバイダー非依存空間を
取得することを推奨します。最初に割り当てるアドレス ブロックのサイズを正当化するプ
ロセスは、レジストリごとに異なります。
たとえば、ARIN ポリシーは、組織が有するサイトの数に関連します。次に、ARIN ポリシー
に記載されている内容の詳細を示します。
• 2 ∼ 12 個のサイトが正当化された場合は、/44 が割り当てられる
• 13 ∼ 192 個のサイトが正当化された場合は、/40 が割り当てられる
• 193 ∼ 3,072 個のサイトが正当化された場合は、/36 が割り当てられる
• 3,073 ∼ 49,152 個のサイトが正当化された場合は、/32 が割り当てられる
他の地域レジストリは、/48 ブロックの割り当てから開始し、より大きなブロックを正当
化するためのプロセスを有します。
August 2012 Series
アドレス計画
12
最初の IPv6 アドレス ブロックを取得する方法を決定したら、アドレス計画を構築する際
のその他の要因について検討します。ネットワークの現在のサイズは、最初のブロック要
求を構築する際の主な考慮事項でしたが、全体的なサブネット計画を検討する際の大きな
要因でもあります。現在の RFC では、/48 プレフィクスを組織に割り当てることが推奨
されています。/48 プレフィクスにより、組織は 216（65536）個の /64 プレフィクスを
使用できます。この例では、それに応じてネットワーク デバイスがパケットの転送に使用
するルーティング テーブルのサイズが増大することに焦点を当てます。IPv6 アドレス指定
計画を構築する際の主要な推進要因は、ネットワークの拡張を可能にする IPv6 プレフィ
クスの集約を考慮に入れることです。
図 11 は、集約原則の単純な適用例を示しています。この場合、サービス プロバイダーは、
地域レジストリから 2001:db8::/32 アドレス ブロックを取得しています。サービス プロ
バイダーは、その後、アドレス ブロックをカスタマーに割り当てます。この例では、カス
タマー A は 2001:db8:1::/48 を取得し、カスタマー B は 2001:db8:2::/48 を取得し
ます。この方式では、各カスタマーは、選択した任意の方式で内部ネットワークにサブネッ
トを割り当てることができます。ただし、すべての内部サブネットをサービス プロバイダー
への 1 つの /48 アナウンスに集約します。サービス プロバイダーは、ピア プロバイダー
への単一の /32 アナウンスに割り当てたカスタマーのアドレス ブロックをすべて集約しま
す。
図 11 - 階層 的なアドレス指定
Customer A
2001:db8:0001:/48
2001:db8:0001:0001:/64
2001:db8:0001:0002:/64
Announces the
/48 Prefix
ISP
2001:db8::/32
Customer B
2001:db8:0002:/48
Announces the
/32 Prefix
IPv6
Internet
Announces the
/48 Prefix
2001:db8:0002:0001:/64
2001:db8:0002:0002:/64
2174
サブネット計画：集約
集約がキーであるとしても、厳格な階層が必要ないと考えることが依然として合理的であ
ることを覚えておいてください。厳格な階層に従うことができないのには、いくつかの理
由があります。アドレスの節約は依然として重要です。アドレスの節約は、 IPv4 のときと
は意味合いが異なりますが、全体的なアドレス指定計画を構築する際には引き続き考慮す
る必要があります。
August 2012 Series
アドレス計画
13
サブネット計画：拡張
表 2 - 地域プレフィクスの内訳
拡張は、ネットワークにサブネットを割り振る際のもう 1 つの考慮事項です。サブネット
の割り当ておよび操作は、組織のプレフィクス内のビット境界に基づいて行うことができま
す。サブネット計画には、将来の拡張に対応するための余地も残しておく必要があります。
ネットワークへのサブネットの追加には、アドレス空間の隣接するブロックを予約して残し
ておくことで対応できます。
地域
地域プレフィクス
予約済み
2001:db8:1::/52
地域 1
2001:db8:1:1000::/52
地域 1
2001:db8:1:2000::/52
このプロセスを示すために、ある企業が IPv6 ネットワークを構築するために
2001:db8:1::/48 プレフィクスを受け取ったと仮定します。この企業は、ネットワークを
4 つの地域に分割しました。この企業は、受け取った /48 アドレス ブロックにより、サ
ブネット計画の構築に 16 ビットを使用できます。この数字は、組織全体を通じて /64
プレフィクスを使用するという前提に基づいています。最初の 4 ビットは、地域の識別に
使用できます。これにより、16 個の地域の設定が可能になります。より大きなサブネット
空間を必要とする可能性がある地域には、連続するブロックを割り当てることができます。
各地域内での拡張に対応するためのギャップも残しておくことができます。各地域内では、
次の 4 ビットを使用して組織内の施設またはサイトを識別できます。これにより、地域あ
たり最大 16 個の施設を設定することが可能になります。最後の 8 ビットは、各施設に
適用されます。これにより、施設あたり最大 256 個のサブネットを設定することが可能
になります。
地域 1 の拡張に備えて予約済み
2001:db8:1:3000::/52
地域 2
2001:db8:1:4000::/52
地域 2 の拡張に備えて予約済み
2001:db8:1:5000::/52
図 12 - プレフィクスの内訳
16 Bits for Organizational Subnets
2001:db8:1:0000::/48
4 Bits for Subnet Prefix
4 Bits for Subnet Function
4 Bits to Define Regional Prefix
2175
4 Bits to Define Site Prefix
表 2 に、地域プレフィクスの内訳を示します。半分以上のアドレス空間が予約済みになっ
ていることに注意してください。
地域 3
2001:db8:1:6000::/52
地域 3 の拡張に備えて予約済み
2001:db8:1:7000::/52
地域 4
2001:db8:1:8000::/52
地域 4 の拡張に備えて予約済み
2001:db8:1:9000::/52
予約済み
2001:db8:1:a000::/52
予約済み
2001:db8:1:b000::/52
予約済み
2001:db8:1:c000::/52
予約済み
2001:db8:1:d000::/52
予約済み
2001:db8:1:e000::/52
予約済み
2001:db8:1:f000::/52
上の表では、地域 1 は大きな地域として識別されており、地域内で使用できる 2 つの連
続するブロックが割り当てられています。この割り当てにより、地域 1 では、64 の施設
と施設ごとに 256 個のサブネットを設定することができます。他の地域は地域 1 よりも
小さく、当初は地域 1 ほど大きなブロックを必要としません。ただし、アドレス計画には、
将来の拡張に対応するためのギャップが残されています。施設にサブネットを割り当てる
場合にも同じようにできます。大きな施設には、施設のサイズに対応するために、最初に
連続するブロックを割り当てることができます。たとえば、地域 2 の施設 1 は大きな施
設で、連続するブロックが割り当てられています。
技術的なヒント
RFC 3531 は、組織の IPv6 プレフィクス内のビット境界に基づいてサブネッ
トを割り当てる計画と、ネットワークが拡大して多くのサブネットが必要になっ
た場合に、その境界を操作または変更する方法を表しています。
August 2012 Series
アドレス計画
14
サブネット計画：プレフィクス長
プレフィクス長を割り当てる際には、エンド ステーションを含むネットワーク セグメントと
ネットワーク インフラ セグメントの 2 つのネットワークを考慮する必要があります。
エンド ステーションが接続されたセグメントの場合、IPv6 用のアドレス指定 RFC では、
/64 プレフィクス長を使用することが推奨されています。セグメントあたり 264 個のアド
レスを使用できるため、エンド システムをホストするセグメントのプレフィクス長が /64
より短くなることはほとんどありません。/64 セグメント プレフィクスは、エンド ステー
ションにインターフェイス ID を割り当てるためにステートレスな自動構成を使用する場合
にも必要になります。セキュア ネイバー探索とプライバシー拡張にも /64 プレフィクスが
必要です。
ネットワーク インフラにプレフィクスを割り当てる際には、多数のオプションを使用できま
す。ネットワーク プランナーは、ネットワーク全体を通じて一貫性を保つことを選択し、ネッ
トワーク インフラとホスト アクセス セグメントの両方に /64 プレフィクスを導入できます。
ネットワーク プランナーは、/64 よりも長いプレフィクス長を使用する計画を選択すること
もできます。これらすべてのオプションが使用できるため、ネットワーク インフラへのプレ
フィクスの割り当てに使用できる厳格なルールはありません。アドレス計画のこの段階では、
ネットワーク プランナーは前述の原則、つまり単純さ、集約、および拡張を頭に入れてお
く必要があります。表 3 に、プレフィクスをリンクに割り当てる際に考慮する必要があるい
くつかのガイドラインの概要を示します。残りのセクションでは、これらの考慮事項の背景
と詳細に関する追加情報を提供します。
表 3 - リンク レベルのプレフィクスに関する懸念事項
プレフィクス
64 ビット
懸念事項
一貫性が確保されるため、管理が容易になる
SLAAC 、SEND、およびその他の自動アドレス割り当て方法を使
用する場合は必須
サブネットがエンド システムの数と整合しないため、アドレス空間
の「浪費」と見なされる
< 64 ビット
サブネットあたりのホスト数を増やすことができる
悪習と考えられている
64 ビットでは、現在のメディア タイプとトランスポートで効果的に
サポートできないほど多くのホスト用空間が提供される
> 64 ビット
アドレス空間の節約
特殊なケース：
/126：p2p に有効
/127：p2p に有効（RFC 6164）
/128：通常はループバック インターフェイスに使用される
ループバック アドレス
インフラストラクチャ管理
管理を複雑にする
次の特定のアドレスの重複を回避する必要がある
Embedded RP（RFC 3956）
ISATAP アドレス
August 2012 Series
アドレス計画
15
/64 よりも長いプレフィクスの使用を検討する際には、いくつかの潜在的な問題がありま
す。最初の懸念分野は、IPv6 アドレスのビット位置 71 および 72（それぞれ「u」および
「g 」ビット）に関連しています。これらのビットには特定の意味があり、これらのビットの
値は正しく設定する必要があります。ビット 71 は、アドレスがグローバルに一意であるか、
ローカルに割り当てられたものであるかを示します。ビット 72 は、アドレスがユニキャス
トであるか、マルチキャストであるかを示します。これらのビット位置は、MAC アドレス
におけるその機能と EUI-64 アドレス拡張プロセスに関連しています。現在、ほとんどの
IPv6 実装では、これらのビット設定は説明されていません。
アドレス指定に関する別の問題は、ネットワークでマルチキャストが使用され、 RFC
3956 に従ってマルチキャスト グループに Rendezvous Point（RP）情報が埋め込まれ
る場合に現れます。RFC 3956 では、RP に /64 のプレフィクス長が必要です。この要
件は、全体の計画を策定するときに対応する必要があります。
最後の懸念分野は、Intra Site Automatic Tunnel Address Protocol（ISATAP）アド
レスに関連しています。ISATAP では、/64 を使用する必要があり、IPv6 アドレスの最
後の 32 ビットに IPv4 アドレスが埋め込まれます。ISATAP では、ホスト インターフェ
イスの ID を完成させるために、0000:5efe が使用されます。このシーケンスは、 /64
よりも長いプレフィクス長を検討する場合には避ける必要があります。
ネットワーク インフラに対する推奨アプローチの 1 つは、/64 、/124 、/127、および
/128 プレフィクスを使用することです。/128 は、ネットワーク ノードを識別するために、
ループバック アドレスに使用されます。/64 または /127 は、シリアルや Packet over
SONET POS リンクなどのポイントツーポイント リンクに使用されます。/124 または
/64 は、複数のアドレスを必要とするインフラストラクチャ セグメント（たとえば、ファイ
アウォールと複数のルータを含むセグメントなど）に使用できます。/64 プレフィクス方式
は、最も実装が簡単な方式です。あるいは、より具体的なプレフィクスを使用する方式を
採用すると、最もアドレスを節約できます。この時点で、 /64 方式の単純さと具体的なプ
レフィクス方式の潜在的な複雑さのどちらかを選ぶ必要があります。
この決定に影響すると考えられるのは、RFC 6164 で特定されている問題です。この問題
とは、未使用のアドレスが多数存在するポイントツーポイント リンクでは、ホップ カウン
トの有効期限が切れるまでパケットがループする可能性があることです。このシナリオでは、
パケットはリンク上に存在しないアドレスに送信されます。POS リンクなどのインターフェ
イスは、ネイバー探索を使用せずにパケットを転送します。このシナリオの両方のルータは、
ホップ カウントの有効期限が切れるまでパケットの転送を続行します。RFC 4443 では、
この問題を解決するために、ルータはこれらのパケットを転送せずに、ICMPv6 宛先到達
不能メッセージを生成する必要があると記述されています。
August 2012 Series
次の表に、/64 、/126 、または /127 のどのプレフィクス長を使用するかを決定する際に
考慮する必要がある要因を示します。
表 4 - プレフィクス長に関して考慮する必要がある要因
/64
/126
/127
パケットが未指定のアドレ 論理上は最適であるもの
スに送信された場合、ピン の、依然としてピンポン ルー
ポンが発生する可能性があ プが発生する可能性がある
る
古い RFC 3627 および
5375 では、サブネットルー
タのエニーキャストにより
/127 を使用しないように
推奨されているが、新しい
RFC 6164 では、/127 を
使用するように推奨されて
いる
他の LAN ブロックに対し
て全体的な一貫性を維持
する場合によく使用され
る（Cisco IOS デバイスで
は、ピンポン ループの問
題が解決されている）
IPv4 タイプの節約主義を
維持する場合によく使用さ
れる（Cisco IOS デバイス
では、ピンポン ループの問
題が解決されている）
シスコ デバイスは、/127
アドレスの設定時にサブ
ネットルータのエニーキャス
トを無効にする
また、RFC 4443 により、
コード 3 宛先到達不能
メッセージをネイバー ルー
タに送信することが義務付
けられている
また、 RFC 4443 により、
コード 3 宛先到達不能メッ
セージをネイバー ルータに
送信することが義務付けら
れている
ほとんどのベンダーの機器
は、サブネットルータのエ
ニーキャストを使用しない、
または使用する予定がない
全体にわたって同じ長さを
維持することに運用上の重
点が置かれている場合は、
この方式を使用する
v4 /30 タイプのアドレス指
定セマンティクスを維持す
ることに運用上の重点が置
かれている場合は、この方
式を使用する
v4 /31 タイプのアドレス指
定セマンティクスを維持す
ることに運用上の重点が置
かれている場合は、この方
式を使用する
表 2 の計画例は、/64 サブネットと /126 サブネットの両方を使用してインフラス
トラクチャ アドレスを計画する方法を示しています。/64 のケースを最初に取り上
げます。表 2 では、最後の 2 つの地域ブロック（2001:db8:1:e000::/52 および
2001:db8:1:f000::/52）は、インフラストラクチャ リンクを提供するために使用されます。
この方式を使用すると、8192（213）個のインフラストラクチャ サブネットを割り当てる
ことができます。アドレス ブロックのさらに細かい細分化は、先に示したものと同じです。
地域を識別するために 4 ビットが使用され、地域内のサイトを識別するために 4 ビット
が使用され、さらにサイトごとに 4 ビットが使用されます。以前に割り当てた地域番号と
サイト番号を、インフラストラクチャ プレフィクスを選択する際に再利用できることに注意
してください。
アドレス計画
16
全体として見ると、このモデルでは、次に示すように、地域 1 のサイト 1 で 32 個のイ
ンフラストラクチャ プレフィクスを、エンド システムに 256 個のサブネットをそれぞれ使
用できます。
図 13 - インフラストラクチャ サブネットの割り当て
12 Bits for Network Infrastructure Subnets
地域 1 のサイト 1 のインフラストラクチャ プレフィクス
2001:db8:1:0000::/48
2001:db8:1:e110::/64 ∼ 2001:db8:1:e11f::/64
2001:db8:1:f110::/64 ∼ 2001:db8:1:f11f::/64
4 Bits for Site Subnets
地域 1 のサイト 1 のエンド システム プレフィクス
2001:db8:1:1100::/64 ∼ 2001:db8:1:11ff::/64
2176
4 Bits to Define Site Infrastructure Prefix
4 Bits to Define Regional Infrastructure Prefix
次の表は、2001:db8:1:e000:::/51 インフラストラクチャ プレフィクスがどのように地域
プレフィクスに細分化されるかを示しています。
表 5 - 地域インフラストラクチャ プレフィクスの細分化
地域（4 ビット）
地域インフラストラクチャ プレフィクス
地域 2
2001:db8:1:e400::/56 および 2001:db8:1:f400::/56
地域 3
2001:db8:1:e600::/56 および 2001:db8:1:f600::/56
地域 4
2001:db8:1:e800::/56 および 2001:db8:1:f800::/56
2001:db8:1:e100::/56 および 2001:db8:1:f100::/56
地域 1
2001:db8:1:e000::/52 ブロックと 2001:db8:1:f000::/52 ブロックの両方からインフ
ラストラクチャ プレフィクスが地域に割り当てられていることに注意してください。この割
り当てにより、地域ごとに 512 個のインフラストラクチャ プレフィクスを使用できます。
2001:db8:1:1100::/56 はサイトの集約プレフィクス
別の実装方法は、インフラストラクチャ リンクに /126 サブネットを使用することです。
この場合、/64 ブロックは、すべてのインフラストラクチャ リンクを割り当てるために使
用します。表 2 で作成した計画を再度使用します。2001:db8:1:ffff::/64 ブロックを、す
べてのインフラストラクチャ リンクを割り当てるために使用します。このブロック割り当て
を使用すると、ネットワーク インフラに使用されているサブネットとエンド システムに使
用されているサブネットが明確に識別されます。
同様の細分化を使用して地域とサイトを識別できます。地域を識別するために 4
ビットが使用され、地域内のサイトを識別するために 4 ビットが使用されます。
2001:db8:1:ffff:0::/80 プレフィクスは、ユニバーサル / ローカル ビットを使用する実装
で発生する可能性がある競合を回避するために使用されます。次の表は、地域インフラス
トラクチャ プレフィクスがどのように細分化されるかを示しています。
表 7 - 地域インフラストラクチャ プレフィクスの細分化
地域（4 ビット）
地域プレフィクス
次の表は、地域 1 内のサイトのさらに細かい細分化を示しています。
1
2001:db8:1:ffff:0:1000::/96
表 6 - 地域 1 内のサイトの細分化
2
2001:db8:1:ffff:0:2000::/96
3
2001:db8:1:ffff:0:3000::/96
4
2001:db8:1:ffff:0:4000::/96
サイト（4 ビット）
サイト インフラストラクチャ プレフィクス
サイト 2
2001:db8:1:e120::/60 および 2001:db8:1:f120::/60
サイト 3
2001:db8:1:e130::/60 および 2001:db8:1:f130::/60
サイト 4
2001:db8:1:e140::/60 および 2001:db8:1:f140::/60
サイト 1
2001:db8:1:e110::/60 および 2001:db8:1:f110::/60
August 2012 Series
アドレス計画
17
この割り当てモデルでは、各地域で 244 個のインフラストラクチャ サブネットを、地域
内の各サイトで 256 個のインフラストラクチャ サブネットをそれぞれ使用できます。次の
表は、地域 1 内のサイトの細分化を示しています。
表 8 - 地域 1 内のサイトの細分化
サイト（4 ビット）
地域プレフィクス
1
2001:db8:1:ffff:0:1100::/112
2
2001:db8:1:ffff:0:1200::/112
3
2001:db8:1:ffff:0:1300::/112
4
2001:db8:1:ffff:0:1400::/112
全体として見ると、このモデルでは、次に示すように、地域 1 のサイト 1 で 240 個のイ
ンフラストラクチャ プレフィクスを、エンド システムに 256 個のサブネットをそれぞれ使
用できます。
地域 1 のサイト 1 のインフラストラクチャ プレフィクス
2001:db8:1:ffff:0:1110::/127 ∼ 2001:db8:1:ffff:0:111f:ffff:fffe::/127
一部のインフラストラクチャ セグメントで 3 つ以上のアドレスが必要になる可能性がある
ことに注意してください。この場合は、連続する /127 ブロックを割り当てる必要があり
ます。
地域 1 のサイト 1 のエンド システム プレフィクス
2001:db8:1:1100::/64 ∼ 2001:db8:1:11ff::/64
2001:db8:1:1100::/56 はサイトの集約プレフィクス
この例では、/127 プレフィクスの細分化をインフラストラクチャ リンクに使用して、サブ
ネットあたり 2 つのアドレスのみを許可することにより、より多くのアドレスを節約するこ
とに焦点を当てています。この例はまた、この方式の管理および維持が、方式の計画およ
び実装の両面においてやや複雑であることを示しています。
ULA は、インフラストラクチャ リンクにアドレスを割り当てるための別のオプションです。
この方式では、ネットワーク インフラ プレフィクスをエンド システム プレフィクスとはまっ
たく異なる IPv6 アドレス ブロックから割り当てることにより、ネットワーク インフラ プ
レフィクスをエンド システム プレフィクスから完全に分離します。この戦略では、ネット
ワーク インフラのセキュリティもある程度確保できます。ULA には、インターネットから
到達できないようにする必要があります。こうすることにより、ネットワーク インフラが
外部の攻撃から保護されます。上の例では、ULA ネットワーク インフラ プレフィクスは
fd00:2001:db8::/48 にすることができます。このルートを選択する組織は、管理を容易
にするために /64 プレフィクスを実装する必要があります。グローバル ユニーク アドレス
をループバック インターフェイスに使用して、そのインターフェイスから応答を取得するこ
とにより、PMTUD がすべてのホストに対して確実に機能するようにすることも検討する
必要があります。この方法を使用すると、組織が実装する ULA フィルタリングの問題を
August 2012 Series
防ぐことができます。
ネットワーク インフラに関して説明する必要がある最後のオプションは、リンク ローカル
専用アドレスを使用する一方で、ネットワーク インフラのループバック インターフェイスに
グローバル アドレスを割り当てることです。このモデルでは、グローバル アドレスまたは
ULA アドレスはネットワーク インフラに割り当てられません。すべてのルーティング プロ
トコルでパケットの転送にリンク ローカル アドレスが使用されます。Simple Network
（SNMP）や Terminal Access Controller Access
（ TACACS）
Management Protocol
などのプロトコルは、グローバル アドレスが割り当てられるデバイスのループバック イン
ターフェイスから提供されます。このオプションを分析する際には、いくつかの潜在的な
欠点を考慮する必要があります。インフラストラクチャ インターフェイスに対して ping を
実行することができなくなります。これは、リンク ローカル アドレスがその特定のリンク
でしか意味を持たないためです。traceroute から出力インターフェイスが報告されなくな
ります。これは、返される ICMP パケットの送信元がループバック インターフェイスにな
るためです。このアプローチの利点と欠点の詳細については、IETF インターネット ドラフ
トを参照してください。http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00
アドレス指定計画の構築
IPv6 アドレス指定計画を作成するには、いくつかの方法があります。
• 既存の IPv4 ベースの計画を IPv6 に変換する
• トポロジ ベース
• 組織ベース
• サービス ベース
最初の方法では、既存の IPv4 サブネット方式の認識可能で一意の部分を IPv6 サブ
ネット方式に変換します。たとえば、/48 を顧客に割り当てます。これにより、顧客は
16 ビットを使用して内部ネットワークをサブネット化できます。顧客は、ネットワークへ
のアドレス指定に 10.0.0.0/8 ネットワークを使用しており、IPv6 アドレス ブロックに
2001:DB8:1::/48 を割り当てています。この場合、顧客は、IPv4 アドレスの 2 番目と
3 番目のオクテットを使用して IPv6 アドレスに変換することを選択できます。たとえば、
10.23.16.0/24 サブネットは 2001:DB8:1:1710::/64 に変換されます。図 14 に、この
プロセスを示します。この方式は、IPv4 サブネット方式で一般的な可変長サブネット マ
スクを使用するため、実装が困難です。
アドレス計画
18
図 14 - IPv4 サブネットの IPv6 サブネットへの変換
Customer IPv4 Network
10.0.0.0/8
Customer IPv6 Network
2001:db8:1::/48
Customer IPv4 Network
10.23.16.0/24
Use the 2nd and 3rd Octets for IPv6 Subnet
Do the Decimal to Hexadecimal Conversion
23
0x17
16
0x10
2177
Substitute Conversion Results to Get IPv6 Subnet
2001:db8:1:1710::/64
既存の IPv4 アドレスを IPv6 サブネットにマップしようとする際には、留意すべき問題が
あります。この問題は、既存の /30 サブネットをポイントツーポイント インフラストラク
チャ用の /127 サブネットにマップしようとするときに発生します。
図 15 - 既存の /30 サブネットの /127 サブネットへの変換
Customer IPv4 Network
10.0.0.0/8
次の方法では、ネットワークのトポロジ制約内のすべてのロケーションにアドレス ブロック
を割り当てます。たとえば、ある顧客はプロバイダーから 2001:db8:1::/48 プレフィクス
を割り当てられています。この顧客は国全体にわたってサイトを保有しており、これらのサ
イトは地理的位置（北西、北東、南西、および南東）に基づいて 4 つの地域にトポロジ
的に細分化されます。サブネットの 16 ビットのうちの最初の 4 ビットを、地域の特定に
使用できます。この方式を使用することで、ネットワークには 16 の地域が存在するよう
になり、各地域には 4096（212）の /64 サブネットが存在するようになりました。この
方式をさらに推進すると、地域内の施設を特定するために次の 4 ビットを使用できる施
設レベルに達することができます。これにより、1 地域ごとに 16 のサイト（24）を割り
当てることが可能になり、各サイトは 256（28）の /64 サブネットを所有することができ
ます。この例は前に、本書の「サブネット計画」のセクションで示しました。
次の方法では、会社または組織内の部門上の境界に基づいて、プレフィクスの割り当てが
行われます。この場合、エンジニアリング部門、販売部門、法務部門など、各部門はそ
れぞれ異なるアドレス ブロックを受け取ります。この方法の潜在的な問題は、効率的な
集約方式が推進されないということです。組織内のほとんどの部門は通常、複数のサイト
に配置されています。こうした組織上の分散が原因で、この方式はトポロジーの細分化と
組み合わせて使用される可能性が高くなります。
最後の方法は、Voice over IP（ VoIP）、ワイヤレス サービスなど、提供されるサービス
のタイプに基づいて、プレフィクスを割り当てる方法です。この方法には、組織的な方式
と同じ集約の問題があり、やはりトポロジーの細分化と組み合わせて使用される可能性が
高くなります。
Customer IPv6
Network Infrastructure
2001:db8:1:ffff:/64
Customer IPv4 Network
10.10.10.4/30
この最後の 2 つの方法は、デバイスまたはサブネットの機能に関する情報をアドレス自体
に埋め込むテンプレート化アドレス指定という、より広範なカテゴリに分類できます。この
アプローチを使用すると、集約能力が低下しますが、運用が簡単になる可能性があります。
2178
Use the 1st, 2nd, and 3rd Octets for IPv6 Subnet
Do the Decimal to Hexadecimal Conversion
10
0x0a
4
0x04
Substitute Conversion Results to Get IPv6 Subnet
2001:db8:1:ffff:a:a:a:4/127
できないことを思い出してください。そのため、2001:db8:1:ffff:a:a:a:4/127 には、
2001:db8:1:ffff:a:a:a:4 と 2001:db8:1:ffff:a:a:a:5 がそのプレフィクスのエンド シス
テム アドレスとして割り当てられます。プレフィクスの細分化にこのモデルを使用すること
を検討する際には、このプレフィクスの重複の問題を頭に入れておいてください。既存の
IPv4 アドレス計画と IPv6 アドレス計画を混同しないようにしてください。
上の例では、顧客はプロバイダーから 2001:db8:1::/48 というサブネットを受け取ります。
この場合も、地域を特定する最初の 4 つのサブネット ビットと、サイトを特定する次の
4 ビットを使用できます。ここでは、サブネットの機能 / サービスを特定する次の 4 ビッ
トを使用することが選択されました。最後の 4 ビットは、対象機能内の異なるサブネット
になります。新しい細分化は、次のようになります。
IPv4 ネットワークでは、デバイスは 10.10.10.5 と 10.10.10.6 を使用してイ
ンターフェイスを識別します。上記の変換方法を使用すると、IPv6 アドレスは
2001:db8:1:ffff:a:a:a:5 と 2001:db8:1:ffff:a:a:a:6 になります。ここでの問題は、
2001:db8:1:ffff:a:a:a:5 と 2001:db8:1:ffff:a:a:a:6 が別々のサブネットに存在す
ることです。/127 は、IPv4 の /31 プレフィクスと同様に、2 つのアドレスしか収容
August 2012 Series
アドレス計画
19
サブネット計画を構築するための推奨事項
• エンド システム / ホストが接続されたセグメントには /64 サブネットだけを使用しま
図 16 - サブネットの細分化
す。
16 Bits for Organizational Subnets
• ループバックには /128 サブネットを使用します。
2001:db8:1:0000::/48
• ネットワーク インフラには /64 、/126 または /127 サブネットを使用します。
◦
3 つ以上のアドレスが必要なネットワーク インフラ セグメント（ /124 など）に
◦
はじめはパイロット プロジェクト用の /64 プレフィクスと初期実装を使用して、
サブネット計画をシンプルに維持します。より詳細なサブネット アドレス計画に
段階的に移行します。
4 Bits for Subnet Prefix
4 Bits for Subnet Function
4 Bits to Define Regional Prefix
2175
4 Bits to Define Site Prefix
サブネットの機能 / サービスを特定するには、次の表を使用します。
表 9 - サブネットの機能とサービス ID
対応するように計画を立てます。
• ネットワーク トポロジーと自然な集約ポイントを利用して、プレフィクス情報を集約し
ます。
◦
集約境界内の組織とサービスベースの割り当てを考慮します。場合によっては、
運用を簡略化するため、厳密な集約化を一部断念します。
• 拡張用に、計画にギャップを残します。外部接続を必要としないネットワーク デバイ
ス（プリンタなど）に対して、 ULA の使用を検討します。
機能 /サービス
予約済み
ID
0
ワークステーション
1
予約済み
2
音声
4
予約済み
5
ワイヤレス
6
予約済み
7
• 手動
サーバ
8
予約済み
• ステートレス
9
パートナー
• プライバシー拡張
a
予約済み
• セキュア ネイバー探索 / 暗号化生成アドレス（SEND/CGA ）
b
予約済み
• DHCP
c
予約済み
d
予約済み
e
予約済み
f
このモデルの使用時に、2001:db8:1:1181:227:13ff:fe68:854 というアドレスが提供さ
れた場合、運用チームは地域 1 のサイト 1 で問題が発生した可能性があることを認識す
るでしょう。
August 2012 Series
• ネットワーク インフラでの、リンク ローカル アドレスの使用ステータスを追跡します。
インターフェイス ID の割り当て
アドレス指定計画を作成する場合に検討しなければならないもう 1 つの項目は、エンド
ステーションやネットワーク インフラに対してインターフェイス ID を割り当てる方法です。
前述のように、インターフェイス ID をエンド ホストに割り当てる場合、複数のオプション
が使用できます。
エンド ステーションでアドレスを手動設定するということは、各ネットワーク ノードを訪
問して、そのノードのインターフェイス ID を設定するということです。この点を考慮して、
ネットワーク インフラ デバイスと主要ネットワーク サーバ（DNS サーバ、DHCP サーバ、
データベース サーバ、Web サーバなど）に対して、手動アドレス割り当てを予約してく
ださい。アドレスを手動で割り当てる場合、検討しなければならない考慮事項がいくつか
あります。懸念事項については、本書の「サブネット計画：最初のアドレス ブロック要求」
セクションで説明したものと同じで、ルータ サブネット エニーキャスト アドレス、IPv6
サブネット エニーキャスト アドレス、埋め込み型 RP アドレス指定、および ISATAP ア
ドレス指定をサポートする「u」ビットと「g 」ビットなどです。
アドレス計画
20
アドレスを手動で割り当てる場合、疑似ランダム プロセスを使用して、アドレスの
インターフェイス ID 部分を生成することを推奨します。Stateless Address Auto
Configuration（SLAAC）は、ノードまたはデバイスがアドレスを自分自身に自動で割り
当てる方法です。このプロセスでは、ノードは、セグメント上のルータによって送信された
特定のメッセージをリッスンします。ルータがアドバタイズしているサブネット プレフィク
ス情報をノードで取得して、インターフェイス ID を設定します。 SLAAC モデルでは、エ
ンド ノードがインターフェイス ID を自動設定するために使用できる共通プロセスが 3 つ
あります。
• EUI-64 プロセス
• プライバシー拡張
• セキュア ネイバー探索 / 暗号化生成アドレス（SEND/CGA ）
EUI-64 は MAC アドレスを使用して、インターフェイス ID を生成します。インターフェ
イス ID には 64 ビットが必要ですが、MAC アドレスは 48 ビットしかないため、MAC
アドレスを拡張する方法が必要です。この拡張に対応するため、MAC アドレスを半分に
分割し、FFFE を挿入します。このプロセスの最後の部分は、ユニバーサル / ローカル ビッ
トを設定することです。ユニバーサル / ローカル ビットは、アドレスがユニバーサルで管
理されるか、ローカルで管理されるかを特定するために使用されます。このビットは第 1
オクテットの第 7 ビットです。図 17 は EUI-64 プロセスを示しています。
RFC 5342 はこのプロセスを記述するもので、FFFE が選択された理由が説明されてい
ます。
図 17 - EUI-64 プロセス
00
00
00
90
90
27
90
27
27
FF
FE
FF
FE
Where u =
000000u0
u=1
02
90
17
27
FF
{
FE
FC
0F
17
FC
0F
17
FC
0F
1 = Unique
0 = Not Unique
17
FC
0F
2179
インターフェイス ID を手動で割り当てる場合、簡単に推測できるアドレス（DEADBEEF、
CAFE、C0FFEE など）を避けることは、セキュリティ面で推奨される方法で、ハッカー
がネットワークをスキャンしても簡単にホストを検出できなくなります。アドレスを公開す
る必要があるホストに対しては、この推奨事項が当てはまらない場合がまれにあります。
アドレスを公開する必要があるホストの場合、外部ホストと通信できるように、 DNS は
アドレス情報を配信します。ただし、このようにアドレスが公開されているサーバに対して
も、簡単に推測できないアドレスを使用しないようにすることを推奨します。
重大な情報は、SLAAC プロセス（DNS サーバ）を使用して配信されません。アドレス
サイズが拡張されたため、IPv6 の全体的な運用において、DNS の重要性がさらに高まり
ます。RFC 6106
（IPv6 Router Advertisement Options for DNS Configuration）は、
ルータがルータ アドバタイズメントを介して DNS サーバ情報を配信するためのオプショ
ンを指定します。このオプションは広くサポートされているわけではありません。この機能
には 2 つの部分があるという点にも留意してください。オプションをアドバタイズするルー
タ内のサポートと、オプションを受信するホスト / サーバ内のサポートです。
SLAAC のもう 1 つの潜在的な欠点は、アドレス管理を一元的に行うメカニズムがない
ということです。機器を追加しなければ、IPv6 アドレスに基づいて、デバイスをトラックバッ
クすることは複雑になります。SLAAC は、モバイル環境、
「単純な」デバイス（センサー
など）が接続されているネットワーク セグメント、多数のクライアントが短い期間内で接
続される環境、DHCP の一元管理モデルが受け入れられない環境などで役に立ちます。
EUI-64 プロセスはレイヤ 3 インターフェイス ID へのレイヤ 2 MAC アドレスのマッピン
グに基づいているため、プライバシーに関する懸念が生じました。このような懸念が生じ
たのは、変更されることがないインターフェイス ID に基づいて、デバイスをトラッキング
することができるためです。プライバシーの懸念に対処するため、IETF は疑似ランダムの
インターフェイス ID を自動生成するプライバシー拡張を RFC 4941 で定義しました。
プライバシー拡張は、エンド ホストにアドレスを自動的に割り当てるもう 1 つの方法です。
このプロセスを使用して、エンド ホストは、指定されたタイム フレームで使用される、疑
似ランダムのインターフェイス ID を生成します。この時間が経過すると、ホストは通信用
に使用される別のアドレスを生成し、以降、この処理が繰り返されます。プライバシー拡
張によって RFC 4941 に記載された懸念は解消しますが、ネットワークの運用スタッフに
管理面の負担がかかります。トラブルシューティング、アカウンティング、許可、アクセス
などのプロセスと手順は、エンド ステーションのアドレスの変更に対応するように開発す
る必要があります。
August 2012 Series
アドレス計画
21
プライバシー拡張を検討する際、組織のネットワークの外側に配置されたエンド システ
ムに対して外部通信を発信する（インターネットなど）場合にプライバシー拡張を使用し、
内部通信には非プライバシーとして割り当てられたアドレスを使用することを推奨します。
図 12 は、こうした通信がどのように行われるかを示しています。サイト 1 とサイト 2 の
間の通信では、永続的に割り当てられたアドレスが使用され、組織外の通信では、一時
アドレスが使用されます。
パブリック アドレスの目的は、有効期間の長いアドレスを設定することです。
図 19 - Wi ndows 7 の IPv6 アドレス
図 18 - プライバシー拡張の例
2001:db8:1:1::3
2001:db8:1:1:7124:eb33:a6d2:1dd8
2001:db8:1:2::21
fd02:2:2:2:89d1:497a:ca56:b8e4
Site 1
Site 2
Corporate
Backbone
2001:db8:3:1::3
2180
Internet Connection
図 19 は、Windows 7 のマシンからキャプチャしたスクリーンを示しています。インター
フェイスには、グローバルに一意なアドレスが 3 つ割り当てられている点に注意してくだ
さい。最初のアドレスは手動で割り当てられ、 2 番目のアドレスは、プライバシー拡張が
使用されていることを示しています。このアドレスの有効期間が切れると、新しいインター
フェイス ID が生成されます。割り当てられる 3 番目のアドレスは、有効期間が長いパブ
リック アドレスです。Windows 7 に対する Microsoft のデフォルトの動作は、インター
フェイス ID として使用するために、ランダムな数値を生成することです。この選択肢は、
パブリック アドレスが EUI-64 プロセスに準拠していない箇所の下で確認できます。ま
た、このアドレスの有効期間は一時アドレスと比べてはるかに長いことを確認してください。
August 2012 Series
この一時アドレスを使用するには、ソース アドレス選択のデフォルト動作を無効にする必
要があります。RFC 3484 では、パブリック アドレスが一時アドレスよりも優先されると
規定されています。RFC の規定によると、アプリケーションはこの動作を無効にするメカ
ニズムを提供する必要があります。このようにプライバシー拡張を使用する場合は、この
点に注意する必要があります。プライバシー拡張に関するもう 1 つの推奨事項は、新しい
アドレスを生成するタイム フレームを「合理的な」期間に維持するということです。
「合理
的な」期間とはアドレス計画を構築する組織にとって相対的なものであり、組織がプライバ
シーをどの程度重視するかによって異なります。RFC で推奨されているアドレスの変更期
間は、1 日です。これはほとんどの組織の要件を満たしています。
アドレス計画
22
全期間を通して、すべてのオペレーティング システムが同じ一時アドレスを維持するとは
限りません。たとえば、iPhone や iPad デバイスはワイヤレス ネットワークに再接続さ
れると、新しい一時アドレスを生成することが多いため、IPv6 アドレスの有効期間は大幅
に短縮される可能性があります。この特性が原因で、ネットワーク内のさまざまな機能の
設計および設定が影響を受ける可能性があります。
このプロセス全体の目的は、セグメント上のネイバーが申告通りの人物であることを確認
し、ネイバー探索プロセスに一定レベルのセキュリティを提供することです。SEND/CGA
は、完全なソリューションを実現するために 2 つの部分で構成されているもう 1 つの機
能です。この機能では、このようなアドレス タイプをサポートするルータとホスト / サー
バの両方が必要です。
インターフェイス ID を動的に生成するもう 1 つの方法が SEND/CGA です。これは
RFC 3756（IPv6 Neighbor Discovery (ND) Trust Models and Threats）に規定さ
れているネイバー探索プロセスを使用して、アドレスのセキュリティ面の懸念に対処するた
めに開発されました。SEND/CGA プロセスの背後にある主要な概念は、公開 / 秘密キー
と証明書を使用して、ネイバー探索プロセスに関連付けられているすべての機器の ID を
検証することです。CGA は、レイヤ 3 アドレス スプーフィングに対する適切な保護を提
供する、軽量メカニズムです。 SEND は、ルータ スプーフィングに対する適切な保護を
提供する、PKI ベースのメカニズムです。この 2 つを組み合わせて使用することで、RFC
3756 に記載されている脅威が軽減されます。
SEND/CGA の導入を制限する要因は、オペレーティング システムのサポートです。
SEND/CGA のワークステーションへの導入は現在、ほとんどの Linux システムに限定
されています。Cisco IOS を搭載したシスコ製品を含め、ほとんどのエンド システムと
ネットワーク インフラ ベンダーに対して、SEND/CGA のサポートが現在進行していま
す。SEND と CGA に対するサポートがないため、このアドレス指定方法の導入が制限
図 20 は、動作中の CGA プロセスを示しています。RFC 3972 では、次のように規定
されています。
基本的な概念は、公開キーの暗号化ハッシュを計算することで、IPv6 アドレ
スのインターフェイス ID（つまり右端の 64 ビット）を生成することです。
図 20 に示すように、CGA プロセスでは公開キーと他のパラメータを使用して、インター
フェイス ID として使用される暗号化ハッシュを生成します。するとデバイスは、秘密キー
を使用して、そのアドレスから送信されたメッセージに署名することができます。他のデバ
イスでは、公開キーを使用してアドレスを検証できます。
図 20 - 暗号化を使用して生成されたアドレス プロセス
Private
Public
Signature
Subnet
Prefix
CGA Params
Send Messages
• ステートフル：このモードでは、DHCPv6 の動作は DHCPv4 とまったく同じです。
アドレスを提供して、セグメントでのアドレスの使用状況を追跡します。ネットワーク
オペレータは、アドレスの場所や使用されているアドレスを追跡できます。
• ステーレス：このモードでは DHCPv6 は主に DNS サーバやドメイン名情報などを
提供するために使用されます。この情報は、前述の SLAAC プロセスの実行中に検
出された情報を補完するために使用されます。ステートレス モデルでは、DHCPv6
RFC 5157 には、アドレスの割り当てに関する推奨事項や、サブネット スキャンの関連
事項があります。インターフェイス ID を割り当てる際の、全体的な推奨事項を次に示しま
す。
Modifier
(nonce)
Public
Key
DHCP も IPv6 をサポートするように拡張されました。DHCPv6 を使用すると、ネット
ワーク管理者はインターフェイスのアドレス指定の処理をより詳細に管理することができる
ようになり、 DHCP から学んだ教訓と特定の新機能（DHCP プレフィクス委任など）に
基づいて、SEND と CGA の両方の機能向上に対応することができます。DHCPv6 は、
次の 2 つの状態で動作可能です。
サーバはアドレス情報を提供しないため、アドレス リースやエンド ノード ステータス
の追跡などの状態を維持する必要がありません。
SHA-1
• 可能な限り、SEND/CGA を使用してください。
Subnet
Prefix
• ネットワーク インフラと主要なネットワーク サーバには、インターフェイス ID を手動
Interface
Identifier
Cryptographically Generated
17
Address (CGA)
で割り当ててください。
2181
RSA Keys
されています。これらの機能に対するサポートを組み込んだデバイスは増加しているため、
SEND と CGA を使用することを推奨します。
• ユーザ アカウンティングとトラッキングが重要な懸念事項である場合は、DHCPv6
を使用してください。
• ステートレス自動設定を使用する場合は、ステートレス DHCPv6 を使用して、DNS
サーバなどの重要な情報を提供してください。
• 簡単に推測可能なインターフェイス ID は使用しないでください。
August 2012 Series
アドレス計画
23
IP Address Management（IPAM）
図 21 - 企業 XYZ のバックボーン トポロジー
アドレス空間が 32 ビットから 128 ビットに拡張されたため、IPv6 アドレスの数と IPv6
プレフィクスの数が大幅に増加しました。スプレッドシートを使用してアドレス計画の管理
と保守を便利に行う時代は過ぎました。IPv6 の広大なスケールの実装を IPAM ツールに
対応させる必要があります。このツールを使用すると、IPv6 アドレス空間の管理と保守を
行うことができるだけでなく、 DNS および DHCP サービスの管理を統合することもでき
ます。
2182
DNS は、世界中のネットワーキング機器の位置を特定してアドレス指定するため、これ
らすべてのデバイスのドメイン名を数字 ID に変換します。ドメイン名を使用すると、物理
的位置にかかわらず、インターネット リソースやユーザ情報を一貫性のあるものにするこ
とができます。アドレス空間が拡張されたため、今後 DNS はさらに重要なサービスにな
るでしょう。2001:db8:ef46:12da:bcde:4987:c:15c0 というアドレスを覚えたいという
ユーザやネットワーク オペレータがいるでしょうか。DNS サービスが高速で信頼性が高
く、安全でなければ、利用者のブロードバンド インターネット アクセスに問題が生じます。
DHCP は、IP ネットワークで使用される自動設定プロトコルです。DHCP を使用すると、
コンピュータの自動設定が可能になり、ネットワークに接続されているコンピュータをト
ラッキングできるようにデータベースの保守が実行されます。このため、2 台のコンピュー
タに誤って同じ IP アドレスが設定されることはありません。DHCP を使用しない場合、
すべてのデバイスに一意のアドレスを手動で割り当てなければなりませんが、これは現在
では、ほとんど実行不可能なタスクです。機動性の高いモバイル ユーザや、統合型の第
3 および第 4 世代（3G/4G）ネットワークの登場、エンド ユーザのネットワーク対応デバ
イスの増加に伴い、大容量の DHCP サーバは必要不可欠な存在になりました。
IPv6 アドレス計画のケース スタディ
このセクションでは、架空の会社がどのように IPv6 アドレス計画を作成するかについて
説明します。企業 XYZ はサンフランシスコに本社を置く多国籍企業で、地域統括本部は
ドバイ、ヨハネスブルク、香港、シドニー、東京、ブダペスト、パリ、ブエノスアイレス、
メキシコシティ、アトランタ、モントリオールにあります。図 21 は、上記の地域統括本部
サイト間の接続を示しています。
August 2012 Series
これらの地域統括本部サイトは、最大 100 ヵ所のリモート オフィスを統括しています。
この企業の主要データセンターは、サンフランシスコの本社に共同設置されています。バッ
クアップ データセンターはアトランタに置かれています。インターネット接続は、3 つの
異なるサービス プロバイダーを介して、サンフランシスコ、アトランタ、パリのサイトを経
由して提供されます。
マルチホーミングと、3 つの異なる IPv6 アドレス ブロックを管理する複雑さという潜在
的な問題に対処するため、XYZ 社は、プロバイダーに依存しないブロックを ARIN に要
求することを決定しました。XYZ 社は ARIN によって規定された要件を満たしていたた
め、ネットワーク内のサイトの数に基づいて、同社には 2001:db8:1000:/36 というブロッ
クが割り当てられ、使用できるようになりました。XYZ 社は、同社の IPv6 プレフィクス
のアナウンスに関してサービス プロバイダーと契約を締結した後、RIPE や他の登録機関
にアプローチしてアドレス空間を求めることはしませんでした。ただし、同社が受け付ける
最長プレフィクスは /48 であることを、サービス プロバイダーから明示的に通知されまし
た。
アドレス計画
24
XYZ 社はサイトが置かれている地域に基づいてプレフィクスを割り当てることを決定し、5
つの地域（北米、南米、ヨーロッパ、アフリカ、アジア）を定義しました。最初の 3 つのビッ
トは、地域の特定のために使用することにしました。1 つのブロックがアジアと北米間で
予約された点に注意してください。この 2 つの市場は、最大規模の成長が予想されてい
る市場です。予約されたブロックのおかげで、2 つの地域は必要に応じて、この空間へ拡
大することができます。他のシアターの増加用に、他に 2 つのブロックが予約されていま
す。表 10 に、ARIN から受け取ったプレフィクス ブロックの詳細な細分化を示します。
表 10 - 企業 XYZ のプレフィクス ブロックの細分化
表 11 - プレフィクスの再分割
サイト
プレフィクス
予約済み
2001:db8:1200::/44
サンフランシスコ
2001:db8:1210::/44
予約済み（サンフランシスコ）
2001:db8:1220::/44
サンフランシスコ データセンター
2001:db8:1230::/44
予約済み
プレフィクス
予約済み（サンフランシスコ データセン 2001:db8:1240::/44
ター）
2001:db8:1000::/39
2001:db8:1250::/44
北米
アトランタ
2001:db8:1200::/39
予約済み（アトランタ）
2001:db8:1260::/44
予約済み
2001:db8:1400::/39
アトランタ データセンター
2001:db8:1270::/44
アジア
2001:db8:1600::/39
ラテン アメリカ
予約済み（アトランタ データセンター） 2001:db8:1280::/44
2001:db8:1800::/39
モントリオール
2001:db8:1290::/44
アフリカ
2001:db8:1a00::/39
2001:db8:12a0::/44
ヨーロッパ
予約済み（モントリオール）
2001:db8:1c00::/39
2001:db8:12b0::/44
予約済み
メキシコシティ
2001:db8:1e00::/39
予約済み（メキシコシティ）
2001:db8:12c0::/44
予約済み
2001:db8:12d0::/44
地域（3 ビット）
次のステップは、各地域の計画を作成することです。北米地域をサンプルとして使用し、
作成された計画を他の地域に適用することができます。
地域的な計画の場合、次の 5 ビットは地域統括本部と主要施設（データセンター、大規
模なユーザ ロケーションなど）の特定に使用されます。この決定では、このような特定
対象の施設を 32 ヵ所考慮することができます。このようなロケーションごとに、/44 プ
レフィクスからサブネットを割り当てることができます。表 11 の細分化は、北米の /39
プレフィクスをさらに /44 プレフィクスに再分割する方法を示しています。
この方式では 2001:db8:12d0::/40 ∼ 2001:db8:13f0::/44 のプレフィクスが未割り当
てで、将来使用することができます。これらのブロックは、サイトに割り当てられた /52
プレフィクスより多くのプレフィクスを使用することが予想される大規模サイトで使用でき
ます。
/52 ブロックは、各地域統括本部サイトと地域統括本部に接続されているリモート ロケー
ションに割り当てられます。地域統括本部に接続された各サイトに /52 を使用すると、そ
の地域のハブに 256 のサイトを接続することができます。/52 プレフィクスにより、各ロ
ケーションに 4096 の /64 サブネットが提供されます。次の表は、サンフランシスコ地
域のハブに接続されているいくつかのサイトの細分化を示しています。
August 2012 Series
アドレス計画
25
表 12 - サンフランシスコ地域のハブに接続されているサイトの細分化
サイト
プレフィクス
表 13 - サブネットの機能とサービスの特定
予約済み
機能 /サービス
2001:db8:1210::/52
予約済み
ID
0
サンフランシスコ本社
2001:db8:1210:1000::/52
ワークステーション
1
予約済み
2001:db8:1210:2000::/52
DMZ
2
ロサンゼルス
2001:db8:1210:3000::/52
音声
3
フェニックス
2001:db8:1210:4000::/52
ラボ
4
ラスベガス
2001:db8:1210:5000::/52
ワイヤレス
5
シアトル
2001:db8:1210:5000::/52
サーバ
6
デンバー
2001:db8:1210:6000::/52
ゲスト アクセス
7
シカゴ
2001:db8:1210:7000::/52
予約済み
8
予約済み
9
予約済み
a
予約済み
b
予約済み
c
予約済み
d
予約済み
e
予約済み
f
地域のサイトがサポート可能なサブネット数を把握するには、サンフランシスコ地域の
ハブに接続されているサイトの /52 サブネットの総範囲が 2001:db8:1210::/52 ∼
2001:db8:121f:f000::/52 であることを理解する必要があります。
次のステップは、施設ごとにプレフィクス ブロックを細分化することです。最初の 4 ビッ
トはそのサイト内でサブネットが配置されている建物またはフロアを特定するために使用
されます。次の 4 ビットはサブネットの機能を特定します。次の表は、さまざまな機能を
示しています。この表は地域をまたいで使用されるという点に注意してください。
この方式では、各サイトで最大 16 の建物またはフロアをサポートできます。各建物また
はフロア内で、サービスごとに最大 16 のサブネットをサポートできます。サブネット計画
の全体的な管理を簡単にするため、すべての施設で /64 サブネットを使用します。表 14
に、施設の細分化を示します。
August 2012 Series
アドレス計画
26
表 14 - サンフランシスコ地域統括本部サイトの建物 1 の細分化
建物（4 ビット）
サービス（4 ビッ
ト）
ユーザ/サービスのサブネット（4 ビッ
ト）
0001
予約済み
̶
ワークステーション
2001:db8:1210:1110:./64 to
2001:db8:1210:111f::/64
̶
DMZ
2001:db8:1210:1120:./64 to
2001:db8:1210:112f::/64
̶
音声
2001:db8:1210:1130:./64 to
2001:db8:1210:113f::/64
2001:db8:1210:1100:./64 to
2001:db8:1210:110f::/64
̶
ラボ
2001:db8:1210:1140:./64 to
2001:db8:1210:114f::/64
̶
ワイヤレス
2001:db8:1210:1150:./64 to
2001:db8:1210:115f::/64
̶
サーバ
2001:db8:1210:1160:./64 to
2001:db8:1210:116f::/64
̶
ゲスト アクセス
2001:db8:1210:1170:./64 to
2001:db8:1210:117f::/64
インフラストラクチャ プレフィクスの場合、ポイントツーポイント リンクには /127 プレフィ
クスが使用され、3 つ以上のアドレスを必要とするインフラストラクチャに対しては /112
が使用されます。/128 プレフィクスはループバック アドレスに対して割り当てられます。
予約済みの 2001:db8:1e00::/39 ∼ 2001:db8:1fff:ffff::/64 プレフィクスは、インフラ
ストラクチャ アドレスを割り当てるために使用されます。 2001:db8:1fff:ffff:0::/80 は、
ユニバーサル / ローカル ビットとの競合を避けるため、予約されます。/80 以降の最初の
3 ビットは、地域インフラストラクチャ プレフィクスを特定するために使用されます。こ
の選択は、ユーザのプレフィクス割り当てモデルの細分化に従って行われます。表 15 に、
地域インフラストラクチャ プレフィクスの細分化を示します。
表 15 - 地域インフラストラクチャ プレフィクスの細分化
地域（3 ビット）
予約済み
インフラストラクチャ プレフィクス
2001:db8:1fff:ffff:0::/83
北米
2001:db8:1fff:ffff:0:2000::/83
予約済み
2001:db8:1fff:ffff:0:4000::/83
アジア
2001:db8:1fff:ffff:0:6000::/83
ラテン アメリカ
2001:db8:1fff:ffff:0:8000::/83
アフリカ
2001:db8:1fff:ffff:0:a000::/83
ヨーロッパ
2001:db8:1fff:ffff:0:c000::/83
予約済み
2001:db8:1fff:ffff:0:e000::/83
次の表では、北米のインフラストラクチャ プレフィクスをさらに細分化します。
表 16 - 北米インフラストラクチャ プレフィクスの詳細な細分化
機能
プレフィクス
ポイントツーポイント セグメント
2001:db8:1fff:ffff:0:2000::/96
マルチアクセス セグメント
2001:db8:1fff:ffff:0:2e00::/96
Loopback
2001:db8:1fff:ffff:0:2f00::/96
識別対象の特定のサイトを考慮して、この方式をさらに細分化することができます。次の
表は、サンフランシスコ サイトのインフラストラクチャで行われる可能性がある細分化方
法を示しています。
表 17 - サンフランシスコ サイト インフラストラクチャの詳細な細分化
機能
プレフィクス
ポイントツーポイント セグメン
ト
2001:db8:1fff:ffff:0:2000:1000::/100
マルチアクセス セグメント
2001:db8:1fff:ffff:0:2e00:1000::/100
Loopback
2001:db8:1fff:ffff:0:2f00:1000::/100
この方式では、サイトあたり 217 のポイントツーポイント サブネット、212 のマルチアク
セス サブネット、および 218 のネットワーク インフラ デバイスに対応できます。
August 2012 Series
アドレス計画
27
エンド システムに対して個々のアドレスを割り当てる場合、XYZ 社は DHCPv6 を使用し
て、ユーザ マシンにインターフェイス ID を割り当てます。DHCPv6 をサポートする機能
を持たないデバイスは SLAAC を使用します。SLAAC が使用されるため、ネットワーク
接続されているユーザを特定するために使用されるプロセスと手順は、これらのデバイス
に対応するように修正する必要があります。これらのデバイスを DHCPv6 をサポートす
るオペレーティング システムにアップグレードするための改善計画が作成される予定です。
主要サーバとすべてのネットワーク インフラは、手動で割り当てられたインターフェイス
ID を使用します。ネットワークではプラバシー拡張を使用しません。CGA/SEND 実装
が使用可能になるため、SEND/CGA を使用して、ネットワークの全体的なセキュリティ
を強化します。 XYZ 社はネットワーク ベンダーとエンド システム ベンダーの両方と協力
して、この機能を XYZ 社のネットワークで使用されている製品に統合します。
この例では、/36 の初期ブロック サイズを使用している例を示しました。ここに示されて
いる概念は、/40、/44 、/48 など、より長い初期割り当てに使用することもできます。初
期プレフィクス割り当てが要求したものより長い場合、使用可能なビット数は少なくなりま
す。大事なことは、割り当てに合わせて、計画を適合させるということです。
一例として、前述の例の初期割り当てが /40 に対するものだった場合、同じ細分化を使
用できます。ただしこの場合、より小さな空間に対して、予約済みブロックの使用が増加
します。次の表は、 2001:db8:1100::/40 に対して地域の細分化がどのようになるかを示
しています。3 つのビットが以前と同じように、地域を特定するために使用されます。
表 18 - 2001:db8:1100::/40 に対する地域の細分化
地域（3 ビット）
プレフィクス
予約済み
2001:db8:1100::/43
北米
2001:db8:1120::/43
予約済み
2001:db8:1140::/43
アジア
2001:db8:1160::/43
ラテン アメリカ
2001:db8:1180::/43
アフリカ
2001:db8:11a0::/43
ヨーロッパ
2001:db8:11c0::/43
予約済み
2001:db8:11d0::/43
August 2012 Series
アドレス計画
28
地域内の主要サイトの場合はこれまでと同様、5 ビットをそのサイトの特定に使用できます。
表 19 - 地域内の主要サイト
地域ビット
主要サイト ビット
（3 ビット） （5 ビット）
サイト
001
00000
予約済み
プレフィクス
2001:db8:1120::/48
̶
00001
サンフランシスコ
2001:db8:1121::/48
̶
00010
予約済み
（サンフランシスコ）
2001:db8:1122::/48
̶
00011
予約済み
（サンフランシスコ）
2001:db8:1123::/48
̶
00100
予約済み
（サンフランシスコ）
2001:db8:1124::/48
̶
00101
予約済み
（サンフランシスコ）
2001:db8:1125::/48
̶
00110
̶
00111
サンフランシスコ デー
タセンター
2001:db8:1126::/48
予約済み
2001:db8:1127::/48
（サンフランシスコ デー
タセンター）
̶
01000
̶
01001
アトランタ
2001:db8:1129::/48
̶
01010
予約済み（アトランタ）
2001:db8:112a::/48
̶
01011
予約済み（アトランタ）
2001:db8:112b::/48
̶
01100
予約済み（アトランタ）
2001:db8:112c::/48
̶
01101
予約済み（アトランタ）
2001:db8:112d::/48
̶
01110
アトランタ データセン
ター
2001:db8:112e::/48
̶
01111
予約済み
2001:db8:112f::/48
（アトランタ データセン
ター）
̶
10000
予約済み
2001:db8:1130::/48
（アトランタ データセン
ター）
̶
10001
August 2012 Series
予約済み
2001:db8:1128::/48
（サンフランシスコ デー
タセンター）
モントリオール
̶
10010
予約済み（モントリオー
ル）
2001:db8:1132::/48
̶
10011
予約済み（モントリオー
ル）
2001:db8:1133::/48
̶
10100
メキシコシティ
2001:db8:1134::/48
̶
10101
予約済み
（メキシコシティ）
2001:db8:1135::/48
̶
10110
予約済み
（メキシコシティ）
2001:db8:1136::/48
̶
10111
予約済み
2001:db8:1137::/48
̶
11000
予約済み
2001:db8:1138::/48
̶
11001
予約済み
2001:db8:1139::/48
11010
予約済み
2001:db8:113a::/48
11011
予約済み
2001:db8:113b::/48
11100
予約済み
2001:db8:113c::/48
11101
予約済み
2001:db8:113d::/48
11110
予約済み
2001:db8:113e::/48
11111
予約済み
2001:db8:113f::/48
この計画の大きな違いは、地域のハブに接続されているサイトに対応できるように、より
多くのブロックが予約できるということです。ハブに接続されているサイトの場合、これま
でと同じように /52 を割り当てることが可能で、この場合、細分化方法は変わりません。
この例では、サンフランシスコの地域ハブは、 /52 が割り当てられたサイトを最大 80 ま
で収容できます。
まとめ
IPv4 アドレスの枯渇の兆しが見え始め、企業やサービス プロバイダーのネットワークで
は IPv6 の統合が始まりました。地域の登録機関は、IPv4 アドレスの枯渇が現実的な問
題であることを認識し、IPv6 統合プロセスを開始するように組織に働きかけています。こ
の統合プロセスの主要ステップは、アドレスの取得と、取得したアドレスを導入する計画の
構築です。本書では、IPv6 アドレス空間の取得とアドレス計画の構築について、複数の
アプローチを説明しました。組織による IPv6 アドレス空間の取得方法と導入方法は、そ
の組織のニーズによって決まりますが、そのプロセスの計画作成は今すぐ始める必要があ
ります。IPv6 の時代が到来しました。すぐに準備を整えましょう。
2001:db8:1131::/48
アドレス計画
29
リソース
• Deprecating Site Local address（RFC 3879）：http://www.ietf.org/rfc/
rfc3879.txt
• Unique Local IPv6 Unicast Addresses（RFC 4193）：http://www.ietf.org/
rfc/rfc4193.txt
• Special-Use IPv6 Addresses http://www.ietf.org/rfc/rfc5156.txt
IPv6 リソース
• Requirements for Address Selection Mechanisms http://www.ietf.org/rfc/
rfc5221.txt
• Cisco.com 内の IPv6 情報：http://www.cisco.com/ipv6
• SEcure Neighbor Discovery (SEND) http://www.ietf.org/rfc/rfc3971.txt
• IPv6 フォーラム。シスコは IPv6 フォーラムを設立しました。また、このフォーラム
のアクティブ メンバーです。使命は、IPv6 プロトコルの使用を推進することです。
http://www.ipv6forum.com/
• Cryptographically Generated Addresses (CGA) http://www.ietf.org/rfc/
rfc3972.txt
• 世界各国の IPv6 タスク フォース：http://www.ipv6tf.org/
◦
North-America IPv6 Task Force：http://www.nav6tf.org/
◦
European IPv6 Task Forces：http://www.ipv6tf.org/meet/tf/eutf.php
◦
Japan IPv6 Promotion council：http://www.v6pc.jp/en/
◦
Asia Pacific IPv6 Task Force：http://www.ap-ipv6tf.org/
IPv6 関連書籍：
•
• IPv6 Address Prefix Reserved for Documentation http://www.ietf.org/rfc/
rfc3849.txt
• Default Address Selection for Internet Protocol version 6 (IPv6) http://
www.ietf.org/rfc/rfc3484.txt
• A Flexible Method for Managing the Assignment of Bits of an IPv6
Address Block http://www.ietf.org/rfc/rfc3531.txt
• Use of /127 Prefix Length Between Routers Considered Harmful http://
www.ietf.org/rfc/rfc3627.txt
◦
IPv6 for Enterprise Networks, Shannon McFarland, Muninder Sambi,
Sanjay Hooda, Nikhil Sharma, ISBN 1587142279
• Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
Address http://www.ietf.org/rfc/rfc3956.txt
◦
Deploying IPv6 networks, Ciprian Popoviciu, Erik Levy-Abegnoli, and
Patrick Grossetete, ISBN 1587052105
• IPv6 Implications for Network Scanning http://www.ietf.org/rfc/rfc5157.
txt
◦
IPv6 Essentials, Silvia Hagen, ISBN 0596100582
◦
Understanding IPv6, Joseph Davies, ISBN 0735624461
• Privacy Extensions for Stateless Address Autoconfiguration in IPv6 http://
www.ietf.org/rfc/rfc3041.txt
◦
Cisco Self Study: Implementing Cisco IPv6 Networks, Regis
Desmeules, ISBN 1587050862
• Reserved IPv6 Subnet Anycast Addresses http://www.ietf.org/rfc/
rfc2526.txt
◦
Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile
and Fixed Networks, Marc Blanchet, ISBN 0471498920
• IPv6 Unicast Address Assignment Considerations：http://tools.ietf.org/
html/rfc5375
◦
Global IPv6 Strategies: From Business Analysis to Operational
Planning, Patrick Grossetete, Ciprian Popoviciu, Fred Wettling, ISBN
1587053438
• IPv6 Top Level Aggregator (TLA) Assignment：http://www.iana.org/
assignments/ipv6-tla-assignments
アドレス関連リソース
• IPv6 Addressing Architecture（RFC 4291）：http://www.ietf.org/rfc/
rfc4291.txt
• IPv6 Global Unicast Address Format（RFC 3587）：http://www.ietf.org/rfc/
rfc3587.txt
August 2012 Series
• IPv6 Multicast Address Assignment：http://www.iana.org/assignments/
ipv6-multicast-addresses
• AFRINIC IPv6 Policies：http://www.afrinic.net/en/services/rs/
membership-types/122-afpub-2004-v6-001
• ARIN Number Resource Policy Manual：https://www.arin.net/policy/nrpm.
html
• LACNIC IPv6 Registration Services：http://lacnic.net/en/registro/ipv6.
リソース
30
html
• RIPE NCC Registration Services：http://www.ripe.net/rs/ipv6/index.html
August 2012 Series
リソース
31
フィードバック
Cisco SBA にフィードバックを提供するには、ここをクリック
してください。
SMART BUSINESS ARCHITECTURE
このマニュアルに記載されている設計、仕様、表現、情報、
および推奨事項（総称して
「設計」）
は、障害も含めて本マニュアル作成時点のものです。
シスコおよびそのサプライヤは、商品性の保証、特定目的への準拠の保証、
および権利を侵害しないこと
に関する保証、
あるいは取引過程、使用、取引慣行によって発生する保証をはじめとする、一切の保証の責任を負わないものとします。
いかなる場合においても、
シスコおよびそのサプライヤは、
この設計の使用または使用できないことによって発生す
る利益の損失やデータの損傷をはじめとする、間接的、派生的、偶発的、
あるいは特殊な損害について、
あらゆる可能性がシスコまたはそのサプライヤに知らされていても、
それらに対する責任を一切負わないものとします。設計は予告なしに変更され
ることがあります。
このマニュアルに記載されている設計の使用は、
すべてユーザ側の責任になります。
これらの設計は、
シスコ、
そのサプライヤ、
パートナーの技術的な助言や他の専門的な助言に相当するものではありません。
ユーザは、設計を実装す
る前に技術アドバイザーに相談してください。
シスコによるテストの対象外となった要因によって、結果が異なることがあります。
このマニュアルで使用している IP アドレスは、実際のアドレスを示すものではありません。 マニュアル内の例、コマンド出力、および図は、説明のみを目的として使用されています。 説明の中に実際のアドレスが使用されてい
たとしても、それは意図的なものではなく、偶然の一致によるものです。
© 2012 Cisco Systems, Inc. All rights reserved.
シスコシステムズ合同会社
〒107-6227 東京都港区赤坂9-7-1
ミッドタウン・タワー
シスコは世界各国 200 箇所にオフィスを開設しています。各オフィスの住所、電話番号、FAX 番号は当社の Web サイト
（www.cisco.com/go/office）
をご覧ください。
© 2012 Cisco and/or its affiliates. All rights reserved. Cisco および Cisco のロゴは、米国およびその他の国における Cisco およびその関連会社の 商標または登録商標です。Cisco の商標の一覧は、www.cisco.com/go/trademarks でご確認いただけます。
掲載されている第三者の商標はそれぞれの権利者の財産です。
「 パートナー」
または
「partner」
という用語の使用は Cisco と他社との間のパートナーシップ関係を意味するものではありません。(1110R)
B-0000200-1JA 12.12