要約

  • RFC 9844はnon-global IPv6 addressを受けるUIに、link-localまたはscoped multicast addressとzone identifierの選択手段を要求する。通常はOSのinterface名が人間向け表現になる。
  • 文字列はhost固有のnumeric interface indexへ解決され、socket callに使われる。ローカル行動には不可欠だが、別nodeでは意味を持たず、wireへ送ってはならない。
  • 信頼できるreceiptはinput、検証、mapping、interface lifecycle、結果をnode内に残し、送信packetからlocal labelが除かれたことを別の観測で示す。

同じaddressを入力した二人のoperatorが、別のlinkを操作した。文字列は一致していた。異なっていたのは、その文字列に欠けていたlocal contextである。

複数のinterfaceを持つhostでは、同じlink-local literalが複数のzoneで解釈され得る。UIがaddressしか受けなければ、kernelは意図を受け取れない。Zoneを追加すると操作できる。しかし、その完成形を「世界中で同じendpoint」として保存すれば逆の誤りになる。別hostの同名interfaceは別のnetworkへ接続しているかもしれない。

RFC 9844は、このlocality boundaryを標準化した。2025年8月のStandards Trackであり、記録、TXT、XMLが同じ仕様を保存する。RFC 6874をobsoleteとし、RFC 4007、7622、8089をupdateする。公開標準であることは、特定製品のsupportや選択結果の正しさを証明しない。

Addressとpathは別のclaimである

RFC 4291はIPv6 addressingを、RFC 5952は推奨text representationを定める。Link-localはscopeを制限する設計であり、複数linkを横断するglobal uniquenessを与えない。従ってaddress bitsが正しくても、どのlocal linkを使うかは残る。

RFC 4007は内部利用にzone indexを加える。人に見せるzone identifierは、多くの場合interface nameかdecimal indexである。RFC 9844の%eth0形式は、IPv6 headerに文字を追加する方式ではない。このnodeのOSに対する選択命令である。

Interface選択はcontrol surfaceだ。Ping、configuration、capture、management requestは、valid addressのまま誤linkへ向かえる。反対にzone inputを持たないtoolは、OSなら到達できるlink-local-only deviceを管理不能にする。RFC 9844はdebugging、device configuration、monitoring、virtual printer、marine networkingをuse caseとして挙げる。RFC 6991はYANG contextを、RFC 8925はIPv6-mostly networkを示す。

長いliteralのcopy-and-pasteはerrorを減らす。しかしcopyされるのはtextだけで、interface tableは付いてこない。文字列と意味のprovenanceを分けて記録すべき理由がここにある。

UIの後ろにあるmappingが本体である

RFC 9844は、global unicast以外のIPv6 addressを許すUIにzone選択を求める。RFC 4007のcomplete formatを推奨し、難しければ別delimiter、二つのfield、active zoneのlist、独立CLI parameterを許す。見た目が違ってもinvariantは同じだ。Addressとzoneは別々に検証され、利用時にnumeric interface indexへ結び付く。

fe80::1%eth0はinet_pton()へそのまま渡せない。getaddrinfo()を使うか、addressとnameを分離し、inet_pton()とif_nametoindex()を順に使う。RFC 3493のsockaddr_in6にはsin6_scope_idがあるが、indexからinterfaceへの意味付けはimplementation固有である。

Receiptは「form accepted」で止めてはならない。Raw input、parser/policy version、lengthとcharacterのvalidation、resolved index、その時点のinterface identity、scoped destination、socket構築、operation resultを結ぶ。表示から実行までの間にinterfaceが消えた場合、古いapprovalを新しいobjectへ継承せず、raceとして失敗させる。

Running codeが区別すべき状態は少なくとも四つある。Inputを受理した。Interfaceを解決した。Packetを送った。意図したdeviceが応答した。一つのgreen badgeは四つのauthorityを混ぜる。

Local labelはboundaryで権限を失う

RFC 9844のsecurity ruleは明確だ。Zone identifierはlocal significanceしか持たず、wireへ送ってはならない。UIから得たsoftwareも先へ転送すべきでない。RFC 4007は、packetのdataとして届くtextual non-global addressを信頼しないよう注意する。Remote nodeはreceiverのlocal zoneを定義するprincipalではない。

Labelをstripすることは、audit evidenceを捨てることではない。Node内部ではname-to-index mappingがpath choiceを説明する。Network boundaryでは、そのlabelに他者を拘束する意味がない。Packet captureがlocal annotationとして表示する場合も、annotationとtransmitted bytesを分けなければならない。

この分離はautomationの誤ったportabilityも防ぐ。eth0を別hostへcopyしても、cable、network namespace、virtual topologyはcopyされない。Nameはrename/reuseされ、numeric indexはreboot後にrecycleされる。Historical recordにはhost、time、boot/lifecycle contextが必要であり、claimは「このhostがこの時点でこのように解決した」に限定される。

自由な文字列には型付きの入口が要る

RFC 4007はzone identifierのuniversal maximum lengthやcharacter setを定めない。RFC 9844はenvironmentに適したlength limit、通常はOSのinterface-name limitと、context固有のcharacter checkを求める。ASCII NULは後段のstring processingを分裂させるため拒否すべきだ。

Riskはbuffer overrunだけではない。Delimiterのdouble decode、normalizationによるlookup変化、shell metacharacter、log renderingの差、submit前に古くなるinterface listも対象だ。万能regexではなく、exact bytesを保存し、target environmentでvalidationし、useに近い場所で一度mappingし、inputとresultを共に残す。

Browser向けURI案は撤回された

RFC 6874はzoneをIPv6 URI literalへ組み込もうとしたが、status recordは現在obsoleteを示す。RFC 9844はbrowser implementerがその方式をimpracticableと判断したことを記録し、RFC 3986への変更を戻し、generic UI requirementへ置き換えた。RFC 7622とfile URIのRFC 8089からもRFC 6874参照を削る。

これはstandardがrunning realityによって狭くなる健全な例だ。RFC 9844自身もRFC 6454のHTTP origin problemを解決せず、browserがfetchするURIにはnormative statementを適用しないと明記する。本稿もそのscopeを越えない。

現れ、変換され、消えたことを試験する

Acceptance testでは、同じlink-local textを持つ二つのactive interfaceを用意し、explicit selection、unknown zone rejection、arbitrary default不使用を確認する。Selection後にinterfaceをrename/removeし、rebootでindex recycleを起こし、overlong input、NUL、delimiter variant、Unicode edge、shell/log special characterを入れる。

次にboundaryを観測する。Local receiptは使用indexを示し、packet captureはzone textが送られていないことを示す。Remote dataがzone labelを供給してもlocal policyなしに信頼しない。Mapping failureはclosed failureであり、別interfaceを選ぶ許可ではない。

最後にoperatorへ四つの状態を分けて示す。Accepted、resolved、sent、answeredである。Minimum specificationは入力可能性とlocalityを揃え、local operatorはpolicy、retention、rollbackを決め、running codeが実際のpathを証明する。

証拠の限界

本稿はOS、browser、router、printer、sniffer、YANG client、marine networkを試験していない。Support、adoption、error rate、incidentも測定していない。RFCの例はmechanismの説明であり、現行製品のcertificateではない。

確かな結論は、行動に必須のcontextが共有identityとしては無効になり得るということだ。Node内でreceiptを保存し、node外でauthorityを止める。この両方が一つのcontrolである。

出典