ニュースレターNo.57/2014年8月発行

IPv6関連WG報告

第89回IETFにおけるIPv6関連の話題として、会場ネットワークの状況を報告します。また、6man WG、v6ops WG、softwire WGの概要についても報告いたします。

IETF会場ネットワークでのIPv4アドレス枯渇

IETF会議では古くからIETF会議会場において、インターネットアクセス環境が提供されています。前回の第88回IETF会議から、IPv4アドレスが割り当てられない事態を盛んに経験するようになりました。

IETFでは、基本的にグローバルアドレスが供給されます。アクセスができないサイトに気づいて調べると、IPv6アドレスはもちろん付与されますが、IPv4は、自己割り当てアドレス、すなわちリンクローカルアドレスしか付与されていません。事実上のIPv6 onlyな状態と表現してよいと思います。これは、少し早く訪れた未来と言えるでしょう。

実際にどのような体感になるかを紹介しましょう。IETF会議関係の資料へのアクセスは問題なくできます。たまに、Facebookをのぞいて見ることも普通にできます。会議中に何か調べたくなり、Googleで検索すると普通に結果が返ります。Wikipediaで詳細を読むこともできます。しかし、他の検索結果にアクセスしようとしたときに、タイムアウトになります。おかしいと思って調べてみると、IPv4アドレスが割り当てられていないことに気づきます。

調べると、IPv4アドレスの総量は、1人当たり2個無いほどでした。今時の参加者は、PCとスマホの双方を持っている人が少なくありませんので、あっという間に、IPv4アドレスが無くなってしまうようです。特に、スマホは常時電源が入っていますので、IPv4アドレスを掴みっぱなしになるようです。このため、お行儀よく、アドレスを解放するような実装だとアクセスできない事象が起こりやすいようです。

実際にこのような環境で過ごしてみると、IPv4でしか提供されないサービスにはアクセスできませんので、存在しないのと同然です。接続環境によって、アクセスできたりできなかったりという事態が起これば、確実につながる、すなわち、IPv6も提供されるサービスが利用者から選択されることは間違いないと思いました。

また、VPNが利用できないのは、強いストレスになりました。業務に支障が出かねないわけです。緊急案件の対応中に、IPv4アドレス枯渇に偶然遭遇するということも、想像したくありませんが、起こり得る状況になったと考えるべきでしょう。リスク管理として考えておくべきテーマになるかもしれません。

IPv4アドレス枯渇とはどのようなものかは実体験が伴わないと、なかなかピンと来ないと思います。疑似的にこのような環境を作ってみることも可能でしょう。案外、IPv6だけでこれだけできるんだと驚かれるかもしれません。

私は、このような経験を通じて、筆者が提案しているSA46Tを用いれば、その場のアクセス環境がIPv6 onlyであっても、IPv4グローバルアドレスを提供するサービスや、NAT経由でIPv4プライベートアドレスを供給するサービスなどを提供できるなど、さまざまなことを考えさせられました。

写真:Meetechoの画面 — ● IETFではMeetechoなど、さまざまなリモート参加の手段が用意されています

無線LAN環境での隣接探索プロトコルの問題についての議論(6man, v6ops)

今回、IPv6基本仕様のメンテナンスを行う6man WGおよびIPv6運用を扱うv6ops WGにて、この無線LAN環境での隣接探索プロトコルの問題がテーマとして取り上げられました。

隣接探索プロトコル(Neighbour Discovery Protocol)は、アドレス解決やアドレス自動生成などを実現するもので、IPv6の特徴です。アドレス自動生成はIPv6の特徴ですし、アドレス解決も、IPv4ではリンク種別ごとに定義される非IPプロトコルであったものを、IPプロトコルとして汎用化したものです。このプロトコルの初版はRFC 1970として1996年に発行されましたが、この当時、無線LANは存在しませんでした。私の記憶では、無線LANが初めて用いられたのは1999年11月のIETF会議でした。RFC発行の3年後です。

さて、このような無線LAN環境での問題が初めて指摘されたのは、2011年に開催された、IAB Smart Object Workshopだそうです。この報告は、RFC 6574にまとめられ2012年に発行されています。具体的には、バッテリーの消費を抑えるため、“sleep”する、小型で、低価格かつバッテリーだけで動作するノードの存在です。

隣接探索プロトコルではマルチキャストを多用します。例えば、ルータがRAをマルチキャストで送信すれば、その配下のホストはこのメッセージのみでルータのアドレスを学習できます。IPアドレスとMACアドレスの対応表であるネイバーキャッシュ(IPv4ではARPテーブル)も、他のノード間のマルチキャストでやり取りされる通信を見て学習します。このような、マルチキャストを用いるメリットは、パケット数の削減です。マルチキャストにより、学習すべきデータを共有し、それにより、学習の必要性そのものを減らし、問い合わせのパケット送信を削減するのです。

ところが、IETFのホテルで提供されたWi-Fiによるアクセス環境での測定結果では、IPv6パケットの内、75％がマルチキャストで、その内、mcast NSが30％で、さらにその内訳は、ホストからルータへのNSが39％、ルータからホストが30％とのことです。マルチキャストパケットの削減効果も、学習効果もあまり得られていないと評価して良さそうです。

対策としては、マルチキャストをユニキャストに置き換える、送信間隔を長くする等が話し合われました。隣接探索プロトコルは汎用化を目指していますが、リンクの特性に最適化するという方向性の可能性もあり得ると感じました。