• 検索結果がありません。

第 5 章 IPv6 導入における課題に対する技術的対応 42

5.3. IPv6 継続普及期

5.3.1 IPv6 マルチプレフィックス問題の解決

実施者:筆者を中心とする

NTT

研究所内グループ

時期:

2004

年〜

2014

実施カテゴリ:

IETF

標準化

2

https://www.ntt.com/release/1999news/news/news99/9911/1116.html,

http://www.ntt.com/ipv6/data/ipv6 history.html

マルチプレフィックス問題とその解法

APNIC

地域においては,グローバルな

IPv6

インターネットに直接接続されて

いないネットワークに対しても,

IPv6

アドレスを割り振ることを可能としていた

(

6.1.3

)

.当時,東日本日本電信電話株式会社では,

ISP

とインターネット利用 者の間のアクセスラインを提供する

IPv4

閉域網であるフレッツネットワークを運 用していたが,このポリシを利用して

IPv6

アドレスを取得,フレッツネットワー クにて

IPv6

を利用した閉域網サービスを開始した.

この閉域網による

IPv6

サービスは,将来的に,

ISP

による

IPv6

インターネット 接続サービスと並行して利用され,並行利用により,端末に複数の

IPv6

アドレス が同時に付与される,「マルチプレフィックス」に関する課題が発生することが想 定された.この「マルチプレフィックス問題」は,閉域網とグローバル

IPv6

イン ターネットとの同時接続のみならず,複数の

ISP

と同時に接続する場合にも発生 する.

ノードの単一インタフェースに複数のアドレスが付与できることは

IPv6

の特 長の一つである.特に,複数の

IPv6

サービスプロバイダに接続される場合に,そ れぞれのサービスプロバイダから割り当てられた

IPv6

アドレスを用いて,個々の ノードも複数の

IPv6

アドレスを持つことになる.この状態のネットワークを,マ ルチプレフィックスネットワークと呼ぶ.マルチプレフィックスネットワークでは,

通信を開始する際に通信相手に応じた正しい

IPv6

アドレスを始点アドレスとして 選択する必要がある.図

5.2

に,複数サービスプロバイダとの同時接続時の様子を 示す.

閉域網と

ISP

との同時接続の例において,両ネットワークに接続されたサイト では,始点アドレス選択が大きな問題になる.この例では,ユーザサイトに

ISP

と閉域ネットワークからそれぞれ

IPv6

アドレスブロックが割り当てられ,端末に は二つの

IPv6

アドレスが付与されている.サイト内の端末が,インターネットに あるサーバに通信する際,閉域網から割り当てられたアドレスを始点アドレスと して利用した場合,サーバからの返答が端末まで到達せず,通信が成立しない.

ユーザサイトが複数の

IPv6 ISP

に接続している場合,ユーザサイトには上流

ISP

それぞれからアドレスブロックが割り当てられ,端末には複数のアドレスが付 与される.このようなネットワーク環境で端末がパケットを送信する場合,通信 の際に端末が選択した始点アドレスが,パケットが送信される上流

ISP

が割り当 てたものでないことがある.昨今,セキュリティ対策として,ユーザ端末のアド

5.2

複数サービスプロバイダとの同時接続

レス詐称を防ぐために,ユーザから送信されるパケットについて,自ネットワー クのアドレス以外をフィルタすることが一般的になってきている

[24]

.このため,

選択された始点アドレスによっては,パケットが届かない,といった事象が発生す る.特に,コンシューマネットワークのような比較的小規模なサイトの場合,

ISP

は経路情報を提供せず,ディフォルトルートを利用した経路制御を実施している 場合が多い.この場合,ディフォルト経路が向いている

ISP

から割り当てられた

IPv6

アドレス以外を始点アドレスとして用いたパケットは,フィルタされてしま う.

IPv6

の仕様では

RFC6724[25]

にて,複数アドレス選択のアルゴリズムを定義 している

.

この

RFC

では,アドレス選択を制御するポリシテーブルを定義,この テーブル中の規則に従って,始点アドレスを制御する.

RFC

中にはディフォルト のポリシテーブルが定義されているが,ディフォルト動作では,通信できないア ドレスが選択される可能性がある.

マルチプレフィックス問題は,

IPv6

による閉域網サービスが広く利用されてい る日本において多く発生することが予測された.解決方法として,端末に対し,

IP

アドレス選択ポリシを配布する機構を

IETF

に提案した.前述のように,

IPv6

の 仕様として,ポリシテーブルによるアドレス選択機構が定義されている.ネット ワークの状態に合わせたポリシテーブルを端末に配布,設定することで複数アドレ スの選択を制御することが可能となる.本提案では,

“Default Address Selection

Policy Option”

という新しい

DHCPv6

オプションを定義し,

IPv6

環境でプロバイ ダからユーザにアドレスブロックを割り当てるプロトコルである

DHCP-PD

に重

畳してアドレス選択ポリシを配布する.サイト内では,

DNS

サーバアドレス等を

配布する

DHCPv6

を利用し,各端末まで選択ポリシをが配布する.

RFC6724

で定

義されているアドレス選択ポリシ機構はすでに多くのオペレーティングシステム で実装されているため,端末へのアドレスポリシ配布機構を規定することで,管 理者によるアドレス選択の制御が可能となる.図

5.3

に配布機構の動作を示す.

5.3

アドレス選択ポリシ配布

ISP

と閉域ネットワークより,アドレスブロックとあわせ,アドレス選択に関す るポリシを配布する.ユーザサイトのルータでは,配布されたポリシをマージし た上で,宅内の端末機器に配信する.端末機器は,配布された選択ポリシテーブ ルを利用することで,通信相手のアドレスに応じた始点アドレスが選択される.

また,本技術は,

IPv6

の豊富なアドレス空間を利用し,複数のアドレス空間利用 による

IPv6

マルチプレフィックスサービスにも利用可能である.マルチプレフィッ クス技術によるマルチサービス提供の例を図

5.4

に示す

[26]

この例では,ユーザは,インターネットサービス,ビデオオンデマンドサービ ス,ホームセキュリティサービス,ネットワーク家電制御サービスを利用してお

5.4

マルチプレフィックスによるマルチサービス

ンシューマネットワークでは,このような環境は既に数多く存在し,

IP

電話,イ ンターネット接続,および映像配信サービスが別ネットワークにて提供されてい る.現在のこれらのサービスは主に

IPv4

を用いて実装されており,端末に割り振 られる

IPv4

アドレスは一つで,出口のホームゲートウェイ(

HGW)

NAT

を用 いた始点アドレス変換を実施している.

IPv6

を利用したこのようなサービスの提 供形態の実装例の一つとして,マルチプレフィックスによるマルチサービスが利用 できる.

標準化の経緯

5.3.1

節で述べたように,マルチプレフィックス問題は,

IPv6

による閉域網

サービスが広く利用されている日本において多く発生することが想定された.こ の解決方法として,

2004

10

月に,

DHCP

のオプション等を議論する,

IETF DHC WG (Dynamic Host Configuration WG)

に対し,始点アドレス選択情報配

DHCPv6

オプションとして提案した

[27]

.この時点では,始点アドレス選択情

報のみを配布するオプションとして定義していたが,

IETF

議論の結果,

RFC6724

(

当時は

RFC3484)

にて規定されているポリシテーブル全てを配布するように変更

した

[28]

その後,当該オプションの必要性についての合意がなかなか得られず,

IPv6

の 基本仕様との整合性をとる必要があるとの意見から,

IPv6

プロトコル仕様を標準

化している

6man WG (IPv6 Maintenance WG) (

当時は

ipv6 WG)

にて提案説 明,議論の実施,また,オペレーションに関係するということから,

v6ops WG (IPv6 Operations WG)

での議論とたらい回しとなり,標準としての議論が進展し なかった.

このため,マルチプレフィックス環境に課題の整理,及び,解法の必要要件を はっきりさせることを目的とし,

2006

12

月に,マルチプレフィックス環境にお けるアドレス選択に関する問題提起についての文書

[29]

を提案した.この文書は,

v6ops WG

にて取り上げられ,

WG

での議論アイテムとなり

[30]

,また,同時に,

解法としてのアドレス選択ポリシ配付機構の要件定義について提案

[31]

した.両文 書は,問題提起文書

[32],

解決に当たる要件提起文書

[33]

として

RFC

化され,

2010

6

月に,

DHCP

アドレス選択ポリシ配布オプションについても,

6man WG

に て正式な議論アイテムとなった.

この後,筆者所属組織内の体制変更により,標準化作業を第二著者に引き継ぎ,

最終的に

DHCPv6

オプション定義

[34]

標準として規定された.