要約

  • RFC 1681 は、誰が支払うかを表す区分、または課金アルゴリズム表への索引を宛先アドレスに符号化し、接続前にクライアントと境界ルーターが判断できるようにする案を示した。
  • 費用を事後に知るのでは遅く、対話の機会がない通信や、警告なしで有料アドレスへ進む Gopher 転送では、接続時の表示さえ機能しないと論じた。
  • アドレスは方針を選べても、人間の主体、当時の条件、同意、有用な提供、正しい計量、請求の妥当性、支払いを単独では証明できない。

警告を出す場所がない通信

RFC 1681 の課金節には、小さく鋭い想定例がある。Gopher サーバーが、必要な警告を見せずに呼出側を有料アドレスへ転送する。文書はこれを実際に起きた事件とはしていない。利用者が判断する場所をアプリケーションが用意しないとき、料金通知をどこに置けるのかを問うための例である。

接続時に警告文を表示するだけでは足りない、と文書は言う。多くのやり取りには人を介在させるフックがない。接触が始まってから条件を知らせても、課金の境界はすでに越えられているかもしれない。

そこで、宛先アドレスの一部を課金規則に使う。少数のビットなら誰が払うかを示し、より広い領域なら課金アルゴリズム表の索引にできる。組織の境界ルーターは、その区分に対してローカルな許可・拒否を接続前に適用できる。

ただし、アドレスに料金表そのものが入るわけではない。そこにあるのは選択子である。金額、単位、有効期間、契約当事者は別の記録に残る。

箱の数ではアドレス需要を測れない

RFC 1681 の主題は本来、一台のホストが多くのアドレスを必要とし得るという指摘だった。当時の終端ホストは一つのアドレスを持つことが多く、必要なアドレス空間もホスト数から見積もられた。サービス、アクセス方針、利用者、限定的な移動に別々のアドレスを使うなら、その算術は崩れる。

二次アドレスを物理マシンではなくサービスの識別子にすれば、サービスを別のマシンへ移しても外向きのアドレスを保てる。同じホスト上の異なるサービス表示に別アドレスを与えれば、新しいプロトコルや特別なポートを利用者に覚えさせずに済む。ファイアウォールは特定のサービスアドレスだけを通せるが、それは各サーバープロセスが正しいアドレスに束縛されている場合に限られる。アドレス認証の弱点も残る。

文書は DNS がポート情報まで返す案も考えたが、既存のクライアントを一斉に変更する負担を問題にした。すでに普及したアプリケーションが理解するアドレスへ意味を載せる方が、移行は軽く見えたのである。

しかし一つの欄に、位置、サービス、アクセス区分、ログイン利用者、移動、課金という異なる寿命の意味が集まる。サービスアドレスはホストをまたぎ、利用者アドレスはセッション終了で消え、課金表は同じアドレスのまま改訂される。ビットだけを保管しても、各意味の時点までは保管できない。

支払者の四類型

RFC 1681 は従量課金を四つに分けた。通常の pay-as-you-go では双方のホストが自分のパケット分を負担する。caller-pays では呼出側が払う。collect call では受け手へ負担を移す。さらに米国の「900」番号のように、呼出側がサーバーへ割増料金を払う形も想定した。

だから、呼出側と受信側は、誰が払うかを事前に知る必要がある。費用を負った後で初めて知る仕組みは受け入れられない。

それでも、支払者は課金規則の一項目にすぎない。RFC 1125 は別の文脈で、会計単位、課金基準、実額、誰が払い誰が受け取るか、誰のパケット数を使うか、上限を分けていた。支払区分が正しく読めても、バイト単位かパケット単位か、どのカウンターが優先されるか、いくらまで許されるかは決まらない。

RFC 1681 の「表への索引」は、この依存を隠さない。アドレスがある行を指しても、その行の内容、版、管理者、有効時刻を残さなければ後から規則を再現できない。索引が生き残り、意味だけが失われることがある。

ルーターの許可は利用者の承諾ではない

組織境界のルーターなら、有料サービスを早い段階で制御できる。文書は、学生寮の匿名ワークステーションから collect call をさせない例を挙げる。これは一つの管理領域が、自分の装置で、自分の方針を執行する限定的な権限である。

通過したことは、人が同意したことを意味しない。端末は共用かもしれず、プログラムは自動かもしれない。口座所有者が認めた上限と、ルーターの許可区分が違う可能性もある。遠隔サービスが参照する料金表が更新されているかもしれない。ネットワーク判断と商業上の責任は別々に争い得る。

RFC 1681 はログイン中の各利用者に個別 IP アドレスを割り当てる案も示した。ルーターはそのアドレスで利用量を集計し、ホストはセッションとの対応を記録し、請求はオフラインで行う。高価なサービスへ接続できる利用者区分をアドレスの形で表すことも考えた。

これは記録を結びやすくするが、利用者を暗号学的に証明するものではない。必要なのは、ルーターの測定、ホストの時刻付き割当記録、認証、権限、料金表、サービス側の記録である。一人用に見えるアドレスだけでは、その瞬間に誰が操作し、どの支出を承認したかは確定しない。

採用されなかった提案を、後世から完成させない

RFC Editor の情報 では RFC 1681 は Informational である。RFC 1550 の IPng 白書募集への応答であり、本文は掲載が提案の受諾を意味しないと明記する。RFC 1550 も白書を選考用資料と IPng 過程の歴史記録に位置付けていた。

後の IPv6 で複数アドレスが普通になったことは事実である。RFC 4291 はアドレスをインターフェースに割り当て、一つのインターフェースが種類やスコープの異なる複数アドレスを持てるとする。しかし、これは課金ビットの採用、RFC 1681 からの因果、現在の課金運用を証明しない。

サービス探索には RFC 2782 の DNS SRV がある。サービス、プロトコル、優先度、重み、ポート、対象を明示し、利用するアプリケーションプロトコル側にも規定を求める。SRV は行き先を探すための記録であり、価格、支払者、承諾、メーター、請求を運ばない。

RFC 1681 が一台当たり 2^6、場合によっては 2^8 の追加アドレス余裕を勧めたのも、観測値ではなく設計上の見積もりだった。意味が増えれば、箱の数以上に識別子が要る。その警告と、個々の用途が採用されたかどうかは分けて読む必要がある。

信号から決済までを一列に潰さない

監査可能な連鎖には、選ばれた宛先、アドレス区分または表索引、当時有効な表と管理者、境界での判断、認証された主体、契約前に示された条件と承認、遠隔サービスの受入れと実提供、計量単位とカウンター、請求計算と上限、支払い・取消し・紛争結果がそれぞれ要る。

前段は後段の代用品にならない。区分の一致は表の鮮度を証明せず、ルーター通過は人の承諾を証明せず、接続成功は有用な提供を証明しない。パケット数は単価を決めず、請求書は決済完了を示さない。

Heng Lu の Running-Code Primacy に従えば、提案と実装、掲載と採用、ラベルと観測事実を分ける必要がある。Minimum Initial Specification は共通層に必要な意味と、事業者がローカルに決められる商取引を区別する。Reality, Not Advocacy は、この案を復活運動にも失敗談にもせず、証拠の幅で記述するための基準になる。

RFC 1681 が守ろうとしたのは、費用が生じた後ではなく、その前に機械が読める情報を置く順序だった。その情報に価値があるのは、本人性、権限、提供、計量、請求、決済の各段階を、なお別々に証明できる場合だけである。

出典