要約

  • 1993年11月のRFC 1545は、FTPのデータ接続先を記すLPRTとLPSVを提案した。アドレスの種類、ホスト部分の長さ、ポート部分の長さをそれぞれ伝える。従来のPORTはホスト四欄とポート二欄の六オクテット固定だった。
  • 長い受動モードの返答には228、要求されたアドレス種別をサーバーが扱えない場合には521を用意した。RFC 1639は1994年6月に初版を置き換え、IP以外のネットワーク種別とTCP以外の転送インターフェースをより明確に扱った。

転送の前に住所でつまずく

FTPで交わす話は二本立てだ。制御接続では命令と返事をやり取りし、データ接続ではファイルや一覧を運ぶ。RFC 959のPORT命令は、後者をどこへ張るか伝える。その形式はh1,h2,h3,h4,p1,p2。最初の四つが32ビットのホスト住所、残り二つが16ビットのTCPポートで、各欄は一オクテットを十進数で書く。IPv4とTCPの組み合わせを前提にすれば、覚えやすい六マスだった。

困るのは住所の形が変わるときだ。1990年代初め、次世代IPの候補はいくつもあり、ホスト住所が長くなったり可変長になったりする案があった。転送側の識別子も二オクテットで足りるとは限らない。新しいネットワークのパケットが設計できても、FTPがデータ接続を始める前に相手へその住所を告げられなければ仕事は進まない。下の階の設計変更が、上の階の古い申請書に引っかかった。

David Piscitelloが1993年11月に出したRFC 1545は、実験的な提案だった。題名はFTP Operation Over Big Address Records、略してFOOBAR。冗談めいた略称とは裏腹に、命令の組み立ては几帳面である。LPRTはまずアドレス種別を置き、次にホスト住所の長さ、ホスト住所そのもの、ポート住所の長さ、ポート住所を並べる。それぞれを符号なし十進数のオクテットとしてコンマで区切る。読み手は「四つと二つだろう」と決め打ちせず、宣言された長さだけを読む。

受動モードにも相棒が要った。LPSVを受けたサーバーはデータ接続を待ち受け、228 Entering Long Passive Modeという返事で自分のアドレス種別、長さ、住所、ポートを示す。クライアントから渡すPORTだけを広げても、サーバーが返す待受先が昔の六マスなら通信は片足立ちになる。FOOBARは両方向の住所表を作り直した。

もう一つの新しい返事が521だ。サーバーは長い住所を記す命令そのものを理解していても、指定されたネットワーク種別に対応していないことがある。521なら扱える種別を列挙できる。構文を間違えたときの500や501とは違う。文法は分かった、しかしその接続口はない、と相手に伝える仕組みだ。使える種別が分かれば、両端は別の選択肢を検討できる。

RFC 1545に並ぶ候補を見ると、当時の机上がにぎやかだったことが分かる。IPのほか、ST Datagram Mode、SIP、TP/IX、PIP、TUBAが登場する。ホスト住所だけでなくポートの長さまで書く理由もある。TP/IXはTCPの16ビットポートより長い転送セレクタを考えていた。住所欄を増やしてもポート欄が二マスのままでは、次のつまずきが隣に残る。制御接続とデータ接続が異なるアドレス種別を使うことも、原稿は認めていた。切り替えは一斉の号令より複雑なものとして扱われた。

初版はほどなく改訂される。1994年6月のRFC 1639はRFC 1545を廃止し、長い住所の考え方を引き継いだ。アドレス種別の値0から15をIP系のバージョン番号向けにし、16から255をIANAが割り当てる他のネットワーク層プロトコル向けにした。Novell IPXは16で示される。TCP以外の転送インターフェース上でFTPを動かす話も明記された。六マスの住所録は、別の言語で書かれた住所も受け取れる帳簿へ育った。

最初のPORT h1,h2,h3,h4,p1,p2は小さな記法に見える。けれども、ホストは32ビット、ポートは16ビットという想定をアプリケーションの言葉の中に固定していた。次のインターネットを語るなら、ルーターの設計だけでなく、この一行を読む側も変えなければならない。FOOBARの仕事は六マスを広げること以上に、隠れていた前提に見出しと長さを付けることだった。