C01-CJ: Yes
Rationale
A native cjdns endpoint retains its key-derived IPv6 address when its UDP/CryptoAuth access peering changes. In the pinned SessionManager, sessions are indexed by IPv6 identity, getSession can update paths for an existing identity, and ordinary outgoing traffic uses an available path or requests lookup. An updated route label therefore need not change the sender's destination address.
Assessment method
Primary specification review; no runtime experiment
Source context
Yggdrasil documentation and pinned Ironwood/cjdns path management
Outstanding qualification
Witness: preserve the destination key, establish a new authorized numeric peering after loss of the old attachment, and obtain a usable route through the selected pathfinder/route-server system. Outer IPv4 locators and forwarding labels can change while the application retains the same cjdns IPv6 destination. Routing infrastructure must learn the new reachability; possession of the key alone is insufficient. No imported IP tunnel, custom label override or public discovery is introduced. New sessions may be needed after expiry; stale-label recovery, convergence delay and uninterrupted delivery remain unmeasured.
Public sources
- https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/SessionManager.c
- https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/doc/peering.md
- https://github.com/cjdelisle/cjdns/blob/f5902acab6dd2f1a68bf6e4c89e352ed71f93698/net/InterfaceController.c
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