インターネット最前線

IPv6: The final frontier

註: このhtmlファイルは「bit」96年10月号(共立出版)に 掲載した記事の原稿を、編集部の許可を得て公開しているものです。

図版やフォーマットは当然ながら雑誌掲載版と若干異なります。 また、執筆時(96年8月あたり)の状況に基づいて書かれているので 若干話題が古くなっていたりする可能性があります。 なるべく直したり補足したりするつもりではいますので お気づきの点がありましたら御指摘ください。

IPv6とは

アドレス空間の不足

32bitぶん、すなわち43億台の計算機ぶんのアドレス空間があるとはいえ、 残念ながらIPv4アドレスの利用効率は100\%とは程遠くなっています。 また、ここ数年のインターネットブームによってインターネットに 接続される計算機は年に2倍のペースで増えています。 今年あたりは3倍とか4倍のペースになっているでしょう。 このため、ラフな計算でいくと2010年頃にはIPv4アドレスが足りなくなる 計算になっています。

実際の利用状況と仕様のひずみ

IPv4は1970年代に定められたプロトコルです。20年以上も経てば 社会の状況が変わるのは当然で、IPv4の利用者は少数の研究者から ちょっと進んだ一般市民へと移行しています。 このまま進めば2000年頃にはごく普通のおじいちゃんおばあちゃんも インターネットを利用するようになっているでしょう。 また、最初は遠隔地の計算機をちょっと使うだけのために作られたIPv4は、 現在はかなり無理やり、通販、画像/音声通信などの用途に利用されています。

アドレス空間は128bit

128bitぶんというとピンと来ないかもしれませんが、3かける10の38乗ぶんの 計算機のアドレスづけが可能です。 アボガドロ数が6.02かける10の23乗ですから、2かける10の15乗立方ミリ、 すなわち100mかける100mかける200mの直方体をした風船(立方体の 風船ってちょっとヘンですね)の中にある原子の数を カウントすることができます。

基本設計の踏襲

IPv6はIPv4の設計のよいところはそのまま引き継ごう、悪いところは 取り除こう、という設計方針でつくられています。 このため、基本的な設計の方向性などはIPv4と非常に似ています。

不要なIPv4ヘッダを削除

IPv4には、パケットが無限ループするのを防ぐための値として、 TTL(Time to Live)という値がありました。 これはスペック上は、経路上のルータを通過した秒数、となっていましたが、 インターネット上では時計の同期もとれないし秒数で計るほどパケットを 流すのに時間はかからないので、実運用では通過したルータの台数、 ということになっていました。 IPv6ではこれをHop limitとして、実運用とスペックが整合 するようになっています。

高速処理を見据えた設計

ルータなどのパケット処理性能を考慮してスペックが設計されています。 例えば、IPv4ではIPv4ヘッダのチェックサムをとっていましたが、IPv6では これは省略されています。 IPv4でもIPv6でも、IPヘッダはルータで頻繁に書き換えられるので、 ヘッダのチェックサムをとるとルータごとにチェックサムの計算しなおしが 必要になり、ルータの機構のハードウェア化に対する障壁となります。

各種機能の標準化

ホストのIPアドレスの自動設定機構(dhcp)や、IP層における暗号化/認証は IPv4では基本仕様に入っていなかったために一般的ではありませんでした。 また、IPv4では実時間通信のための配慮が不足していたため、 ビデオ会議や音声通信などを行う場合にQoSの制御などが困難でした。 IPv6ではこれらの機能を基本仕様に含め、みんなが使えるように 配慮しています。

なめらかな移行

これまで発展してきたIPv4の子孫として設計したIPv6ですが、 IPv4の資産を捨てては元も子もありません。 そんなことをしたらみんなIPv6を使おうとはしないでしょう。 そのため、IPv6の仕様にはIPv4からのなめらかな移行のための手順が 含まれています。

ヘッダフォーマット

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. |                   Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+---------------+------------------------
|  IPv6 header  | TCP header + data
|               |
| Next Header = |
|      TCP      |
+---------------+------------------------

+---------------+----------------+------------------------
|  IPv6 header  | Routing header | TCP header + data
|               |                |
| Next Header = |  Next Header = |
|    Routing    |      TCP       |
+---------------+----------------+------------------------

+---------------+----------------+-----------------+-----------------
|  IPv6 header  | Routing header | Fragment header | fragment of TCP
|               |                |                 |  header + data
| Next Header = |  Next Header = |  Next Header =  |
|    Routing    |    Fragment    |       TCP       |
+---------------+----------------+-----------------+-----------------

自動設定

IPv6における自動設定にはDHCPに似たアドレス割り当て機構と、 新しい"stateless autoconfiguration"のふたつに分けることができます。 前者はIPv4のDHCPとさして違いがありませんが、後者はDHCPと比べると IPv6の広いアドレス空間をうまく利用している点と実装方式に大きな違いがあります。 アドレス空間の利用方法ですが、ホストの番号づけに使うアドレスの 幅が大きく異なっています。 IPv4のclass Cのサブネットの場合だと、サブネット内のホストの番号づけには 1バイト分しか幅がありませんでしたが、IPv6では24ビット幅の幅を用意しています。 すなわち、Ethernetの場合だったらMACアドレスをそのまま利用することができます。 実装方式の違いですが、 DHCPではサーバからIPv4アドレスそのものが配られていました。 つまり、サーバ側で10個なら10個のIPv4アドレスを予約しておいて、 それをクライアントに割り当てる、という形式になっていました。 このため、「このアドレスはクライアントに割当たっている」とか 「まだ割当たってない」というような状態の管理が必要でした。 これに対し、stateless autoconfigurationでは、状態の管理は必要なくなっています。 各物理ネットワークに接続されるルータは「このネットワークはこういうところだ」 という情報のみを一定の間隔でマルチキャストにより流します。 これを聞いたクライアントはネットワーク番号とハードウェアインタフェースに ついているアドレス(Ethernetの場合MACアドレス)をくっつけて 自分のアドレスとします。 もちろん、MACアドレスのない物理層などのために アドレスの衝突を防ぐためのロジックも存在します。

IPv6では自動設定が設計開始時の必要事項に含まれています。 このため、IPv6が普及すればいつでもどこでも自動設定してもらえる 環境が整うものと思われます。

フローラベル: 実時間通信のための基盤

なめらかな移行

1. 最初数年は、IPv6ホストはIPv4も喋れるバイリンガルにする。 つまり、昔からいるIPv4ホストと通信するときはIPv4で、 あたらしいIPv6/v4ホストと通信するときはIPv6で通信します。
2. トンネリングを使います。 つまり、IPv4パケットをIPv6パケットにくるんで伝送したり、 つまり、IPv6パケットをIPv4パケットにくるんで伝送したりします。 これにより、IPv6パケットがIPv4ホストしかいない領域を 通過したり、またはその逆を実現することができます。

NetWorld+Interop96 tokyo

我々WIDE IPv6ワーキンググループのメンバは7/20にホテル入りしました。 ホテルはメッセの隣、幕張ホテルニューオータニだったわけですが、 綺麗な建物豪華な内装のこのホテルにTシャツ単パンの男12人で入ると、 なかなか場違い感があります:-)。 集合し夕食を食べたあと、まずやることと言えば接続テストです。 この豪華な部屋が5分足らずであっという間にこんな風に! 大学の研究室のような状況になってしまいました (幕張ニューオータニの方、読んでたらごめんなさい。 掃除を断ったのはこういうわけだったんです...)。

この素敵な部屋が...

こんな風に!

実は7/21までは会場のほうは工事中です。 ネットワークの設計運用はNOCチームというボランティア(WIDEプロジェクトからも かなりの人数が参加しています)のみなさんが行うのですが、こちらが仕上るのも 7/22ということで、機材搬入や設定は7/22からとなっています。 このため、我々は7/22朝から会場に入り、搬入と設定を開始しました。 電源タップが足りないとか電源が非力だとか、いろいろ些細なトラブルはありましたが、 なんとか7/24の朝までにはデモンストレーションの準備をすることができました。

デモ内容の方は、大きく分けて3つありました。

• 6boneへの接続: デモ用のマシンをWIDE 6bone経由でworld 6boneに接続し、 IPv6的に接続されていることを見せるデモ。
• 自動設定: なにも手でネットワーク関係の設定をされていないマシンが、 ルータからの情報を聞いて自分を自動的に設定する様子を見せるデモ。
• IPv4とIPv6の相互接続: IPv4のマシンとIPv6のマシンを通信させるために、トランスレータ というパケットフォーマットを変換する機能を持ったマシンを間に挟んで 動画像を流すデモ。

みなさん「IPv4アドレスの枯渇」とか「IPv6」とかのキーワードはご存知なようで、 かなり突っ込んだ質問を頂きました。 特に、「どうやったらIPv6アドレスを割り当ててもらえるのか」 「ルータをそろそろ導入するんだけど対応製品を待った方がいいか」 といったようなちょっと焦りすぎの質問や、 「インターネットに接続したいんだけどどうすればいいですか」といった プロバイダのブースに行って欲しいような質問が印象に残っています。

IPv6の興奮

現状と今後

ちょっと強調したいことがひとつ。 IPv4からIPv6への移行について「明日移行しなきゃいけないのか」とばかりに 焦っている方がいらっしゃるようなのですが、焦る必要はありません。 現在、各組織ではIPv6の広域接続実験や接続性の確認をしているところです。 実際に普通に買えたり入手できたりする安定したソフトウェアがでてくるまでには まだまだ時間がかかります。 IPv6への移行はバックボーンからゆるやかに始まり、 きっと普通のひとはその変化に気づくことはないでしょう。 あなたの目の前にあるマシンが直接IPv6を喋るようになる時期、というのは 組織の管理方針やプロバイダの移行状況などによるのでなんとも 予測がつきませんが、まだまだ年単位で時間がかかるとおもいます。 たいていの機器はソフトウェアのアップデートだけでIPv6に対応できます。 つまり、ルータなどのファームウェアの更新は必要になりますが、 買い替えはほとんどの場合必要ないと予想されます。 ということですので、全く焦る必要はないとおもいます。

最新の現状について知るためには、 IETF(Internet Engineering Task Force、インターネット関係の 研究者の組織)のipng working groupのホームページが http://playground.sun.com/pub/ipng/html/に、 WIDEプロジェクトのIPv6ワーキンググループのホームページが http://www.wide.ad.jp/wg/ipv6/に ありますので、あわせて御覧になるとよいでしょう。

参考文献

• Christian Huitema, "IPv6: The new internet protocol", Prentice-hall, 1996, ISBN 0-13-241936-X.
• S. Deering and R.Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC1883, January 1996.
• J.Postel, "Internet Protocol", RFC791, September 1981.
• J.Postel, "DoD Standard Internet Protocol", RFC760/IEN128, January 1980.