要約

  • RFC 7710は、キャプティブポータルの発見にDHCPv4オプション160を割り当てた。IETF 106のネットワーク実験では、一部のPolycom機器が160を別用途ですでに使っており、標準のAPI URLを受けると意図どおりに動作しなかった。
  • RFC 8910はDHCPv4の機能を114へ移した。IANAは160を未割り当てとしつつ、RFC 7710による旧割り当てとPolycomでの利用を注記している。登録状態は、導入済み機器の互換性試験を代替しない。

仕様書を会議ネットワークに接続する

シンガポールで開かれたIETF 106では、Captive Portal APIに対応するクライアントがvenue-info-urlを見つけられるようにするネットワーク実験が行われた。DHCPv4で使う値には根拠があった。2015年のRFC 7710が、キャプティブポータル通知にオプションコード160を指定していたからだ。

実験用の値は、対応クライアントだけには届かない。同じネットワーク上の一部のPolycom機器も受け取った。RFC 8910の付録Bによれば、それらは160を別の目的で使っており、Captive Portal APIのURLが入った160を受信すると、望ましい動作をしなかった。

公開記録が示すのはそこまでだ。機種、ファームウェア、台数、別用途のデータ形式、具体的な不具合は記されていない。メーカー名から空欄を推測してはならない。確認できるのは、観測された環境で二つの解釈が衝突し、その結果が標準の番号変更につながったことだ。

RFC 8910の著者はWarren KumariとErik Klineである。前身のRFC 7710はKumari、Olafur Gudmundsson、Paul Ebersman、Steve Shengによる共同作業だった。したがって、これは一人の発明家の逸話ではない。Klineの役割は、失敗を過大評価せず、しかし消去もしない改訂文書の共著にある。

権威ある意味と、実行される意味

DHCPv4のオプションコードは1オクテットである。IANAの登録簿は、サーバーとクライアントが同じ番号を同じ意味で使うための基盤だ。160をRFC 7710へ割り当てた記録は、当時の標準上の意味を正当に定めていた。

一方、端末はACKを受けるたびにIANAへ問い合わせない。ファームウェア内の分岐を実行する。CAPPORT対応クライアントは160にURIを期待する。別のパーサーが異なる構造を期待すれば、同じバイト列が別の状態遷移を起こす。

ここには二つの問いがある。どの用途が標準として認められているかは登録簿が答える。そのセグメントの機器が実際にどう反応するかは、資産把握と試験が答える。前者を後者の証明に使うと、正式な割り当てが世界中のバイナリーを調査したかのような錯覚が生まれる。

RFC 3679は、DHCPコードの再利用でも実装調査が欠かせないことを示していた。標準にも一般利用にも至らなかった提案のコードは再割り当てに戻した。その一方、公開RFCがなくても機器で使われている値は予約した。文書がないことと、導入がないことを同一視しなかったのである。

114は新しい合意、160には履歴が残る

2020年9月に標準トラックで公開されたRFC 8910は、RFC 7710を廃止し、RFC 3679を更新した。DHCPv4のキャプティブポータルには114を採用した。現在のIANA BOOTP/DHCPパラメーター登録簿でも、114はDHCP Captive-PortalとしてRFC 8910に結び付いている。

160の状態はUnassignedである。ただし説明には、RFC 7710で以前割り当てられていたことと、Polycomでも使われていることが分かっている、と残る。未割り当てとは現在の標準上の状態であって、全ファームウェアが無反応だという保証ではない。

変更はDHCPv4に限られる。DHCPv6のキャプティブポータルオプションは103、IPv6 Router Advertisementでは37のままだ。三つは別のコード空間に属する。「160から114へ変わった」と述べるなら、DHCPv4という限定が必要である。

新しいRFCは旧端末へ遠隔パッチを送らない。サーバーが114を配り、リレーやアクセス制御が保ち、クライアントが理解して初めて移行する。現場には114を読む端末、160に反応する旧機器、CAPPORTを知らない端末が混在する。両方の値を送れば、古い衝突を再び起こす恐れがある。

リースの先にある機能を測る

導入前に、ハードウェア、ファームウェア、用途で機器を分類する。ラボでは正確なコード、長さ、代表的なペイロードを再現する。次に、種類を意図的に混ぜた小さなカナリアセグメントへ進む。

アドレス取得と更新だけでは足りない。起動が完了したか、サービス登録が済んだか、通信できるか、本来の業務を実行できたかを見る。DHCPを正常終了してから別の処理で失敗することはあり得る。ACK率だけが緑色でも、サービス結果は未確認だ。

サーバー側でオプションを取り除く手順も先に試す。更新不能な機器群には、専用セグメントや明示的なDHCPポリシーが必要かもしれない。管理された例外は、事故発生時に初めて存在が分かる「互換機器」より扱いやすい。

失敗を残すことが標準を強くする

非公開利用が先行しただけで番号の権利を得るわけではない。それを認めれば、黙って使う者が共有空間を奪える。同時に、正式な決定だけで導入済みの処理を消せるわけでもない。

登録簿は共通の目標を定め、限定的な実験は導入済み実装を照合する。食い違いが見つかれば、目的を維持したまま手段を変えられる。114はキャプティブポータル発見を断念した番号ではなく、既知の衝突を回避して収束を目指す番号だ。

RFC 8910は、場所、限定された機器表現、一般的な結果、番号変更を記録した。断定を抑えたからこそ、メーカーへの根拠のない非難を避けながら、次の割り当てに使える教訓になった。160の注記は、失敗から得た互換性の受領書である。

出典