要点

  • RFC 9952はCoAP over DTLSに0x63 0x6f、すなわちcoを割り当て、SVCBのalpn値として発見に使えるようにした。一方でRFC 7252はDTLSハンドシェイクにおけるALPN利用を定義しておらず、RFC 9952もRFC 8323相当の規則を新設しないと明記する。
  • レジストリは名前を、DNSは候補を示す。実際の交渉を証明するのはClientHelloの全提案とServerHelloの選択または失敗であり、相手認証、CoAP認可、業務結果はさらに別である。

CoAP over TLSにはcoapがある。DTLSには同じ値を流用せずcoを用意した。輸送層が異なるプロトコルを一つの識別子に押し込まず、しかも二バイトを節約する。6LoWPANのような環境では、その二バイトが境界をまたぐこともある。

ただし、RFCが保証するのは名前の一意な意味までである。フラグメント削減、実装、設定、交渉、サービス成功を一括して保証するものではない。

「規則を作らない」という設計

RFC 9952の重要な限定は、RFC 7252がALPN拡張の利用を定めていないことを確認し、新しい文書もその挙動を変えないと述べた点にある。RFC 8323のCoAP over TLS規則を、値が似ているという理由でDTLSへ輸入してはならない。

したがって、実装表に「RFC 9952対応」と書くだけでは接続について何も証明しない。ローカルプロファイルがcoを必須にするなら、そのプロファイル、両端設定、実際のwire結果を結ぶ必要がある。単に利用可能とするだけなら、ALPNのない一接続を直ちに標準違反とは呼べない。

発見と接続の間

SVCBのalpn=coはサービス候補を提示する。権威ある公開、検証、TTL、キャッシュ、Alias処理、クライアント選択、到達先が順に関与する。DNSSECが成功しても、到達先プロセスが同じ設定世代をロードしたとは証明しない。

RFC 7301のwire記録はより具体的である。ClientHelloに順序付きリストが入り、サーバはその中から一つだけ選ぶ。共通値がなければ定義された失敗がある。接続ID、端点、DTLS版、完全な提案、選択またはalert、時刻、採取地点を保存して初めて交渉回数を数えられる。

再試行も別接続として記録する。最初のALPN失敗後、別設定で成功したCoAP応答を一つの「成功」にまとめると、どの条件で処理されたか失われる。

サイズの設計値と現場値

coはcoapより二バイト短い。しかしClientHello全体にはkey share、暗号スイート、署名、cookie、資格情報、他の拡張がある。DTLSレコード分割とリンク層分割も違う。電波損失と再送条件も結果を変える。

効果を主張するなら、同じ環境でサイズ、リンクフラグメント、再送、完了時間、失敗率を比較する。短い値はよい設計判断だが、それだけで測定結果にはならない。

選択後も権限は残る

coが選択された事実は、証明書やRaw Public Keyが期待するサービスに結び付いたことを示さない。信頼アンカー、参照名、有効期間が別に必要である。その後もCoAPのtokenとmessage ID、method、option、resource policy、応答相関、アプリケーションの状態変更が残る。

証拠列は、登録、DNS広告、候補選択、offer、selection、相手認証、CoAP交換、resource認可、業務効果、観測結果に分かれる。ALPNがないことも逆方向の万能証拠ではない。RFC 9952は普遍的義務を作っていないため、意味は具体的プロファイルが決める。

Lu Hengの最小初期仕様は、この狭さを弱点ではなく設計原則として捉える。共通層は相互運用に必要な名前だけを持ち、将来判断は結果を負う実装者に残す。現実層はIANAの記号をパケットへ、パケットをアプリ承認へ昇格させない。Running-Code Primacyは、ロードされたバイナリと実際の交換を問う。

RFC 9952は二文字を登録した。そして二文字以上の権限を主張しなかった。運用証拠も同じ節度を持つべきである。

例外台帳は実際の経路を記述する

移行は全端末を同時に一つの状態から別の状態へ移す作業ではない。古いfirmwareのセンサー、別のresolver viewを見るgateway、cacheに残るSVCB、DNS discoveryを使わない固定宛先のclientが混在する。それぞれが、広告を見られたか、機能をロードできたか、ClientHelloに値を入れられたかを変える。単一の展開率は、この原因差を消してしまう。

例外台帳にはowner、対象population、理由、softwareとconfigurationの世代、期限、fallback動作が必要である。期限切れだけでは例外は閉じない。最後の対象endpointが旧経路を離れた観測が終了条件になる。代替経路が残る間は接続ごとに別のidentityを持たせ、CoAPの効果を発生させた接続へ帰属させる。二回目の成功で一回目の失敗を書き換えてはいけない。

release evidenceは少なくとも四つのartifactを結ぶ。対応コードを含むbinaryまたはfirmware、機能を有効にした設定とload receipt、clientが見たDNS世代、完全なofferとselectionまたはfailureを示すtraceである。新しい実行物が古い設定を読むことも、新しいDNSが古いlistenerを指すこともある。canary一台の成功は、異なる経路を持つ母集団の証拠にならない。

この分解は組織の境界も明らかにする。DNS teamは広告を証明できるがClientHelloは証明できない。platform teamはfeature activationを証明できるがremote selectionは証明できない。security teamはpeer identityを検証できるがresource authorizationは所有しない。application teamは状態変化を見ても、connection identityがなければどの試行が生んだか分からない。報告は各判定を分けたまま保存し、時刻、端点、接続、設定世代で結合する。

公開日ではなく証拠列を管理する

段階展開では三つの観測群を分けるとよい。従来経路を保つcontrol、対応コードだけをロードして広告しない群、DNS広告とendpoint supportをともに持つ群である。この比較なら、code load、discovery input、handshake selectionの変化を混同しにくい。単純な前後比較では、cache更新、再起動、無線損失までALPNの効果として数えてしまう。

群ごとに分母も固定する。広告を見たclient、coをofferしたconnection、serverが選択したconnection、identity validationを通過したconnection、CoAP operationを完了したconnection、期待するapplication effectを生んだoperationは、六つの異なる集合である。層を進むほど数が減ること自体は異常ではないが、その差を説明できなければならない。

rollbackも一操作ではない。SVCBを削除してもcacheは直ちに消えず、server supportを止めてもclient offerは残り、clientがofferを止めても既存connectionは存続し得る。DNS、client、server、connection lifetimeごとに終了条件を置き、進行中のCoAP operationを完了させるか中止するかを決める。可逆性とは、この順序とreceiptを持つことである。

情報源