今年もエープリルフールRFCが発行された。今回は、インターネット業界の最大の関心事が盛り込まれた2つのエープリルフールRFCを見ながら、IPv4枯渇問題、IPv6移行問題の最新動向を紹介する。
RFC5513
今年発行されたエープリルフールRFCの一つ目は、「RFC5513 – IANA Considerations for Three Letter Acronyms」(3文字頭字語(TLA)に関するIANAの考察)である。3文字頭字語では、例えば Three Letter Acronyms を TLA と略すわけだが、RFC 等の文書でこの TLA が増えすぎて弊害が出ているという内容である。
RFC5513で注目したい点は、枯渇がテーマになっているところである。TLA の世界でも余りが少なくなってきていて、このままでは枯渇してしまうと予測している。枯渇すると、新しい TLA が作られなくなるか、1つの TLA に複数の言葉を割り当てることになり、とても混乱することになる。
結局、新しいレジストリシステムを作って TLA を管理することを提案しているわけだが、一歩インターネットの世界を出ると、ぶつかっている TLA はざらにあるし、厳密な意味では TLA ではない3文字略語もたくさんある。例えば TCP と言えばインターネットの世界では言うまでもなく Transmission Control Protocol だが、空港名を表す3文字略語では TCP はエジプトのタバ国際空港になる。せめてインターネットの世界だけでも一貫性を保とうということになるが、実際問題としては徒労に終わるだろう。
RFC5514
二つ目のエープリルフールRFCは、「RFC5514 – IPv6 over Social Networks」(ソーシャルネットワーク経由のIPv6通信)である。なかなか普及が進まない IPv6 ネットワークも、ソーシャルネットワークを活用すれば飛躍的に普及するという内容である。
IPv6の普及のためには、IPv6 over IPv4トンネルが有効だろうといわれてきた。しかしそれを使っても普及しないので、多くのインターネット関係者が頭を悩ませている。そこで、SNS の感覚で自分と友人のルータ間で IPv6 の P2P リンクを確立することで、巨大なIPv6メッシュネットが作れるだろうというのが、この RFC の提案である。
草の根的に IPv6 ネットワークを作ろうというこの試みは、インターネット黎明期の活動に似ている。実際、この RFC に書かれているプロトタイプでの実証例では、例えば ping の応答に二日以上かかったり、traceroute するのに一週間以上かかったりしている。かつての電話回線を使ったひ弱なインターネットが戻ってきたようで懐かしさすら感じる。
NTT閉域網問題、NAT444、NAT66
さて、エープリルフール RFC でも「枯渇」「IPv6」がキーワードになっているが、IPv4 枯渇対応、IPv6 移行は進んでいるのだろうか。実は進み始めた途端に課題がたくさんあることに気づかされたというのが正直なところだろう。
まずは有名なNTT閉域網問題。NTT東西が展開している NGN をISPがアクセス回線として使う場合に、IPv6 のマルチプレフィックス問題が起こるというものだ。元はというと、NGN 以前にフレッツ網の時代から、NTT東西では閉域網に IPv6 グローバルアドレスを使ってきた。その当時はその閉域網しか IPv6 ネットワークが無かったので問題にならなかったが、いざ IPv6 をインターネットとして使おうとした時に大きな障壁となってしまった。技術的にはトンネルを使った案がいくつか提案されているが、結局どの方式を使ってこの問題を克服するかが決めきれずにいる。
続いてはキャリアグレードNAT(CGN)の問題。まずは名前がよくないということで Large Scale NAT(LSN)と呼ぶようになったようだが、こちらも仕様が固まりきっていない。現在は NAT444 として、2段NAT構成をとり、中間層で使う IPv4 グローバルアドレスをどうするかという議論が進んでいるところだ。
NAT66という提案もある。これは IPv6 にも NAT 機能を導入して、プライベート IPv6 アドレスが使えるようにしようという拡張である。多くのインターネット関係者は、IPv6 が持つ単一のグローバルアドレスによる P2P 通信の優位性を主張している。一方、ネットワークを NAT で守る仕組みに慣れてしまった企業ユーザからすると、NAT66 は確かに魅力的に見える。例えば企業が上流 ISP を変更すると、社内で使っている IPv6 グローバルアドレスも全てリナンバーする必要があるわけだが、NAT66 を使うと、少なくとも社内LAN 内はリナンバーの必要が無くなる。NAT66 に関する議論はまだ先が長そうだ。
IPv6 アドレス表記についても、新しい提案がある。例えば IPv6アドレスでは、ゼロが続く部分を :: で省略することができる。しかし、どの部分をどこまで省略するべきかというコンセンサスがないため、同じアドレスを様々な表記で記述されてしまい、その同一性が人間には確認しにくい。提案ではこれを含めて、なるべく曖昧さを排除して表記が一意になることを求めている。
長い黎明期が続くIPv6移行
上で挙げた課題を見ると、「今頃なにやっているんだろう」という疑問が沸く。IPv6 は 1994 年には IETF 標準化原案が出され、1995年には RFC 1883 として登場している。その後各種実験ネットワークも作られ、商用サービスも始まっている。しかし15年の年月を経て、IPv4アドレス枯渇時期を間近に控えながら、課題山積である。
過去ばかり振り返っても仕方がない。それよりも出てくる課題を解決してゆくことに傾注すべきだろう。CGN、LSN、NAT444、NAT66 などのバズワードが生まれてくるのは、その分野から何か新しいものが生み出されようとしている兆しだと考えたい。
そして、これらのバズワードが生まれ続ける限り、IPv6への移行は相変わらず黎明期と位置づけられるだろう。多くの人々は安定したネットワーク基盤を望んでいるかもしれないが、実態として運用実績がないのだから仕方がない。しかし、黎明期を経ずにいきなり成熟したものが生まれる道理もない。インターネット世代の我々は、今一度インターネットの原点に立ち戻り、IPv6インターネットを成熟したものに仕上げていく責務があるのではないだろうか。
本文中のリンク・関連リンク:
- 2009年のエープリルフールRFC は以下の二つ。
- 「RFC5513 – IANA Considerations for Three Letter
Acronyms」
セキュリティに関する考察で、暗号アルゴリズムの MD5 を “the well-known Maybe-Decrypted-Deciphered-Decoded-Disambiguated-and-Degraded algorithm” としている辺りがおもしろい。 - 「RFC5514 – IPv6 over Social Networks」
IPv6 が普及しないというネタなので、IETF 内でも自虐的な空気があるのではないかと想像します。
- 「RFC5513 – IANA Considerations for Three Letter
Acronyms」
- Large Scale Nat に関連した IETF での主な議論は下記の通り。いずれも日本からの提案である。
- NAT66の提案は、 「IPv6-to-IPv6 Network Address Translation
(NAT66)」参照。
賛否両論ある中、IAB(Internet Architecture Board)の見解として、「IAB Thoughts on IPv6 Network Address Translation」が提示されている。ここでは、リナンバリングを避けるためにPI(プロバイダ非依存)アドレスの利用を推奨し、その場合に発生するルーティングテーブル爆発問題を今後解決してゆくべきだとしている。 - IPv6アドレス表記への提案は、「A Recommendation for IPv6 Address Text Representation」参照。