JP4760963B2 - ＩＰｖ６アドレス割り当て方法 - Google Patents

Description

本発明は、パケット通信システム及び移動体通信システムに用いるデータ通信装置及びアドレス生成方法、アクセスサーバ、並びにコンピュータ・プログラムに関する。

近年、移動体通信において、移動端末を使ったメールの送受信、インターネットへのアクセス、Web閲覧といったデータ通信が盛んに行われている。このようなデータ通信を実現するため、移動無線端末とデータ通信装置（Packet Data Serving Node：以下ＰＤＳＮと称す）間のデータ通信用として、非特許文献１に開示のとおりＲＦＣ１６６１で標準化されているPont to Point Protocol（以下ＰＰＰと称す）が使用されていることが知られている。ＰＰＰでは、データ通信に必要な設定の交渉、アクセスするユーザの認証、ＩＰアドレスやDNSアドレスの通知する機能から成り立っている。

また、ＰＰＰで転送するネットワーク層としてInternet Protocol（以下ＩＰと称す）が用いられ、現在多く使用されているＩＰはＩＰｖ４であり、発信元／宛先として３２ビットからなるアドレス（ＩＰアドレス）が用いられている。インターネット通信においては、３２ビットＩＰアドレスを各発信元／宛先にユニークに割り当てるグローバルＩＰアドレスを採用し、ＩＰアドレスに応じて、個々の発信元／宛先を判別している。しかし、インターネットの世界は急速に広がりを見せており、ＩＰｖ４の限られたアドレス空間、すなわちグローバルアドレスの枯渇が問題となってきている。これを解決するためにInternet Engineering Task Force（以下ＩＥＴＦと称す）では、次世代ＩＰアドレスとしてＩＰアドレス空間を３２ビットから１２８ビットに拡張する新しいInternet Protocol version 6（以下ＩＰｖ６と称す）を提案している。

図１２は、ＩＰｖ６アドレスのフォーマットを示す図である。ＩＰｖ６アドレスの上位６４ビットは経路情報（ネットワークプレフィックス：Network Prefix：以下Prefixと称す）１１１０であり、下位６４ビットはノードが有するネットワークインタフェースをノードが接続しているサブネットワーク内で識別するためのインタフェース識別子(以下Interface IDと称す)１１２０である。Prefix１１１０の内、上位４８ビットをPublic Topology１１１１と呼ばれ、Internetプロバイダの経路に使われ、下位１６ビットは、Site Topology１１１２と呼ばれローカルルーティングに使用される。インタフェース識別子１１２０はサブネットワーク内で一意であり、インタフェース識別子としてＭＡＣアドレス等が利用される。

ＰＰＰを用いたＩＰｖ６通信は、非特許文献２に開示のとおりＲＦＣ２４７２で規定されているＩＰｖ６ＣＰ手順を用いて行われる。このＩＰｖ６ＣＰ手順では、ＩＰｖ６アドレスのInterface-ID１１２０を通信相手に通知する手順を規定している。

3rd Generation Partnership Project 2（以下３ＧＰＰ２と称す）のX.S0011-Cのリファレンスモデルでは、移動端末、移動端末と無線接続するRadio Network、移動端末とＰＰＰ接続するＰＤＳＮ、ＰＤＳＮが認証時にアクセスするRADIUS、インターネットプロバイダ、インターネットと接続されているIP Networkから構成される。移動端末とＰＤＳＮ間でＰＰＰ接続が完了すると、移動端末は、プロバイダネットワーク、ＰＤＳＮ２００を介してIP Networkと接続し、インターネット通信、コンテンツ閲覧を行えるようになる。ＩＰｖ６接続を行う場合、ＰＤＳＮは、移動端末に付与するPrefixをＰＰＰリング毎にユニークにしなければならないことが知られており、Prefixはルータ広告（以下Router Advertisementと称す）で移動端末に通知することも知られている。

３ＧＰＰ２（ＣＤＭＡ２００）モデルを適用したシステムにおけるＩＰアドレス割り当てとして、特開２００４−１０４８００「符号分割多重接続システムにおける端末に対するＩＰアドレス割り当て方法」が特許文献１として開示されているが、ＩＰｖ６アドレス割り当てに関しては言及していない。

特開２００４−１０４８００号公報

３ＧＰＰ２ Ｘ．Ｓ００１１−Ｃ cdma2000 Wireless IP network Standard ＲＦＣ１６６１ Point to Point Protocol ＲＦＣ２４７２ IP Version 6 over PPP ＲＦＣ２８６５ Remote Authentication Dial In User Service (RADIUS) ＲＦＣ３３１５ Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

上述した非特許文献１に示される従来のネットワーク接続方式では、ＰＰＰリンク毎の移動端末のPrefixをユニークに割り当てることを規定している。これはＰＤＳＮがＩＰｖ６パケットを転送する際にPrefixを使ってＰＰＰリンクを識別する必要があるからである。また、非特許文献１では、移動端末に割り当てるPrefixは、Home-RADIUSからＰＤＳＮへと送信するAccess-AcceptにFramed-IPv6-Prefixとして含めることと規定している。Access-Acceptは、非特許文献３に開示のとおりIETF RFC2865で規定されているインタフェースであり、図６に示すフォーマットが使われる。さらにＰＤＳＮは、Home-RADIUSから受信したAccess-AcceptのFramed-IPv6-PrefixからPrefixを取り出し、Router Advertisementメッセージに含めることで移動端末に通知する。通知を受けた移動端末は、ＩＰｖ６グローバルアドレスを生成でき、IP NetworkへのＩＰｖ６通信が可能となる。

しかしながら、この手順で行うとＰＰＰリンク毎にPrefixをユニークにするためには、Home-RADIUSでＰＰＰリング毎にユニークになるようにPrefixを管理する必要がある。また、Home-RADIUSは、3rdベンダ毎に設置される場合があり、異なる3rdベンダに複数のHome-RADIUSが存在する。この場合、複数のHome-RADIUSでPrefixが重複しないように設定することは運用上困難である。更に移動端末に割り当てる６４ビットPrefixは、ＰＰＰリンク毎に異なる値なため、ＰＤＳＮと接続されているIP Network内にあるＩＰｖ６ルータの経路情報は、図１４に示すようにＰＰＰリンク数に相当する経路情報が必要であり、ＩＰｖ６の特徴である経路の集約ができなくなる。

図１４は、IP NetworkにあるＩＰｖ６ルータからＰＤＳＮへの経路を決めるために必要な経路テーブルであり、宛先のPrefix４０１と次の転送先であるネクストホップ４０２の情報が格納されている。宛先のPrefix４０１には、移動端末に割り当てた６４ビットPrefix４０３、ネクストホップにはＰＤＳＮのＩＰｖ６アドレスが格納されることで、IP Networkから移動端末宛てのＩＰｖ６パケットがＰＤＳＮを経由して移動端末へと転送することができる。

本発明の目的は、上記従来の技術の欠点を解消し、Home-RADIUSがＰＰＰリンク毎のユニーク性を意識することなくPrefixの運用管理を容易にすること、データ通信装置が移動端末に通知するPrefixを生成する装置を提供することで、ＰＰＰリンク毎のユニーク性を保障することである。また、経路集約効果を高めたＩＰｖ６アドレス割り当て方法を提供するものである。

上記目的を達成するため、本発明は、プロバイダネットワークを介し、ＰＰＰ（Point to Point Protocol）を用いて、通信端末装置の接続承認を認証サーバへ問い合わせすることで行い、認証サーバから通知されるPrefixを抽出し、装置管理識別子を生成し、ＰＰＰ識別子を生成し、抽出したPrefixと装置管理識別子とＰＰＰ識別子を結合してＩＰｖ６アドレスのPrefixを生成するようにしたものである。

以上に説明したように、課題を解決する手段を用いることで、データ通信装置でＰＰＰリング毎のユニーク性を満足したＩＰｖ６アドレスのPrefixを生成することができる。これによりHome-RADIUSは、ユニーク性を考慮することなく移動端末に割り当てるPrefixを管理することができる。また、データ通信装置は、経路集約効果をもつPrefixを生成、通知することで、ＩＰｖ６ルータの経路情報数を減らすことができる。

本発明を適用した移動体通信システムの構成を表した網構成図である。 データ通信装置（PDSN）の構成図である。 データ通信装置に実装されたソフトウェア構成図である。 データ通信装置に実装されたソフトウェアの接続処理フローである。 本発明を適用した移動体通信システムの接続シーケンス図である。 Access-Request、Access-Acceptパケットのフォーマット図である。 Access-Acceptに含まれるFramed-IPv6-Preefixのフォーマット図である。 Router Advertisementに含まれるPrefixオプションのフォーマット図である。 データ通信装置に実装されたソフトウェアが用いる呼管理テーブルの構成図である。 データ通信装置で生成するPrefixの構成図である。 データ通信装置で生成するPrefixの生成フロー図である。 IETF勧告で規定されてるＩＰｖ６アドレスの構成図である。 データ通信装置によって生成された外部ＩＰｖ６ルータの経路テーブルである。 従来のデータ通信装置によって生成された外部ＩＰｖ６ルータの経路テーブルである。 本発明を適用した移動体通信システムの別の構成を表した網構成図である。 図１５のシステムの動作を示す接続シーケンス図である。 データ通信装置に実装するソフトウェアの別の構成を示す構成図である。 データ通信装置が生成するPrefixの別の構成を示す構成図である。

以下、図面を用いながら本発明のデータ通信装置の構成や動作、ならびに、IPアドレス管理方法について詳細に説明する。
図１は、本発明を適用した移動体通信システムの構成例を示す網構成図である。
移動体通信システムは、移動端末１００又は１１０と、移動端末１００、１１０と無線リンクで接続する基地局１２０、無線管理を行う無線管理装置１３０、移動端末１００とＰＰＰ接続する本発明によるデータ通信装置（以下、ＰＤＳＮと称する）２００又は３００、ＰＤＳＮ２００、３００がユーザ認証時にProxy-RADIUS５００経由でアクセスするHome-RADIUS６００又は６５０、ＩＰ Network７００とから構成される。

ＩＰ Network７００は、ＩＰｖ６通信を行うもので、図示していない複数のＩＰｖ６ルータによってＩＰパケットが転送される。移動端末１００は、ＰＰＰ接続１０６が完了すると装置管理装置１３０、ＰＤＳＮ２００、ＩＰｖ６ルータ４００を介してIP Network７００（たとえばインターネット）と接続し、インターネット通信、コンテンツ閲覧を行えるようになる。プロバイダネットワーク１４０とは、一般的なサービスプロバイダが管理するネットワークであり、ＰＤＳＮ２００、Proxy-RADIUS５００もサービスプロバイダで管理している場合が多い。移動端末１００は、接続開始操作を行うことでＰＤＳＮ２００に対してＰＰＰ接続確立１０６を開始、ＰＰＰ接続が完了した後のデータ送受信が可能となる。

図２は、ＰＤＳＮ２００の機能構成図である。ＰＤＳＮ２００は、プロバイダネットワーク１４０との外部インタフェースを持つネットワーク部２１０または２２０、ＰＰＰといったプロトコル処理を行う制御部２４０、統計情報や課金情報といった必要情報を蓄えるデータ蓄積部２３０から構成される。

ネットワーク部２１０は、伝送路インタフェース２１１とバスコントローラ２１２から成り、外部から受信したデータを装置バス２３４経由で制御部２４０へと転送する機能を持つ。また制御部２４０から送信されたデータを外部インタフェースに送信する場合もこのネットワーク部２１０を介して転送される。このネットワーク部２１０は単数、または複数２２０あり、プロバイダネットワーク１４０向けとIP Network７００向けの外部インタフェースを別けること、または共通にすることを選択することができる。

制御部２４０は、装置バス２３４とプロセッサバス２３５のアクセス調停を行うバスコントローラ２４２、ソフトウェアを動作させるプロセッサ２４３、ソフトウェア動作に必要なワークエリア、テーブル格納、プログラム格納、および外部から受信したパケットを格納するメモリ２４１、プロセッサ能力を向上させるためのキャッシュメモリ２４４、これらを接続するプロセッサバス２３５から成る。データ蓄積部２３０は、装置バス２３４とのアクセス調停を行うバスコントローラ２３１、プログラムを格納するハードディスク又はフラッシュクメモリ２３２、ハードディスクまたはフラッシュメモリ２３２を制御するディスク制御２３３から成る。

図３は、プロセッサ２４３で動作するソフトウェア構成２０００を示す構成図であり、オペレーションシステム（以下ＯＳと称す）２８００上にＰＰＰ交渉を行うＰＰＰ処理２１００、無線管理装置１３０とR-Pセッション１３２を確立するR-Pセッション処理２４００、認証処理を行う認証処理２２００、課金の情報を収集する課金処理２３００、Router Advertisement処理等を行うＩＰ処理２５００、ＦＡ（Foreign Agent）処理を行うMobile IP処理２６００が動作している。ＰＰＰ処理２１００には、移動端末の情報を管理するため、図９の呼管理テーブルを持っている。この管理テーブルは、接続に必要な情報が格納されており、例えば移動端末のNetwork Access Identifier(以下NAIと称す)２１１１や、無線管理情報２１１２として、International Mobile Subscriber Identity（以下ＩＭＳＩと称す）等が格納されている。またテーブルの行数は、ＰＤＳＮの移動端末の接続数と一致する。このテーブルは、R-Pセッション処理２４００といった他の処理もアクセスできるテーブルである。

図３のソフトウェアは、移動端末との接続として図４のフロー手順で処理を行う。このフローは、無線管理装置１３０からのR-Pセッション１３２要求があることでステップ２００１から開始され、ステップ２４０１に進む。ステップ２４０１では、ＰＤＳＮ２００に新規接続である移動端末１００の接続を受入れる空き容量があるかをR-Pセッション処理２４００がチェックする。R-Pセッション処理２４００は、この空き容量チェックとして、図９の呼管理テーブルを検索して空き行が存在するか検索する。検索結果として空き行が存在する場合は、受入れ可能としてステップ２４０２へ、空き行がない場合は、受入れ拒否としてステップ２４０３と進む。ステップ２４０３では、無線管理装置１３０に対してＰＤＳＮ２００に空き容量がないことを伝える処理（Re-Direct）を行いステップ２００２に進み終了となる。

一方、ステップ２４０２に進んだ場合は、接続処理を開始して、ステップ２４０４でＲ−Ｐセッションが確立するまでR-P処理２４０２を繰り返し、確立が完了するとステップ２１０１に進む。ステップ２１０１では、ＰＰＰ処理２１００が始まり、先ずＬＣＰ交渉１０１が開始される。ＬＣＰ交渉１０１が完了した場合、ステップ２２０１の認証処理２２００に進む。認証処理２２００では、Proxy-RADIUS５００経由でHome-RADIUS６００に認証要求を行い、ステップ２２０２に進む。認証結果が成功であった場合、ステップ２１０２に進む。ステップ２２０２で認証失敗であった場合には、ステップ２２０３に進み切断、もしくは再接続となりステップ２００２に進む。切断か再接続かは装置管理２７００によって選択される。ステップ２１０２では、ＰＰＰ処理２１００にもどり、ＩＰｖ６ＣＰ交渉１０４が始まる。ＩＰｖ６ＣＰ交渉１０４が完了するとステップ２５０１に進み、ＩＰ処理２５００は、移動端末に対してRouter Advertisement１０５の送信処理を行い、ステップ２００２に進み接続が完了する。

次に図５の移動端末１００の接続シーケンスにて詳細に動作を説明する。移動端末１００は、ユーザによる接続要求があると始めに基地局１２０、および無線管理装置１３０と無線セッション１３１を確立する。無線管理装置１３０は、無線セッション１３１を確立するとＰＤＳＮ２００との間でＲ−Ｐセッション１３２の接続が開始される。無線セッション１３１、Ｒ−Ｐセッション１３２とは、移動体通信に必要な専用のシグナリングである。

ＰＤＳＮ２００では、無線管理装置１３０からのＲ−Ｐセッション１３２の確立要求を外部インタフェースから受信するとネットワーク部２１０を通り、装置バス２３４を経由して、メモリ２４１に格納される。格納後は、プロセッサ２４３で動作しているソフトウェア２０００によってパケット解読・処理が実施される。この解読結果、Ｒ−Ｐセッション１３２の確立要求と判断すると図４の接続フローが開始され、ステップ２４０１に進む。上述したようにステップ２４０１ではＰＤＳＮの空き容量をチェックの為、Ｒ−Ｐセッション処理２４００は、図９の呼管理テーブルに空き行があるか検索する。検索結果、Ｎｏが１の行が空きと判断した場合、このＮｏが１の行２１２１に、Ｒ−Ｐセッション１３２の確立要求に含まれる無線管理情報を格納する。

格納が完了するとＲ−Ｐセッション処理２４００は、無線基地局１３０に対して、受入れ許可の応答を制御部２４０、装置バス２３４、ネットワーク部２１０を介して送信し、ステップ２１０１に進む。ステップ２１０１では、ＰＰＰ処理２１００がＬＣＰ交渉パケット１０１を移動端末１００へと送信する。つまりＰＰＰ交渉の開始である。

一方、移動端末１００は、無線セッション１３１を確立すると、ＰＰＰ交渉を開始させ、ＰＤＳＮ２００に対してＬＣＰ交渉パケット１０１を送信する。ＬＣＰ交渉１０１では、接続に必要なＭＲＵ（Maximum-Receive-Unit）や、ＣＨＡＰ，ＰＡＰといった認証種別を決定する。ＬＣＰ交渉１０１が完了すると移動端末１００は、認証要求１０２をＰＤＳＮ２００に対して送信する。

ＰＤＳＮ２００は、上述同様に受信した認証要求１０２をメモリ２４１まで転送し、プロセッサ２４３上で動作しているソフトウェア２０００で解析・処理を行う。この処理は、図４フローのステップ２１０１からステップ２２０１に進んだことになる。

認証処理は、移動端末１００の接続許可承認であり、ＰＤＳＮ２００とProxy-RADIUS５００もしくはHome-RADIUS６００，６５０との間は、IETF RFC2865で規定されているRADIUSインタフェースが使われる。RADIUSインタフェースは、認証要求のAccess-Requestと認証応答のAccess-Accept又は、Access-Rejectから構成され、図６のフォーマットが使われる。同図で、Code５１０は、Access-RequestやAccess-Acceptといったパケット種別を区別するためのフィールド、Identifier５１１は、Access-RequestとAccess-Acceptとの括り付けに使われ、Attribute５１４は、認証に必要な情報（例えば、NAIやパスワード等）を格納するフィールドである。

認証処理２２００は、Access-Requestを作成して、Proxy-RADIUSが存在するシステムでは、Proxy-RADIUS５００に対して、Access-Request５０１を送信する。システムによってはProxy-RADIUS５００が存在せずにHome-RADIUSのみの場合もあり、その場合、Home-RADIUS６００、又は６５０にAccess-Requestを送信する。

Access-Request５０１を受信したProxy-RADIUS５００は、適切なHome−RADIUS６００、または６５０に対して、受信したAccess-Request５０１をリレーする。Home−RADIUS６００又は、６５０はProxy-RADIUS５００より受信したAccess-Request５０２を解読して、移動端末１００のアクセスを許可するかを判断する。

Home-RADIUS６００、又は６５０は、許可すると判断した場合、接続に必要な情報、例えばＩＰｖ６グローバルアドレスの生成に必要なPrefixやInterface-IDをAccess-Accept５０３に含ませてProxy-RADIUS５００へと送信する。この時Prefixは、Framed-IPv6-Prefixと呼ばれ、Access-AcceptのAttribute５１４に格納される。

図７は、Framed-IPv6-Prefixのフォーマットである。Prefixの長さを示すPrefix-Lengthフィールド５２１があり、Prefix５２０は、可変で格納することができる。このPrefixフィールドに４８ビットのPrefixを格納する。また、システムによっては６４ビットのPrefixを格納してもよい。

Proxy-RADIUS５００は、Access-Accept５０３を受信した後、Access-Request５０１送信元であるＰＤＳＮ２００に対してリレーする。ＰＤＳＮ２００は、Access-Accept５０４をメモリ２４１まで転送して後、認証処理２２００が解析する。

認証処理２２００は、認証応答が認証成功であった場合、移動端末１００に認証成功１０３を送信して、図４のステップ２１０２に進む。また、認証処理２２００は、Access-Accept５０４に含まれるFramed-IPv6-Prefix５２０から４８ビットのPrefix１１０１を取得して保持する。次のステップ２１０２では、ＩＰｖ６ＣＰ処理を行い、移動端末１００とＩＰＣ６ＣＰ交渉１０４を行う。ＩＰｖ６ＣＰ交渉１０４では、ヘッダ圧縮種別やInterface-ID等を決定する。

一方、移動端末１００では認証成功１０３を受信した後、ＩＰｖ６ＣＰ交渉１０４を開始する。ＰＤＳＮ２００は、ＩＰｖ６ＣＰ交渉１０４が完了すると次にステップ２５０１に進みＩＰ処理２５００は、Router Advertisement１０５で通知すべきPrefixを図１１のフローで生成する。

次に図１１のフローを説明する。ステップ２５１１では、図４ステップ２２０１で認証処理２２００が保持しているPrefix１１０１を取得する。次にステップ２５１２でPrefix１１０１のビット長をチェックする。チェックした結果、４８ビット以下であればステップ２５１３に、４８ビットを超える場合はＰＤＳステップ２５１８に進む。ステップ２５１３は、４８ビット未満の場合のパディング処理行うもので、予めシステムで決められた値で４８ビットを満たすまでパディングを行いステップ２５１４に進む。Prefix長が４８ビットの場合は、パディングを行う必要なくステップ２５１４に進む。また、ステップ２５１８は、４８ビットを超えるPrefixから４８bit分１１０１を抽出して、ステップ２５１４に進む。

ステップ２５１４は、装置管理２７００より装置識別子１１０２を取得して保持する。例えば装置識別子は、ＰＤＳＮ２００を(0001)bit、ＰＤＳＮ３００を(0010)bitといった番号で使う。装置管理２７００で管理されている装置識別子１１０２は、予め決めて設定する場合と保守センタよりダウンロードする場合がある。ＩＰ処理２５００は、装置識別子１１０２を取得後、ステップ２５１５に進む。

ステップ２５１５では、ＰＰＰ処理２１００よりＰＰＰ識別子１１０３を取得する。ＰＰＰ識別子１１０３とは、ＰＰＰ処理２１００が管理している図９の呼管理テーブルのＮｏと等しい番号である。Ｎｏは、重なることのないユニークな番号でありＰＰＰ識別子１１０３として使うことができる。ＰＰＰ識別子１１０３を取得した後は、ステップ２５１６に進む。

ステップ２５１６では、ステップ２５１１で取得したPrefix１１０１と、ステップ２５１４で取得した装置識別子１１０２、ステップ２５１５で取得したＰＰＰ識別子１１０３を結合して、図１０の６４ビットのPrefixを生成する。このPrefixを移動端末１００に付与することとなる。なお、上述した実施例では、装置識別子１１０２として４ビット、ＰＰＰ識別子１１０３として１２ビットを設けているが、割合はシステムで決めることができる。

Router Advertisement１０５は、移動端末１００にPrefixを通知する役割があり、図８はRouter Advertisement１０５で通知するPrefixオプションのフォーマットであり、Prefixフィールド１１００に図１１ステップ２５１６で生成した６４ビットのPrefixを格納する。

移動端末１００は、Router Advertisement１０５でPrefix１１００を受信すると、IPv6CP交渉１０４で決定したInterface-ID１１２０と合わせて１２８ビットのグローバルＩＰｖ６アドレス１０８を生成でき、ＰＰＰ通信１０６を通してＩＰｖ６通信が可能となる。

一方、ＰＤＳＮ２００は、IP Network７００にあるＩＰｖ６ルータと経路情報のやりとり７０１を行う。この際にＰＤＳＮ２００は、移動端末１００のPrefixをHome-RADIUS通知Prefix１１０１＋装置識別子１１０２の５２ビットとして経路情報に載せて通知する。

図１３は、IP Network７００にあるＩＰｖ６ルータの経路テーブルである。ＰＤＳＮ２００から経路情報７０１を受け取ると、宛先IPv6 Prefix４１０にHome-RADIUS通知Prefix１１０１+装置識別子１１０２の５２ビット４１１を登録、ネクストホップ４１２としてＰＤＳＮ２００のＩＰｖ６アドレス４１３を登録することで、ＰＤＳＮ２００に収容している複数ＰＰＰリンク宛ての経路情報を経路情報１つで実現することができる。これらの経路情報は、ＲＩＰng等の動的経路プロトコルを使用して通知し合うことや、静的設定として予め設定することもできる。

上述したようにHome-RADIUS６００又は、６５０は、PrefixとしてPublic Topology部分の48ビット１１１１を管理するだけでよく、ＰＤＳＮ２００でHome-RADIUS６００から通知されたPrefix１１０１に装置識別子１１０２と、ＰＰＰリンク毎に異なるＰＰＰ識別子１１０３を付与することでＰＰＰリンク毎のユニーク性を保障した６４ビットのPrefixが生成できる。これよりHome−RADIUSが複数ある場合でも、お互いのPrefixを意識した管理をする必要がなくなる。また、移動端末１００、１１０と複数のPrefixは、上位５２ビットがHome-RADIUS通知Prefix１１０１+装置識別子１１０２と共通の為、ＩP Network７００は、この５２ビットを元にＰＤＳＮ２００にＩＰｖ６パケットをルーティングすれば通信ができる。これは経路集中化効果が高まったことを意味する。

図１５は、本発明のデータ通信装置を備えた移動体通信システムの別の構成例を示す網構成図である。図１のシステムに対して、ＤＨＣＰサーバ９００が追加されていることが特徴である。

ＰＤＳＮ２００、又は３００の構成は、図２と同じであり、プロセッサ２４３で動作するソフトウェア構成は、図１７になる。これは図３の構成にＤＨＣＰ-Relay２９００が追加されている点が異なる。ＤＨＣＰ-Ｒｅｌａｙ２７００とは、非特許文献４に開示のとおりIETF RFC3315 DHCP-Reply-Agent機能を有するソフトウェアであり、移動端末１００からのＤＨＣＰ要求をＤＨＣＰサーバへとリレー機能を持つ。

次に移動端末１００の接続シーケンスを図１６にて説明する。移動端末１００は、ユーザによる接続要求があると始めに基地局１２０、無線管理装置１３０と無線セッション１３１を確立、次にＰＤＳＮ２００に対してＬＣＰ交渉１０１を開始する。その後、ＰＰＰ通信１０６が可能になるまでは従来技術と同じシーケンスで接続する。

移動端末１００は、ＰＰＰ接続完了すると、ＤＨＣＰｖ６を使ってＩＰｖ６ Prefixを取得する。取得の際は、移動端末１００は、DHCPv6 Solicit９１０をＰＤＳＮ２００に送信する。

ＰＤＳＮ２００は、ＤＨＣＰ Ｒｅｌａｙ２９００でＲＦＣ３３１５規定の処理を行い、DHCPv6 SolicitをＤＨＣＰサーバ９００へと転送する。ＤＨＣＰサーバ９００は、DHCPv6 Solicit９１１を受信するとＰＤＳＮ２００を介して移動端末１００にDHCPv6 Advertisement９１２を送信する。

移動端末１００は、DHCPv6 Advertisement９１３を受信すると、ＰＤＳＮ２００経由でDHCPv6 Request９１４をＤＨＣＰサーバ９００に送信する。ＤＨＣＰサーバ９００は、システムにより管理されている４８ビットのPrefix１１０４をＤＨＣＰ-Ｒｅｐｌｙ９１６に入れてＰＤＳＮ２００に送信する。

ＤＨＣＰ−Ｒｅｐｌｙ９１６を受信したＰＤＳＮ２００は、ＤＨＣＰ−Ｒｅｐｌｙ９１６に含まれるPrefix１１０４に装置識別子１１０２とPPP識別子１１０３を結合して、図１８の６４ビットのPrefixを生成する。その後、このPrefixをDHCP-Reply９１７に入れて移動端末１００へと送信する。移動端末１００は、DHCPｖ６−Reply９１７を受信するとＩＰｖ６グローバルアドレス９１８を生成する。 移動端末１００は、ＩＰｖ６グローバルアドレスを生成するとＰＤＳＮ１００を介してＩＰｖ６通信が可能となる。

上述の通りＤＨＣＰサーバは、ＰＰＰリンクのユニーク性を意識することなくPrefixを管理することができる。また、Prefix構成は、先に説明した図１のシステムと同様なことから経路集中化の効果もある。

１００：移動端末、 １２０：基地局、 １３０：無線管理装置、
１４０：プロバイダネットワーク、 ２００，３００：データ通信装置（PDSN）、
５００：Proxy RADIUS、 ６００、６５０：Home RADIUS、
７００：IP Network、 １１０２：データ通信装置が生成する装置識別子、
１１０３：データ通信装置が生成するＰＰＰ識別子
２０００：データ通信装置のソフトウェア構成

Claims (4)

1. 移動端末へのＩＰｖ６アドレス割り当て方法であって、
   プロバイダネットワークを介し、ＰＰＰ（Point to Point Protocol）を用いて、移動端末の接続承認を認証サーバへ問い合わせ、
   接続承認通知に含まれて通知される第１のPrefixを抽出し、
   前記移動端末をＩＰネットワークに接続するデータ通信装置の装置管理識別子を取得し、
   前記データ通信装置が管理するＰＰＰリンク毎にユニークに割り当てられた番号から構成されるＰＰＰ識別子を取得し、
   前記第１のPrefixと前記装置管理識別子と前記ＰＰＰ識別子とを結合することでＩＰｖ６アドレスのPrefixを生成し、前記移動端末に割り当てることを特徴とするＩＰｖ６アドレス割り当て方法。
2. 上記第１のPrefixは、Access-AcceptのFramed-IPv6-Prefixで通知されるPrefixであることを特徴とする請求項１に記載のＩＰｖ６アドレス割り当て方法。
3. 上記装置管理識別子は、予め設定されてデータ通信装置で管理されているものであることを特徴とする請求項１または２に記載のＩＰｖ６アドレス割り当て方法。
4. 前記第１のPrefixは48ビットで構成され、前記装置管理識別子には、前記ＰＰＰ識別子に割り当てられるビットより少ないビットを割り当てることを特徴とする請求項１ないし３に記載のＩＰｖ６アドレス割り当て方法。

Images