ニュースレターNo.53/2013年3月発行
初めてのNAT
慶應義塾大学大学院 メディアデザイン研究科 教授
加藤 朗
NAT(ネットワークアドレス変換)は、ある範囲のIPアドレスを別の範囲のIPアドレスと対応付け、IPパケットヘッダのIPアドレスを書き換える技術です。現在では、ポート番号も含めた変換を行い、NAPT(Network Address Port Translation)としてIPアドレスの節約やセキュリティのためなどに広く使われています。NATは1994年5月に発行されたRFC1631(現在ではobsolutedになっています)として知られていますが、我々が知る限り一番古いNATの実装は、現在のものとは比べ物にならないぐらい稚拙なものではありましたが、1988年に稼働しています。そこで本稿では、このような仕組みを用いるに至った経緯を思い起こしてみます。
1986年頃、東京工業大学では学内の3部門(理学部情報科学科、工学部情報工学科、総合情報処理センター -- 呼称は当時のものです)をIPでつなぎ、キャンパス内でネットワークの運用を開始していました。これは現在のキャンパスネットワークとは異なり、ネットワーク関係の研究者(実は大学院学生が大半だった)がこっそり敷設したものでした。学科内は10Base-5のイーサネット(しかも工具で穴を開けてトランシーバを取りつける“新型”ではなかったため、トランシーバの増設には、同軸ケーブルを切断し、N型コネクタをはんだ付けする必要がありました)でワークステーションが相互に接続されていました。工学部情報工学科と総合情報処理センターの間は、メインフレームアクセスに使われていた4線式構内モデム(9600bps)を“再利用”したSLIP (Serial Line Internet Protocol)で接続されていました。NFS (Network File System)によるファイルシステムの共有は実用的ではありませんでしたが、電子メールなどは瞬時に届きましたし、ネットワーク上のマシンにログインしているユーザーを表示するrwhoを拡張したサービスによって、総合情報処理センターの村井純助手(現慶應義塾大学環境情報学部長)がワークステーションに触った次の瞬間に電話を掛けることも行われていました。
その後、メインフレームアクセスに使われていた光ファイバを使い、Ungermann-Bass社のバッファードリピータ(学習機能のないbridge)を数段経由することで全体が接続されるようになりました。IPアドレスは、外部と接続されていなかったため任意のものを使っても良かったので、「210」で始まる適当なClass Cのアドレスを使っていました。
キャンパスネットワークが大きくなってくると、キャンパス外部の計算機に対しても、モデムを定期的に呼び出すUUCPのように返事が得られるまで時間がかかる方法ではなく、IPで実時間に応答が得られる環境が欲しくなりました。このような広域分散環境の研究とその実現をめざした活動がWIDE Projectです。その最初のリンクは、村井氏がその後東京大学大型計算機センターに異動していたため、東京大学大型計算機センターと東京工業大学工学部情報工学科を64kbpsの高速デジタル専用線で接続したもので、1988年7月に開通しました。
これに先立ち、異なった組織との間にIPでの接続性を得るためには、正規のIPアドレスを取得し、それに変更しなければなりません。そこで、村井氏が米国のSRI-NIC(Stanford Research Institute's Network Information Center)からグローバルIPアドレスの割り振りを受けました。131.112.0.0や130.54.0.0などのアドレスはこの時のものです。133.0.0.0から始まるブロックは、その第二弾でした。
東京工業大学でもグローバルIPアドレスの割り当てを受け、まず工学部情報工学科が東京大学との接続のために新しいアドレスに移行することになりました。しかしながら、当時まだIPアドレスの変更(今ではリナンバという用語もありますが)など誰も経験したことはありませんでした。事前に各種依存関係の解析等も十分行わず、綿密な手順もない状況で作業を進めたところ、種々の問題が発生し、学科内に1ダースほどあったSunワークステーションをリナンバするのに丸一日かかってしまいました。NDというSun独自な方式で起動するディスクレスワークステーションへの対応が結構面倒だったと記憶しています。
学内の他の部門にも、学外との接続のためにグローバルIPアドレスにリナンバすることを求めましたが、当然のことながら「どうして情報工学科が外部と接続するために自分たちがアドレスの変更作業をしなければならないのか」という声が上がりました。そこで解決策として考えたのが、IPアドレスの変換システムを途中に入れることにより、リナンバをしなくても外部との接続を実現するという方法でした。
具体的には、東大への専用線を増設した同期シリアルインタフェースカードによって接続していたSun3/260hmのSunOS 3.5カーネル中に変換表を設定し、IPデータグラムのアドレスを、到着パケットにはグローバルIPアドレスから従来のIPアドレスへ書き換え、送出パケットにはその逆を行う、ということをしました。もちろん、IPアドレスの書き換えに伴い、TCP(Transmission Control Protocol)やUDP(User Datagram Protocol)のチェックサムの補正も必要になりました。後から考えれば、IPパケットのヘッダだけでなく、データ本体にもIPアドレスが埋め込まれているFTPなどをサポートするにはこれでは不十分だったわけですが、JUNETの電子メールや電子ニュースを東大から、当時JUNETにおける配送の頂点の役割を担っていた、総合情報処理センターのVAX-11/730である“titcca”に転送できれば良かったので、これでも十分実用になっていました。非常に原始的ではありましたが、NATの最初の実装ではなかったかと思います。
アドレス変換が必要な計算機は、当初1ダース程度だったので、アドレス変換表はカーネルの中にハードコードし、対象が増えたらカーネルを再構築してリブートするという方法を採っていました。その後、1990年ぐらいになって篠田陽一氏(現北陸先端科学技術大学院大学教授)がioctl(2)により対象が増えた場合にもカーネルの再構築やリブートなしで変更できるように書き直しています。その後、IPアドレスの付け替え作業が進み、この原始的なNATの役割は終了しました。
この初期のNATについて、1989年春に近畿大学にて行われた電子情報通信学会の春期全国大会で発表しましたが※、まだインターネットなど誰も使っていなかった当時、一つも質問が出なかったと記憶しています。
※ 加藤朗、当麻喜弘：“アドレス変換を伴う計算機ネットワークの構成”,電子通信学会春期全国大会予稿集、D-360、1989．
