長野の空を飛ぶLISP実験

2010/9/10-1

Lispと言えば言語を連想される方々も多いと思いますが(参考1、参考2、参考3)、最近はLISP(Locator/ID Separation Protocol)というプロトコルがIETFで盛り上がっています。 Locator/IDをテーマとしているクセに、そのプロトコルのロケータである筈の名前が恐ろしく紛らわしいという点に微妙な疑問を感じつつも、このLISPは面白いプロトコルだと思います。

LISPは名前の通り、ロケータとIDを分離するものです。考えの根本としては、先日紹介したNSFの新プロジェクトで研究されているNDN(Named Data Networking)/Contents Centric Networkingに近いとも言えそうです(参考：未来インターネットアーキテクチャ)。

しかし、LISPとNDNの大きな違いは、かなり先の未来を想定しているNDNと比べるとLISPの方が地に足がついた感じであり、今のインターネットアーキテクチャ上で実際に利用可能に見える点です。今のところLISPはRFCになっておらず、その研究活動も大規模とは言えませんが、運用に基づいた発想で構成されていて将来性があるように感じました。

LISPとは

LISPとは、LocatorとIDを分けるプロトコルです。現在のインターネットでは、IPアドレスはルーティングを制御するためのロケータであり、IDです。今のインターネットでは、このロケータとしての役割を実現するために、IDであるIPアドレスを使います。そのため、たとえばマルチホーミングやトラフィックエンジニアリングを行うために、一つの組織から細かい経路を連発してしまい、大きなIPアドレスブロックを持っていても細切れの経路を流さざるを得ない状況が生まれます。

これを解決するために考案されたのがLISPです。 LISPでは、現在のインターネットと相互通信可能なゲートウェイとなるルータが設置されます。インターネット側に居るユーザから見るとLISPが使われているかどうかはわかりません。

二つに分かれたIDとLocatorは、それぞれEID(End Point ID)とRLoc(Routing Locator)になります。インターネット上のユーザ(「ユーザ」がインターネット側に居てLISP側の「サーバ」と通信をするという想定で説明)に見えるのはEIDです。ユーザがDNSで名前解決を行うと、対象とする宛先のEIDが返ります。このEIDはIPアドレスですが、ユーザ側は通常通りにこのIPアドレス宛に通信を行います。

このIPアドレスで待っているのはLISPのProxy Routerです。 LISP Proxy Routerは、受け取ったIPアドレスの宛先アドレスを見て、RLocへと宛先を変換して中継します。 RLocは、LISP RouterのIPアドレスになります。 RLocは、LISP Proxy Routerからのパケットを受け取ると、先頭にあるLISP情報部分を解釈し、中からIPパケットを取り出します。

このように、仕組みとしてはモバイルIPに似ている部分があります。

こんな感じ

文章だけの説明では、ちょっとわかりにくいので、今度は、仮のIPアドレスを含めて考えてみましょう。このようにLISP Proxy Router、LISP Router A、LISP Router Bがあったとします。

このような状態のとき、インターネット上のユーザが198.51.100.1と通信するときを説明します。 LISP Router Aに接続されたネットワーク内では、198.51.100.0/26が利用されていますが、このネットワークに関する経路はインターネットに流れていないので、外部から直接198.51.100.0/26へと通信を行うことは出来ません。 LISP Router Aの裏側にあるネットワークは、ある意味インターネットから断絶された状態です。インターネットとの接続が行われているのが唯一LISP Router Aのインターネット側インターフェースで、そこには192.0.2.254のIPv4アドレスがついています。

さて、このような環境でインターネット上のユーザが198.51.100.1と通信をしようと思ったとき、ユーザから198.51.100.1へのパケットは、LISP Proxy Routerへと向かいます。これは、LISP Proxy Routerが198.51.100.0/24の経路を広告しているからです。

LISP Proxy Routerは、ユーザからのパケットを受け取ると、198.51.100.1という宛先を見て、LISP的に持っているマッピングテーブルからLISP Router Aへと送れば良い事を知っています。そこで、LISP Proxy Routerは、ユーザから受け取ったパケットをカプセル化しつつ、LISP Router AのRLocである192.0.2.254へと送ります。

LISP Router Aは、LISP Proxy Routerから受け取ったパケットの中から198.51.100.1へのパケットを取り出し、自分が接続されている198.51.100.0/26のネットワーク内へと転送します。 198.51.100.1からユーザへのパケットはLISP Router Aを経由して直接ユーザのIPアドレスへと送信されます。

これが198.51.100.1への通信が行われるときですが、今度は198.51.100.129への通信を考えます。 198.51.100.129はLISP Router Bに接続されています。基本的な流れはLISP Router Aを経由するときと同じですが、LISP Proxy Routerが転送先のRLocとして利用するIPv4アドレスがLISP Router Bの203.0.133.3となる点が大きく異なります。このように、実体が全く別々に存在していても、LISP Proxy Routerによって経路がまとめられているように見えるのがLISPの特徴です。

インターネット側から見れば、外部から見ると198.51.100.0/26と198.51.100.128は同じ場所にあるように見えてしまいますが、実際には二つは全く別の場所にあります。これは、LISP Proxy Routerが、198.51.100.0/24のフリをしつつ経路を広告しているからです。

WIDE合宿での実験

長野県で現在行われているWIDE合宿でLISPの運用実験が行われているようです。

WIDE合宿では、毎年合宿会場までWIDE内部ネットワークを持って行きます。昔は専用線を引いていましたが、最近はIPトンネルを使っていました。今年は、IPトンネルではなく、LISPを利用してWIDEネットワークを合宿地に持って行ったようです。

今回のWIDE合宿での構成では、203.178.156.0/22と2001:200:0:ff00::/56の二つの経路がAS2500のWIDE Internetから広報されました。それらのIPアドレス宛のパケットは、WIDE Internetへ向かいます。

一方、長野のWIDE合宿現場でPPPoEでOCNに接続されています。長野でのOCNへのPPPoE接続のIPアドレスが、今回のLISP構成ではRLocになります。

WIDE合宿内部のユーザは、203.178.156.0/22のIPアドレスを機器に設定しています。しかし、インターネット的には、長野で行われているWIDE合宿の203.178.156.0/22は長野にはありません。

で、何故通信が行えるかというと、WIDE Internetに設置されているCisco 1841でRLoc宛パケットを送信して、長野のCisco 2800がRLoc宛のIPヘッダとLISP情報を使って「脱皮」させるからです。

このように、一見２カ所に203.178.156.0/22が存在しているように見えますが、インターネット的にはCisco 1841がある位置に、そのネットワークがあるようにしか見えません。

衛星回線を選んでLISPでパケットが空を飛ぶ

今回のWIDE合宿でのネットワーク構成では、Flet's光と衛星回線の２種類が用意されました。ユーザは、Webからリクエストを出すことによって、衛星回線側を通るように各自のホストを設定可能でした。

申し込みが行われたユーザの通信を衛星回線経由にする方法として、そのユーザのIPアドレスに対する/32のホストルートを使う方法がとられました。

個人的な感想として、この実験が面白いと思ったのは、DHCPプールを利用しているユーザのトラフィックをリアルタイムに衛星回線に切り替えたり、戻したりをLISPで出来るという点です。しかも、全員が同じセグメントにいつつ、LISPの操作だけで/32のホストルートとして制御出来ちゃう点も面白いと思いました。

利用されている衛星回線の写真をもらいました。こんな感じです。

昔は衛星回線の方が大容量だったのですが、フレッツ光が普通になってしまった昨今では、ワザワザ遅い衛星回線を選択する意味は実はあまりありません。しかし、現地では、割とベテランな方々が懐かしんで衛星回線側を利用されてたとのことでした。

LISPは実装が非常にシンプル

LISPは非常にシンプルです。特定の入力IPアドレスに対応する宛先へとパケットを中継するだけです。これを行うためのマッピングテープルを保持や更新がLISP上で行われます。

そのシンプルさから、IPv4→IPv6も可能ですし、IPv6→IPv4も可能となっています。中継を行うList Proxy Routerはマッピング情報からRLocの宛先を選ぶだけで、LISP Routerは受け取ったRLocから実際のIPパケットを脱皮させるだけです。

一見複雑に思えますが、実は実装そのものは非常にシンプルなのは利点だろうと思います。

IPv4アドレス枯渇後に使われる？

元々は経路表をシンプルにして世界に流れる経路数を抑制するために考慮されたLISPですが、実はIPv4アドレス枯渇に伴うIPv4アドレスの効率的な利用に使えるかも知れないと思いました。

長い間利用され続けたネットワークでは、サブネット内でIPアドレスの利用が虫食い状態になっていることがあります。たとえば、コロケーションサービスなどとの兼ね合いで、容易に立ち入れない場所に割り当てられたサブネットがこのように虫食い状態のIPアドレス利用であった場合などにLISPが使えそうです。

LISPは、IPアドレス一つからでも利用可能なので、虫食い状態のIPアドレスを受け取れるようにLISP Proxy Routerを設置することで、今まで利用が難しかったIPアドレスを使えるかも知れません。

さらに、IPv4アドレス枯渇後にIPv4アドレスを移転せずに他者へと「貸し出す」方法として使えるのかもと妄想しました。

これが流行るとAkamaiは苦労する？

LISPだけではなく、Google Public DNSでもそうですが、このような仕組みが増えて行くとAkamaiのような手法を利用したCDNの運営は難しくなるのかも知れません。

LISPを利用している相手との通信では、IPアドレスとして見えている「ユーザ」の実体が何処にあるかが解らず、効率の悪い配送経路を選択してしまう可能性があります。

LISP＋エニーキャストが実現すると結構使えそう

「LISP Networking: The PETR Anycast prefixes」を見ると、LISPをエニーキャストと組み合わせる方法も考えられているようです。

たしかに、エニーキャストと組み合わせると有効である気がします。 LISPサービスを世界的に提供するような通信事業者が登場すれば、ポータブルなサービスとして利用したいと思う組織も登場するかも知れません。

たとえば、入り口は世界的な通信事業者が提供するLISPで、裏で別の事業者がCDN業を営むようなモデルが将来登場する可能性を妄想しました。エニーキャストって巨大なネットワークを自前で持っている事業者以外は実現が困難だと思いますが、LISPとエニーキャストを組み合わせると、世界的なネットワークを持つ通信事業者がエニーキャストの卸売りみたいなことが出来そうです。

さらに、接続してくるクライアントの位置に応じてRLocの位置を変えたりとかできたら、AkamaiのようなCDN構築への敷居が劇的に下がるかも知れません。そうなったときに、CDNの世界は今とは違った方向へと向かうのではと、妄想は膨らみます。

でも危ない側面もありそう

とはいえ、危なさも感じます。これが普及すると、特定のホストを狙って経路ハイジャックを実現できる土壌を作ってしまいそうです。

今の運用では、BGPハイジャックが発生するとネットワーク単位でハイジャックされるので、比較的気がつきやすいのですが、LISPで小規模なネットワーク単位やホスト単位でハイジャックされたら気がつきにくいかも知れません。

このような懸念があり、この点に関してはIETFの標準化活動でも議論になっているようです。

もうちょっと知りたい人は、こちらを

今回は、説明が長くなり過ぎてしまうので「マッピングテーブルを作る方法」や「ingress/egressに関する詳細な動作」に関しては割愛しています。 MS(Mapping-Server)、MR(Mapping-Resolver)、ITR(Ingress Tunnel Router)、ETR(Egress Tunnel Router)、PITR(Proxy Ingress Tunnel Router)、PETR(Proxy Egress Tunnel Router)など実は色々あります。

もうちょっと詳しく知りたい人は、こちらの公式サイトをご覧下さい。色々な資料が公開されています。

「http://www.lisp4.net/, LISP Networking: Topology, Tools, and Documents」

Googleで行われたGoogle Tech Talkのビデオもお勧めです。

LISP Part 1: Problem Statement, Architecture and Protocol Description

LISP Part 2 - Mapping Database Infrastructure and Interworking

LISP Part 3 - Deployed Network and Use-Cases

最後に

今のところ地味な感じがするLISPですが、個人的には結構面白い技術だと思いました。ただ、ニーズというか、LISPによってできることの嬉しさというところを理解してもらうまでが、色々と大変なプロトコルかも知れないと思った今日この頃です。

(とはいえ、冗長構成にすることを考えると結局は個別に経路を流したくなって行って、LISPを使っても経路数が少なくならないとかありそうですが。何か当初の目的とは違った発展のしかたをしそうな予感も微妙にします。)

おまけ：WIDE合宿実験の話を聞いて10年前を思い出した

今回のWIDE合宿での実験の話を聞いて、そういえば、昔、WIDE合宿で色々な実験を行ったのを思い出しました。

当時、DiffServのポリシー制御に関して研究を行ってました。最終的には博士論文で書いたのは、DV/RTPによる映像転送やTCP親和性に関してなので、博士論文に関連する研究にはなりませんでしたが。。。 (非常に恥ずかしい中身の学部時代卒論はRSVPのポリシー制御でOOPSを実装してました。)

WIDE合宿でのそれぞれの実験では、私は主にCOPS(Common Open Policy Service)による制御部分を担当してました。学生時代の論文を見ると色々と恥ずかしいのですが、、、、まあ、いいやという感じで公開してみます。というか、昔の自分の写真が若い。。。

10年前にやっていたのは以下のようなことです。

2000年春のWIDE合宿での実験は、合宿参加者全員にトークンを渡しWebフォームから帯域申し込みが出来るようにしました。合宿会場からの1.5Mbps回線上をDiffServでクラス分けして、ユーザが申し込むとセッションが優先Queueへとマップされ仕組みを作りました。

"Field-Trial of dynamic SLA in Diffserv network", Naoto Morishima, Akimichi Ogawa, Keijiro Ehara, Youki Kadobayashi, QofIS'2000

2000年秋の前回は回線上の帯域だったのを、衛星回線と地上回線を選択できるようにしました。 Webフォームから特定セッションのQoS申請を行い、そのトラフィックがどちらの回線を通るか設定可能になるというものです。 Web経由でQoS申請が行われた通信に対しては、DiffServを利用してDSCPにマークがつきました。実験では、そのマークを見つつ、出力先インターフェースを決定するルータを実装して運用しました。

"Preliminary Field-Trial for QoS Routing and Dynamic SLA", Naoto Morishima, Akimichi Ogawa, Hiroshi Esaki, Osamu Nakamura, Suguru Yamaguchi, Jun Murai IEICE: Special Issue on Internet Technology(2001/1)

2001年春の実験では、NATセッションに対する予約も可能にしました。 NAT変換テーブルを読み込んで、プライベートIPアドレスでのQoS申請をグローバルIPアドレスで反映するというものです。この実験のときにQoS実現のために利用したのがMPLSでした。

当時のWIDE報告書内の該当部分