要約

  • RFC 9003の自由UTF-8文はAdministrative ShutdownとAdministrative Resetだけに付加でき、上限は255 octetである。128 octetのRFC 8203はobsoleteになった。
  • NOTIFICATION後にconnectionは直ちに閉じ、BGP内に受領・理解確認はない。transportのintegrity/confidentialityがなければ、文は偽造・観測され得る。
  • 説明、事前drain、route retentionは別のcontrol surfaceである。raw bytes、受信log、retry、RIB/FIB、packetまでを証拠にする。

02:00、routerは[CHG-4281] edge更新、30分で復旧予定を送ってTCPを閉じる。遠隔NOCは計画作業らしいと分かる。しかし、権限者が起動したか、trafficが移ったか、30分が保証かは分からない。

使えるsubcodeは二つだけ

RFC 4486はCease原因を分類する。RFC 9003のtextはsubcode 2と4に限られる。maximum-prefix、peer deconfigured、collision、resource不足には別の構造化理由がある。自然文で誤った分類を覆ってはならない。

wire形式はlength 1 octetと同数のUTF-8 octetで、0はtextなし。NUL終端ではなくshortest formが必要だ。255は文字数でない。multibyte言語では入る文字が少なく、これが旧128制約を改めた実務上の理由だった。

ただし128は互換境界として残る。相手のRFC 9003対応を確認できれば255まで、未知なら128以下が推奨される。旧実装は長いdataをerrorとしてlogしても、terminal NOTIFICATION自体は処理する。

これはminimum initial specificationの好例だ。共有するのはsubcode、length、encodingだけで、ticket system、言語、開示、retentionは各operatorが持つ。

最後の一文には返信できない

RFC 4271ではNOTIFICATION送信直後にBGP connectionを閉じる。受信したNOTIFICATIONが誤っていても、NOTIFICATIONで返答できない。従ってRFC 9003にacknowledgementも「正しく理解した」確認もない。

送信logはlocal intent、pcapは送出bytes、遠端logはarrivalとdecodeを証明する。人が読んだこと、ticketを確認したこと、行動を承認したことは証明しない。

共有change IDはauthenticated out-of-band noticeへつなぐべきだ。BGPは消える瞬間にindexを残し、合意・修正・会話は双方向channelに置く。

正しいUTF-8でも危険になれる

valid encodingはtruthを保証しない。偽ticket、confusable Unicode、別syslog行に見える文字列も作れる。shortest formは不正encodeを除くが、視覚的欺瞞は除かない。

receiverはraw valueとsafe renderingを分離し、control characterをescapeし、peer由来dataをlocal fieldと明確に区別する。255は量を制限するだけでsanitizationではない。

integrityなしなら偽造、confidentialityなしなら盗み見が可能だ。共有key、広いchange class、時間帯だけに絞り、個人情報、credential、customer、内部host、topology、未確定root causeを送らない。

transport authenticationもendpointを確認するだけで、人間や文章の正しさを署名しない。corroborationまではpeer claimとして扱う。

説明とdrainは時間軸が違う

RFC 8326は切断前にpath preferenceを下げ、convergenceを待ってから閉じる。RFC 9003は閉じる瞬間に話す。textはalternate routeを作らず、過去のpacketを動かさない。

両方を使うなら、drainを測定してから理由付きで切断する。それぞれに独立したproofが必要だ。

RFC 8538のGraceful Notification N-bitを双方が交換すると、Hard Reset以外のNOTIFICATIONでrouteをstale保持できる。Cease 9はfull resetを要求する。Administrative ShutdownにはHard Resetが推奨され、Resetはuser controlだが、絶対規則ではない。

説明をHard Reset内に入れる場合、外側subcodeは9、内側に行政通知とtextがある。外側しか記録しないmanagementは理由を失う。stale routeが残ってもnext hopが生きている保証はない。

信じ方は受信側が決める

senderは閉鎖と発言を持つ。receiverはlog、redaction、alert、retry、stale policyを持つ。RFC 4486はAdministrative Shutdownなどでretryをdampし、回数を制限して人へ渡すことを勧める。文章がremote timerを設定するわけではない。

automationはsubcodeとlocal authenticated policyから動き、textはcontextだけにする。unknown ticketはverify対象で、commandではない。永久停止をResetと誤分類すればloop、短いResetをShutdownとすれば復旧抑制が起きる。

acceptanceはpacketで終わる

まずauthor、ticket namespace、語彙、禁止data、octet ceilingを定める。長さ既知のASCII/multibyte canaryで128を試し、対応証明後だけ255を試す。

wireでendpoint、時刻、code、subcode、length、raw bytes、decode、N-bit、encapsulationを記録する。受信側でrender、escape、syslog、telemetry、ticket照合、retentionを確認する。

次にsocket、FSM、retry、withdraw/stale、timer、RIB/FIBを追う。traffic、loss、recoveryを測って初めて、説明と実行の両方を証明できる。

rollbackは自由文を止め、128へ短縮し、controlled vocabularyかticket keyだけへ戻す。真のCease理由とout-of-band recordを隠してはならない。

RFC 9003の価値は小さいままにある。sessionは消える瞬間にinteroperableな手掛かりを残す。authorization、minimum disclosure、corroboration、running codeがそれをevidenceにする。説明は命令ではない。