移動体からインターネットをしたい-Mobile IP

 移動体、例えば長距離バスなどに乗っている状態でインターネットをしたいと思いませんか?と言うと何を言っているの?そんなの出来ています、という人もいるかも知れませんね。それから、Wi-Fiのアクセスポイントを越えて通話ができているからそれでいいんじゃないの?という声も聞こえてきそうです。

 たぶん貴方の意見は大体正しいと思います。ただここでは、少し違う角度からお話をします。この講座では、以前ソケット接続という話をしました。そこでは、ソケット接続では通信相手を「IPアドレス+ポート番号」の組で識別するという説明をしました。ソケット接続の考え方では、IPアドレスが異なってしまうと通信接続の相手方を識別することができなくなります。従って、通信が途中で途切れてしまうということになります。

 皆さんの中にはWi-Fiのローミング(wifi-roaming)を思い浮かべた人も多いのではないでしょうか。これは現在使用中のAP(Access Point)を離れて別のAPの無線範囲に入っても接続が途切れることなく通信を継続することができる機能です。しかし、Wi-Fi ローミングが可能なのは、同じサブネット内に限られます。確かにAPは切り替わるのですが、AP同士はスイッチングハブで接続されています。つまり、同じサブネット内ですので、プレフィックスが同じです。ということは、IPアドレスをそのままにして使うことが可能です。

 では、VoIP(Voice over IP、IP電話)はどうかという人もいるでしょうね。これはちょっと痛いところを突かれた感じです。VoIPではSIP(Session Initiation Protocol)というプロトコルを使うのが一般的なのですが、SIPではIPアドレスをデータとして組み込んでいますので、移動しても通信の同一性を維持することが可能です。

 いきなりSIPといわれても戸惑う人がいると思いますので、少しSIPの話をしたいと思います。電話の機能を実現するためには、「呼制御」(signaling、call-control)と呼ばれる処理が必要になります。これは発信、着信、応答、切断などを制御する機能です。シグナリングのプロトコルとしては以前はH.323というプロトコルが主流でした。しかし、このプロトコルは電話のISDN技術を基本に考えられたもので、インターネット経由で電話の制御をするには拡張性にかけていました。そこで登場したのがSIP(RFC2543、3261)です。SIPはWebのHTTPを基本にして開発されたもので、呼制御のためのいくつかのメソッドを追加しています。SIPで相手を特定したら、そのIPアドレスに向けてデータを送りあうことで会話が成立します。電話を切るときもSIPで接続(セッション)を切ります。

※ISDN(Integrated Services Digital Network、サービス総合ディジタル網):交換機・中継回線・加入者線まで全ての電話回線をデジタル化することで、各家庭の電話回線を利用して、電話やファクシミリ、データ通信を統合して扱えるようにしたもの。

※HTTPでは、GET、HEAD、PUT、POSTなどが代表的なメソッドだが、SIPではこれらは使用せず、呼制御のために新たに14種類のメソッドを定義した。例えば、発信に使うINVITEや切断に使うBYEなど。応答は、HTTPでおなじみの200 OKなど

 SIPにはいくつかの問題点もあります。その1つが相互接続性です。SIPは柔軟で拡張性が高いという特徴を持っているのですが、これは規定のあいまいさからきています。細かいところは各メーカに任せてしまったものですから、多くのメーカが独自の拡張を加えてしまいました。現在、草案段階のものを含めると200近くの拡張規格が存在しています。メーカが異なると、ひどい場合は同じメーカでも製品が異なると正常に機能しない場合があります。

 また、SIPにはNATとの相性がよくないと言う問題もあります。SIPはIPアドレス情報などをメッセージの本体に格納しています。NATはパケット(データグラム)の送信元アドレス(送信元NATの場合)を書き換えますが、メッセージ本体のデータは書き換えることは出来ませんので、NAT環境でSIPを使うとさまざまな不都合が生じます(着信できない、音がまったく聞こえない、自分の音は相手に届くが、相手の音は聞こえないなど、環境によってさまざま)。

 そもそもSIPのような上位層のプロトコルで位置(IPアドレス)の移動などを扱うことは元々のプロトコルの階層構造の考え方と相容れません。上位層のプロトコルに携わる人は、ネットワークの技術的なことには疎くてもかまわない。ネットワーク技術に詳しい人がネットワーク層の実装を作成し、アプリケーション層に詳しい人は上位層の実装を作成すると言うのがそもそもの趣旨です。上位層に携わる人に下位層の技術を要求するようでは、インターネットの発展の上からは望ましいことだとはいえないと思います。

 前置きが長くなりましたが、というわけで、IP層のレベルでノードの移動性を保障するようなプロトコルがほしいと言うことになります。IPのレベルの機能として用意すれば、規格が乱立して通信が出来るかどうかはなはだ心もとないと言うようなこともなくなります。ということで、いよいよ本題に入ります。もちろんIP層だけで全部うまくいくかどうかは分かりませんが、次のような試みがあるということを紹介したいと思います。




1 Mobile IPv4の原理

 TCP/IPの通信では「IPアドレス+ポート番号」(ソケット)の組で通信相手を識別しますので、違うサブネットに移動すると通信の同一性を維持することが出来なくなります。その解決策がモバイル(Mobile)IPです。モバイルIPは移動体からインターネットを使えるように機能拡張されたIPです。モバイルIPでは、端末(これ以降はノード、nodeという)が異なるサブネットに移動した後でも、同一のアドレスを使えるようにしていますので、ユーザは異なるサブネットに移動してもそのことを意識することなしにインターネットを使い続けることが出来ます。

 Mobile IPではこの分野に特有な様々なキーワードが出てきますので、注意して下さい。まず初めに、モバイルノード(Mobile node、移動ノード、移動通信機器)です。これはさまざまなサブネットに移動するノードです。移動ノードとTCP/IPで通信をするノードを対向ノード(Correspondent node、対向機器)といいます。

 移動ノードが元々いたネットワークをホームリンク(home link)といい、ホームリンクにいた時のIPアドレスをホームアドレス(home address)といいます。そして、外部ネットワークに移動したとき、その外部ネットワークを外部リンク(foreign link)、外部リンクに移動したときのアドレスを気付けアドレス(care-of address)と言います。

 気付けは「きづけ」と読みます。気付けとは、郵便物などを相手の住所ではなく、友人宅、実家などの立ち寄り先や帰省先に送るときに使う言葉です。英語ではこれを「care-of」といいますので、郵便制度そのままですね。「きつけ」と読むと、「気絶した者を生き返らせるとか、疲れて元気がない者の気持ちを引き立てる」という意味になってしまうので、注意してください。

 気付けは郵便制度で使っている気付けと同じですが、他にも郵便制度みたいな言葉が出てきます。それは郵便制度の郵便局に該当するエージェントという言葉です。ホームリンクの郵便局に該当するのがホームエージェント(home agent)、移動先の郵便局に該当するのがフォーリンエージェント(foreign agent、外部エージェント)です。

 これで役者が揃いましたので説明を続けます。気付けは郵便制度の気付けと同じといいましたが、若干違います。郵便制度で気付を使う人は宛名人が今どこの身を寄せているかを知っていますが、TCP/IPの場合は、これがありません。したがって、誰かに移動先を伝えておく必要があります。TCP/IPの場合にも、相手に知らせるという手もありそうですが、こうなると相手は誰なのかということになります。TCP/IPの場合は世界中の人が相手になりえますので、インターネットをする人全員に知らせなくてはなりません。これはちょっと難しいことですね。そこで考えられたのは転居届けと同じ原理で、郵便局に該当するホームエージェントに登録しておくことです。ホームエージェントに登録しておけば、ホームエージェントが気付のアドレスまで転送してくれるという方法です。つまり、Mobile IPで採用しているcare-ofは郵便制度の気付けと転居届けを合わせたような機能だということになります。




2 Mobile IPv4の具体例

 具体例で説明します。移動ノードAは元々NW1というプレフィックスのネットワーク(ホームリンク)を本拠としていて、IPアドレスはNW1.1だとしましょう。今、移動ノードはホームリンクから、対向ノードBとインターネット通信中だと仮定します。対向ノードBは通信相手をNW1.10と認識しています。この通信の途中に移動ノードAはプレフィックスNW2に移動したとしたらどうでしょうか?

ホームエージェント:
元々のネットワーク(ホームリンク)の郵便局に該当(ルータ上で機能)

 対向ノードBからの応答は当然、NW1.10宛に来ますので、このままですと通信が途中で途切れてしまいます。そこで、移動ノードAは大急ぎで新しいIPアドレスを取得します。新しいネットワークNW2にDHCPが稼働中なら、新しいアドレスをすぐにもらえるかも知れません。新しいcare-ofアドレスを得たら、移動ノードAはフォーリンエージェントを介してホームエージェントに新しいアドレスを登録します。その間に対向ノードBからの返事は何度かエラーになっている可能性があります。しかし、セッションがタイムアウトする前に登録が済めば、ホームエージェントは、NW1.10宛のパケットをNW2.20に転送してくれます。

移動ノードAは移動先で新しいアドレスを獲得

新しいアドレスはフォーリンエージェント経由でホームエージェントに登録



 ホームエージェントの転送はどのように行われるのでしょうか。通信相手の対向ノードBは通信相手のIPアドレスをNW1.10と認識していますので、パケットのあて先を当然NW1.10としています。これを受け取ったホームエージェントはアドレステーブルを確認して、care-ofアドレスがNW2.20であることを確認して、あて先をNW2.20としたパケットでカプセル化して、転送します(IP in IP トンネリング)。

ホームエージェントは受信パケットをカプセル化してcare-ofアドレスに転送


 これでうまくいきそうですが、話は簡単ではありません。まず、移動ノードAは異なるサブネットに移動したことを何らかの方法で知らなくてはなりません。Mobile IPv4ではエージェントはモバイルエージェント広告(Mobile Agent Advertisement)を出すことになっています。これはICMPルータ広告メッセージの機能を拡張したものです。移動ノードは常にこのモバイルエージェント広告メッセージを検出して、自分がホームリンクにいるのか、外部リンクにいるのかを知らなくてはなりません。モバイルノードは異なるサブネットに移動して直ぐにこのモバイルエージェント広告メッセージを受け取れない場合も考えられます。この場合は、自分から広告の送信を要請することができます(モバイルエージェント要請メッセージ、Mobile Agent Solicitation)。これはICMPのルータ請願(要請)通知を機能拡張したものです。

 移動ノードAはモバイルエージェント広告メッセージを受信し、自分の居場所を確認したら、自分のcare-ofアドレスを入手しようとします。多分、DHCPサーバが稼働していると思いますので、そのDHCPサーバからcare-ofアドレスを取得して、これをホームエージェントに登録します。登録要求は登録要求(Registration Request)メッセージによって行います。ホームエージェントは移動ノードからの登録依頼を受信したら、ホームアドレスと気付けアドレスの対応関係を管理しているデータベース(バインディング、binding)を更新して、今後はホームアドレス宛のパケットを代理して受け取れるようにします。登録が終わったら、登録確認(Registration Response)メッセージを移動ノードに送ります。登録要求と登録確認にはポート番号434のUDPが使用されます。

※DHCPサーバが稼動していない場合は、ルータ広告メッセージの中のプレフィックス(サブネットのアドレス部)に自分でホスト部を付け足してIPアドレスを作成することになる。この場合には、自分で作成したIPアドレスがサブネットの中で重複していないかを確認しなくてはならない。このとき利用するのがGratuious ARPである。移動ノードは新しく作成したIPアドレスをGARPでサブネット内にブロードキャストする。既に、同じIPアドレスを使っているものがいれば、GARPの送信者に対して、ARP Replyを返す。ARP Replyがなければ、重複アドレスを持っているものはいないと判断する。

※ホームエージェントがホームアドレス宛のパケットを代理して受け取れるようにする仕組みは次のようになる。移動ノードが外部リンクに移動すると、そこで新しいcare-ofアドレスを取得し、ホームエージェントに登録依頼をするが、この登録依頼が新規登録なら、ホームエージェントはホームリンクに対して、ホームアドレスのMACアドレスがホームエージェントであるようなGARP(Gratuious ARP)メッセージを出す。これによって、ネットワーク(ホームリンク)内の(ルータを含めて)全てのノードがARPキャッシュを更新する。また、今後はホームアドレスへのARP要求に対してはホームエージェントが回答するようになるため、ホームアドレス宛のパケットをホームエージェントが捕獲することができる。

Gratuious ARP:通常のARPはターゲットとなるIPアドレスのNICのMACアドレスを尋ねる場合に利用するが、この場合のGARPはターゲットとなるNICのIPアドレスとそれに対応するMACアドレスの組を送信先のARPテーブルに追加させるために使用する。この場合には、移動ノードのホームアドレスに対応するMACアドレスをホームエージェントのMACアドレスにして、リンク内のノードのARPテーブルに追加させる。こうすると、移動ノードのホームアドレス宛に到達したパケットがホームエージェントに送られてくることになる。

 ホームエージェントはバインディングテーブルを確認し、宛先アドレスcare-of(NW2.20)、送信元アドレスHA(ホームエージェント)のパケットでカプセリングして送り出します。これを受信したフォーリンエージェントは、移動ノードAに転送します。

 今まで話してきた事例は、通信の途中で移動ノードが外部リンクに移動した場合についてです。これは通信の同一性の重要さを強調しようとしたためです。移動ノードは通信を始める前に、外部リンクに移動し、そこでcare-ofアドレスを取得して、ホームエージェントに登録を済ませてから、通信が始まる場合ももちろんあります。




3 Mobile IPv4の問題点

 郵便なら受け取ってそれでおしまいですが、TCP/IPの通信はそんなに簡単ではありません。更に返事を出さなくてはなりません。この返事の送信元のアドレスはどうしたらいいでしょうか。元々のアドレス、すなわちホームアドレスでいいでしょうか。これなら、対向ノードは通信の同一性を認識することが出来ます。

対向ノードは送信元のIPアドレスで通信を識別

ただし、これは通常の場合はうまく行きません。なぜでしょうか?多くの場合ファイアウオールにブロックされてしまいます。


多くのファイアウオールは送信元が外部アドレスのパケットを破棄

 多くのファイアウオールは送信元のアドレスが外部ネットワークになっているパケットを破棄するように設定されています(ingress filtering)。踏み台攻撃などを防ぐためです。では、care-ofアドレスを送信元にしたらどうでしょうか。今度は、対向ノードが通信の同一性を認識できずに通信は破棄されます。

※ingress filtering:送信元を偽装したIPパケットの転送を防ぐ手法の1つ(RFC2827)。自ネットワークからルータに入ってくるパケットに対して適用するルールで、送信元アドレスが自ネットワークのアドレスでないものをブロックする。

 送信元をもともとのホームアドレスNW1.10にしないと対向ノードBは接続の同一性を認識できません。しかし、そうすると今度はファイアウォールを越えることが出来ません。サーどうしましょうか?解決策は送信元をNW1.10としたパケットを、送信元を移動先のcare-ofアドレスNW2.20にしたパケットでカプセル化することです。このパケットは送信元が内部ネットワークになっていますので、ファイアウオールでブロックされることはありません。このパケットを受け取ったホームエージェントは転送先テーブルを参照して、カプセルを外して、中のパケットを対向ノードBに送信します。これを受け取った対向ノードは接続の同一性を認識できます。

ホームエージェント経由で返信

 これで目出度し目出度しと言いたいところですが、そうも言えません。移動ノードAがどんどん違う場所に移動した場合に、パケットは元いたところを辿ってホームエージェントまで辿り着き、最後に対向ノードの戻るということになります。例えば、静岡にいた移動ノードAが東京にある対向ノードBと通信をしていて、移動ノードがどんどん東京に近づいても、パケットの辿る経路はとりあえず静岡に戻ってから東京へという遠回りの経路を辿らざるをえないこととなります。これでは、時間がかかりすぎるという問題もありますし、関わり合う機器が多くなればそれだけトラブルに遭遇する可能性も高くなります。この問題の解決策は、移動後の最初の返信は遠回りしても仕方がないが、移動後最初の返信で新しいcare-ofアドレスを対向ノードに教えるというものです。こうすれば、直接care-ofアドレスを送信元にしても対向ノードは接続の同一性を認識できます。

2回目以降は送信元care-ofアドレスで

 移動後最初の応答だけはカプセル化(リバーストンネル)し、それ以降はcare-ofアドレスで直接通信する方法はそんなに簡単ではありません。この方法を使うためには、対向ノードBは移動ノードAのホームアドレスとcare-ofアドレスの関連付け情報(binding情報)を保持していなくてはなりません。これはキャッシュという方法で保持することになります。移動ノードAがどんどんサブネットを越えて行ったらどうでしょうか?覚えておくべきことがどんどん多くなります。移動ノードは多分Aだけではありません。移動ノードが多数になるとキャッシュの容量が問題となります。ただでさえギリギリのところで動いているWebサーバやストリーミングサーバにこのような能力を期待するのは難しいと思います。



4 Mobile IPv6

 Mobile IPv6とMobile IPv4の間に大きな違いはありませんが、小さな違いがいくつかあります。その1つは外部エージェント(フォーリンエージェント)がないということです。フォーリンエージェントがありませんので、care-ofアドレスの登録、パケット転送などを自分で行う必要があります。それから、制御メッセージはUDPではなく新たにモビリティヘッダを定義しています。制御メッセージ名も変わりました。それから外部ネットワークアドレスを送信元アドレスにしてもファイアウオールを越えることが出来るように修正を加えました。ホームエージェントのアドレスの自動発見等も新しくなっています。

 Mobile IPv6(RFC 3775)では、ホームエージェントと移動ノードはMobile IPv6に対応していることが前提です。対向ノードがMobile IPv6に対応している場合を経路最適化モードと言い、対向ノードがMobile IPv6に対応していない場合を双方向トンネルモードと言います。双方向トンネルモードはMobile IPv4とほとんど同じです。



5 Mobile IPv6 経路最適化モード

 経路最適化モードは移動ノードが異なるサブネットに移動した後も、ホームエージェント経由のトンネルを使わなくてはならないという問題を解決しました。

5.1 Mobile IPv4とMobile IPv6はほとんど同じ

 モバイルIPv6経路最適化モードも、大体モバイルIPV4と同じです。モバイルIPv6の動作概要は次の通りです。

 移動ノードは自分がどのサブネットにいるか常に気をつけていなくてはなりません。IPv6ルータはリンクに対してルータ広告(Router Advertisement、RA、ICMPv6タイプ134)(近隣発見プロトコル)を定期的に送信していますので、それを聞いて自分がどこにいるかを判断します。ネットワークに移動してすぐにルータ広告を聞くことができない場合は、ルータ要請(Router Solicitation、RS、ICMPv6タイプ133)(近隣発見プロトコル)メッセージを出して、ルータ広告を促します。ルータ広告にはIPv6アドレス自動設定に利用するリンクのプレフィックス(64ビット)が入っていますので、IPv6ではこれに自分のインターフェースID(64ビット)を追加して、IPアドレスとします。これでcare-ofアドレスができましたので、ホームエージェントに送信して登録を依頼します。

 移動ノードがホームエージェントを知らない場合はどうしたらいいでしょうか。移動ノードは通常の場合は、ホームエージェントを知っていますが、ホームエージェントが新しくなるなど特別の理由でホームエージェントを知らないという場合も考えられます。この場合はホームリンク内のエニーキャストアドレスにホームエージェント発見(探索)要求メッセージ(Home Agent Address Discovery Request Mesage、ICMPv6タイプ144)を送信し、ホームエージェントアドレス発見(探索)応答メッセージ(Home Agent Address Discovery Reply Mesage、ICMPv6タイプ145)を得ます。ホームエージェントアドレス発見(探索)応答メッセージにはホームエージェントの一覧が入っています。その中から1つを選び、登録要求(binding update、バインディングアップデート)パケットを送信します。care-ofアドレスはこの登録要求パケットの送信元アドレスとして送られます。

 ホームエージェントはホームアドレスとcare-ofアドレスの対応関係をバインディングキャッシュ(Binding Cache、対応関係管理のデータベース)に保管しています。ホームエージェントは移動ノードからの登録依頼を受信すると、バインディングキャッシュを更新します。もし、この登録依頼が新規の登録なら、ホームエージェントはホームリンクに対して、自分のMACアドレスを移動ノードのホームアドレスに対応付けるように広告します。この広告は近隣広告(Neighbor Advertiseme、ICMPv6タイプ136)によって行います。通常の近隣広告は要請(ICMPv6タイプ135)を受けて回答されますが、この広告は自主的な(unsolicited)なので、フラグフィールドのSフラグ(Solicited flag)は"0"にセットされます。これによって、そのネットワーク(ホームリンク)内のルータを含めた全てのノードは近隣キャッシュ(IPv4のARPキャッシュと同じ)を更新し、今後はホームアドレス宛のパケットは全てホームエージェントに送られるようになります。

 移動ノードの現在位置を知らない対向ノードはホームアドレス宛にパケットを送信しますので、ホームエージェントはこれを捕獲して、移動ノードに対してカプセリング(トンネリング)してパケットを送信します。

 ここまでは大筋ではIPv4とまったく同じです。ただし、探索や登録に使う手段がICMPv6になったので、用語が違っています。



5.2 Mobile IPv6がMobile IPv4と違うところ

 Mobile IPv6がMobile IPv4と違うのは大きく分けて3つあります。そのうちの1つは、対向ノードがMobile IPv6対応の場合(経路最適化モード)、対向ノードがバインディングキャッシュを備えていなくてはならないということです。

 対向ノードがバインディングキャッシュを備えていると、もしかしたら対向ノードは移動ノードのcare-ofアドレスを知っているかもしれません。この場合は、ホームエージェントを経由しないで直接パケットを送ってきます(経路最適化)。

 最適化経路を使って送られてきたパケットの宛先はcare-ofアドレスです。これは少し問題があります。なぜでしょうか?今まで、移動ノードは対向ノードと通信をしていて、通信の途中に外部リンクに移動したと考えてください。今までは、《ホームアドレスNW1.10+特定のポート番号》と《対向ノードのアドレス+特定のポート番号》の組(ソケット接続)で通信をしていたのに、自分への宛先が移動先のcare-of(NW2.20)となっているのですから、通信の同一性の判断ができなくなってしまいます。これでは新しい接続要求なのか、今までの接続の続きなのか分かりません。ここで違いの2つ目です。Mobile IPv6では拡張ヘッダの経路オプションを付けて、そこにホームアドレスを入れます。パケットを受け入れた移動ノードはパケットの宛先アドレスをオプションフィールドのホームアドレスで読み替えて通信の同一性を認識することができます。経路オプションはIPv6拡張ヘッダのルーティングヘッダによって行います。ルーティングヘッダは現在タイプ0とタイプ2が定義されています。タイプ0は一般的なソースルーティング用です。タイプ2はMobile IPv6で使用するために特に定義されたもので、アドレスを1つ指定することができます。
 移動ノードから対向ノードへの返信のパケットも同様です。送信元のアドレスにcare-ofアドレスをオプションフィールドにホームアドレスを付加して送信します。対向ノードがMobile IPv6対応ならば、このパケットを受け入れることができ、たとえ移動ノードがホームリンクにいるときに始まった通信だとしても、そのまま通信の同一性は維持されます。対向ノードがMobile IPv6対応でないときは、対向ノードはこのパケットを拒絶しますので(ICMPv6パラメータ異常)、このよう場合はホームエージェントにトンネルし、そこから転送してもらいます。また、送信元アドレスが内部のcare-ofアドレスになっているのでファイアウオールのフィルタリングルールでブロックされることもありません。

 対向ノードがバインディングキャッシュを持っていないと気づいたときは、移動ノードは対向ノードに対してバインディングキャッシュを送信します。

FWと対向ノードの上位層をだます





6 Mobile IPv6のセキュリティ機能

 3つ目の違いはMobile IPv6のセキュリティ機能です。移動ノードが行うバインディングキャッシュは何らかの方法で保護されなくてはなりません。これを無防備なまま放置すると、無関係なノードの不正なcare-ofアドレス通知によりパケットを横取りされる可能性があります。

不正ノードからのbindingアップデートで騙される
 

 移動ノードからホームエージェントへのbinding update通知はIPSecのESPで保護し、移動ノードと対向ノードの間のリターンルータビリティ(Return routability)という新しい仕組みで保護します。IPSecについてはIPSecの章をご覧ください。ここでは、リターンルータビリティについて説明します。

 移動ノードは元々ホームエージェントのリンクを本拠地とするので何らかの信頼関係があると考えられますが、移動ノードと対向ノードの間は全くの赤の他人の関係ですので信頼関係はありません。そこで、何らかの形で信頼関係を構築します。これが、鍵の交換です。鍵を交換することで、これからはこの鍵を使って認証をしましょうということになります。この鍵の交換の手順をリターンルータビリティと言います。移動ノードはバインディングアップデートに認証鍵を添付して、対向ノードに送信します。対向ノードは認証鍵を検証し、正しければバインディングアップデートを受け入れます。

認証鍵付きのバインディングアップデート

 鍵の交換の手順はちょっと複雑です。移動ノードから直接対向ノードへのルートと、ホームエージェントを経由したルータの2つのルート経由で、共通鍵を生成するためのデータの送信を依頼します。直接依頼するためのメッセージをcare-ofテスト開始メッセージと言い、ホームエージェント経由での依頼をホームテスト開始メッセージと言います。

2つのルートで鍵生成の情報を要求

 2つのルート経由で鍵を生成するための情報を送ってくれるように依頼します。

2つのルートで来た鍵生成情報から鍵を生成

 2つのルートから来た鍵生成情報からバインディング情報を管理するための鍵を生成します。





更新履歴

2016/02/25 作成


























 ページの先頭