IETF homenet co-chair, Mark Townsley氏インタビュー(4)

2013/5/13-1

Q: そのようなネットワークを実現するには、ホームネットワーク内の各ホストがIPv6ソースアドレス選択、next hop選択、DNSキャッシュサーバ選択が必要になると思われます。これらの問題を解決するために、どのようなdraftが提案されていますか?

では、ひとつずつ説明させて下さい。

ホストに二つのアドレスがついた場合、どのアドレスを使うのかを選択しなければなりません。 とりあえずは、「良い」アドレスを選ぶことができるという前提で話をさせて下さい。 「良い」が何であるかに関する定義も既にあるものとします。

ここら辺の話は、homenetワーキンググループの範疇ではなく、6man(IPv6 maintenance working group)もしくはmif(multiple interface working group)ワーキンググループの範疇になってきます。 明確にhomenetワーキンググループの範疇なのが、ホストが送信元アドレスを選択したうえでパケットを送信したとして、そのパケットに対して送信元+宛先でのルーティングをホームネットワーク内で行う部分です。 BCP38フィルタリングがあるため、正しい出口からパケットを出してあげる必要があります。

関連するドラフトとして、Ole Troan氏とLorenzo Colitti氏によるもの(http://tools.ietf.org/html/draft-troan-homenet-sadr)や、Fred Baker氏によるもの(http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment)があります。

この二つのドラフトのうち、最初のドラフトはマルチプレフィックスマルチホーミングを行ううえで最低限必要な内容を示した基本的なもので、我々はそこに記述されていることを正しく把握してますし、動作しているコードもあります。

Fredはもうちょっと踏み込んでいて、「DSCPやフローラベルに応じたルーティングをした方が良いのでは?」と提案しています。 そういった話をルーティングプロトコルに入れ始めると、、、複雑化してしまって人々が離れて行く要因になり得ます。 それが有用となる理由も理解できますが、問題はコミュニティがそこまで深入りすることを許容できるかどうかだと思います。 これからの議論ですね。

送信元+宛先ルーティングが必要であるという点に関しては、明確なコンセンサスが成就していると私は考えています。

さらに次に考える必要があるのが、multiple provisioningもしくはmultiple configuration domainです。 それはIETFでの最近の議題でもあります。 昔からmifやdhcpワーキンググループで議論されてきた内容でもあります。 新しいエリアディレクターであるTed Lemon氏が解決したいと考えている課題です。 この話は前回のIETFでかなり議論してます。 先週金曜日の午後も、この話をしてました。

そして、どのDNSサーバを使うかの問題があります。 たとえば、ここにあるiPhoneですが、これには複数のインターフェースがついており、各インターフェース毎に別々のDNSサーバを取得していますが、どれをどう使うのか?というような話です。 特に、そのうちのどれかが特別なスコープを持ってしまっている場合は、この問題が顕著になります。 この点に関しては、日本に興味深い事例がありますよね(笑。 まあ、他の場所でも同様の話はありますが。

これは、前回のIETFでのいわゆる「hallway(廊下での雑談/ネゴ作業)」で話ていたことです。 この話題は徐々に盛り上がりつつあると感じています。 もしかしたら、mifワーキンググループのアーキテクチャとhomenetアーキテクチャの組み合わせを実現できるかも知れません。 ただし、mifは基本的に、複数のインターフェースを持つために複数のレイヤー3設定を受け取る単一のデバイス、という環境にフォーカスしています。 これに対応するのは、アプリケーションかミドルウェアです。

homenetで私がIPv6でやりたいのは、各アップリンクが各種情報を持つことです。 たとえば、DNS、NTPサーバなどがあり得ますし、3Gや4G、有線、光ファイバなどのインターフェースタイプも考えられます。 ドイツテレコムや他のいくつかの組織が、プレフィックスごとに色付けされた任意のラベル(colored arbitrary label for this prefix)に興味を示しています。

ということで、ホームゲートウェイが収集した情報は、プレフィックス単位での収集となります。 そして、そのプレフィックスを家庭内で広告すれば、そのアップリンクから数ホップ離れていたとしても、プレフィックスに紐づいた情報から、そのアップリンクに関する情報を知ることができます。 たとえば、それがwalled gardenであるかないか、関連するDNSサーバは何かなどの各種情報が全てがIPv6プレフィックスというひとつのものに集約されます。

こういった情報がホストまで降りて来たうえで、ホームネットワークが適切にパケットをルーティングできれば、ホストがどの送信元アドレスを選ぶか次第ということになります。 ホストは、各プレフィックスレンジからのアドレスがあれば、個別の設定を活用することが潜在的に可能となります。 そして、それはレイヤー2インターフェースの数に関係無く実現可能です。 我々は、レイヤー3の設定情報をレイヤー3に持ってきました。

本来はレイヤー3情報のはずなのに、レイヤー2情報と紐付けられている場合、話はもっと難しくなります。 たとえば、テザリングの有無などがあげられます。 マルチプレフィックス/マルチホーミングのアーキテクチャによって、マルチコンフィギュレーションを正しくできるかも知れません。

(続く:次へ)

最近のエントリ

過去記事

過去記事一覧

IPv6基礎検定

YouTubeチャンネルやってます!