C01-YG: Yes
Rationale
Yggdrasil derives the endpoint IPv6 address from its node key, independently of TCP/TLS peering locators. A destination that retains its key can move from an unavailable access peering to another configured peering; routing and pathfinding still target the same key-derived IPv6 address. The pinned Ironwood code manages peer removal/addition and discovers paths by destination public key.
Assessment method
Primary specification review; no runtime experiment
Source context
Yggdrasil documentation and pinned Ironwood/cjdns path management
Outstanding qualification
Witness: retain the destination key and native-node address, replace its failed adjacent private-IPv4 TCP/TLS connection with an authorized configured numeric peer in the same reachable mesh, and allow routing convergence. The sender keeps its destination IPv6 address. No public peers, DNS, routed-subnet addresses or automatic remote-peer discovery are added. Stale paths, unavailable topology and admission failures can delay or prevent recovery. Fresh sessions are allowed; existing UDP socket survival or seamless handover is not required or demonstrated. No runtime or global-scale result.
Public sources
- https://yggdrasil-network.github.io/implementation.html
- https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/router.go
- https://raw.githubusercontent.com/Arceliar/ironwood/d50055b11f5ec5b56ee4e56ba9a75261461821dc/network/pathfinder.go
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round527.html
- round527-sources.json