要約

  • 草案第1版は、元の受領者が運用するリンク上で第三者に非恒久的に1アドレスまたは /64 を使わせることを、禁止されたサブアサインメントから除外しようとした。
  • ゲスト端末やホットスポットを独立した下流ネットワークと同一視しない修正は合理的だったが、恒久接続やブロードバンドという呼称を一律に禁止側へ置くと、台帳管理が事業関係の許認可へ広がる。
  • 2018年5月9日のAFRINIC-28で結論は More discussion needed と記録され、提案はメーリングリストへ戻された。合意、批准、実装、具体的な執行を示す記録ではない。
  • 持続可能な基準は時間の長短や顧客という名称だけではなく、保有者、独立した運用支配、連絡先、セキュリティ情報、重複防止に関わる現実が変わったかどうかである。

L3 — 移転に見えて移転ではなかった /64

草案の出発点は、IPv6の利用単位と組織的な支配単位が常に一致するわけではない、というごく実務的な問題だった。ホテルや会議場の来訪者が無線LANに接続すると、端末は通信に必要なアドレスを得る。従業員の私物端末も、事業所の機器も、VPNの端点も同様である。IPv6では、端末やインターフェースを分離する設計のため、一つのアドレスだけでなく /64 を与える場合がある。しかし、ここで渡される1アドレスまたは /64 は、広大なIPv6番号空間の割り当て全体と同じものではない。数値上の接頭辞を端末が利用することと、その接頭辞を含む資源の制度的な保有や運用支配が別組織へ移ることは、別の出来事である。

具体的に見よう。会議主催者がアクセスポイントを設置し、認証条件を決め、ルーターを管理し、端末の接続を切ることができ、障害や不正利用への連絡も受け持つとする。来訪者の電話が /64 を一時的に使っても、来訪者は経路広告を管理せず、台帳の連絡先を更新せず、接頭辞を別のインフラへ持ち出して独立運用するわけでもない。第三者の端末が存在するというだけで、独立した第三者ネットワークが成立したとはいえない。トポロジーの末端に他人の機器があることと、番号資源の支配が移ったことを同一視すれば、共有リンクを使う普通のサービスが制度上の「移転」に化けてしまう。

AFPUB-2018-V6-002-DRAFT01 が狙ったのは、この誤分類の修正だった。提案された例外の核は四つある。使わせる単位は一意なIPv6アドレスまたは /64 であること、相手が第三者であること、利用が恒久的ではないこと、そして利用場所が元の受領者によって運用されるリンク上であることだ。単に「短期間なら何でもよい」としたのではない。元の受領者がリンクを運用しているという条件が、端末利用と独立した下流支配を分ける役割を担っていた。

草案が挙げた運用例は、この問題設定をよく表している。ゲストや従業員が使う端末、機器やサーバー、ホットスポット、ポイント・ツー・ポイントリンク、VPNが対象として示された。BYODのように所有者が組織外または従業員個人である端末も、ネットワーク制御まで外部へ移すとは限らない。機器の所有権を問うだけでは足りず、誰がリンクを構成し、接続条件を定め、障害時に対応し、接頭辞の利用を止められるかを見る必要がある。草案は、古い包括的な「サブアサインメント」概念がこうした実装を十分に想定していなかったと捉えた。

提案番号には注意が要る。この主題の公式な識別子は AFPUB-2018-V6-002-DRAFT01 である。AFPUB-2018-V6-001-DRAFT01 ではない。後者はIPv6ポリシーと参照情報の更新を扱う別の提案であり、似た番号だからといって置き換えると、議論の対象そのものが変わってしまう。本稿が検討するのは、あくまでサブアサインメントの明確化に関する第1草案である。

日付にも二つの公式記録が併存する。提案ページの詳細欄は提出日を2018年3月14日としている一方、改訂履歴は初版がrpdへ投稿された日を3月20日としている。これはどちらかを消して一つの日付に丸めるべき矛盾ではなく、「提出」と「初回投稿」という異なる記録項目として読める。したがって、草案を単に「3月20日に提出された」と書けば詳細欄を失い、「3月14日に公開された」と断定すれば改訂履歴の意味を変える。本稿では、3月14日が公式の提出メタデータ、3月20日が初版投稿の改訂履歴であるという区別を保つ。

草案は一時的な利用だけを許容側へ動かし、恒久的な接続やブロードバンドサービスを禁止側に残した。この区別は、短期の来訪者利用を救う一方で、長期の顧客サービスを引き続きサブアサインメントとみなす構造である。つまり、第1草案はサブアサインメントの禁止自体を撤回する提案ではない。例外に入る運用を定義し、例外の外側、とくに恒久接続やブロードバンドを従来の禁止の下へ置き続ける試みだった。

ポイント・ツー・ポイントリンクについては、さらに細い限定があった。草案はリンクを成立させるためのアドレス利用だけは恒久的でもよいとしたが、そのアドレスをリンクの背後で行われる実際の通信に直接にも間接にも用いてはならない、と区別した。二つの端点を結ぶためのリンク用アドレスと、その接続を通って利用者が行う通信のアドレスを分けたのである。この限定を落とすと、「ポイント・ツー・ポイントなら恒久利用はすべて例外」と広く読み違えてしまう。逆に、リンク用の技術的アドレスまで顧客への恒久的なサービスと同一視すれば、接続を組み立てるための最小限の番号利用を不必要に禁じることになる。

VPNも同じように、端点への一時的なアドレス供給と、独立した下流ネットワークへの資源支配の委譲を分けて考える必要がある。利用者が組織のVPNへ接続し、組織側が認証し、アドレスの有効期間を管理し、切断時に回収するなら、利用者はそのアドレスを独立して再配分できない。ところが「第三者が使った」という一事だけを基準にすれば、この運用まで禁止対象に入り得る。草案の価値は、第三者という人物属性より、どのリンクの上で、どの程度の持続性をもって使われるかを見ようとした点にある。

技術的な背景として参照されたRFC 8273は、プロバイダーが管理する共有アクセスネットワークで、ホストごとに一意なIPv6プレフィックスを与える実装を記述している。ホスト間の分離や加入者管理に利点があり得る一方、接頭辞と加入者を関連付けられることによるプライバシー上の考慮も示す。この文書は2017年12月のInformational RFCであって、Standards Trackではない。実運用の設計が「端末一台に /64」という形を取り得ることの技術的な証拠ではあるが、AFRINICに規制権限を与える文書でも、レジストリ方針の結論を命じる文書でもない。

この区別は重要だ。ある設計がRFCに記述されていることは、その設計が現実に使われ、調整規則が無視できないという事情を示す。しかし、技術文書の存在から、私的なレジストリがサービス内容を許可または禁止する統治権を導くことはできない。逆に、AFRINICにその権能がないからといって、技術文書が明らかにする運用上の差を無視してよいわけでもない。RFC 8273が支えるのは、端末ごとのプレフィックスが直ちに組織間の資源移転を意味しない、という実装理解である。

2018年5月9日、ダカールで開かれたAFRINIC-28では、この第1草案が議論された。公式議事要旨には、PPP、VPN、ホットスポットなどの事例が扱われ、賛同する反応だけでなく、理解の食い違いと文言上の未解決な指摘が残ったことが記録されている。議事要旨は議論の公式な要約ではあるが、全発言の逐語録ではない。誰がどの語をどの抑揚で述べたかまで補う材料にはならないため、確認できる範囲を越えて参加者の意図を推定すべきではない。

会合でAFRINICスタッフは、一時的な利用例をWHOISに登録する必要があるのかと尋ねた。提案者の回答は、それらは一時利用なので登録を必要としない、というものだった。この応答は「WHOISの記録は決して必要ない」という一般命題ではない。草案が例示した一時的なケースへの提案者の答えである。恒久的かつ独立した下流支配によって、責任主体、連絡先、セキュリティ対応、証明可能な支配が変わる場合まで、記録不要とする根拠にはならない。

会合の処分は More discussion needed だった。共同議長は提案をメーリングリストへ戻し、さらに文言を詰めるべきものとした。したがって、第1草案はこの時点で合意を得た規則でも、批准された規則でも、実装された規則でもない。公開され、会合で検討され、理解と文言の問題が解消せず、議論継続になった提案である。この限定を守らなければ、後の版や後の制度状態を第1草案へ遡及させることになる。

記録から確認できるのは、問題提起、草案の文言、二つの日付、会合での質問と提案者の回答、そして議論継続という処分までである。この草案が何件のネットワークへ影響したかは数量化されていない。具体的なサービス拒否、停止、没収、障害、執行が第1草案によって生じたとも証明されていない。制度設計上の危険を論じるには十分な材料があるが、実害を創作して議論を強める必要はない。むしろ、まだ提案段階だったからこそ、どの線なら台帳の目的に適合し、どの線から越権になるかを冷静に分解できる。