Summary

  • draft-ietf-snac-simple-12 specifies automatic IPv6 connection between a stub network and an adjacent infrastructure link, using distinct machinery for addressability, reachability and discoverability.
  • Restart and failover can leave a new on-link or off-stub-network-routable prefix beside old addresses and routes that remain valid. A fresh RA, visible service or green router state does not prove application continuity.
  • Operators need a bounded transition receipt that preserves the state change, lifetimes, route observation, discovery observation and address-specific application result without turning local evidence into a central authority.

Automatic connection is several clocks, not one fact

Revision 12 of Automatically Connecting Stub Networks to Unmanaged Infrastructure tackles a practical problem. A constrained IPv6 network—an IoT mesh is the obvious example—may need to reach a Wi-Fi or Ethernet infrastructure link whose media and framing are incompatible. A Stub Network Auto-Configuring router, or SNAC router, supplies the bridge in function without pretending the two links are one layer-two network.

The draft's own vocabulary prevents an important mistake. It treats addressability, reachability and discoverability as separate functions. A stub host needs an address usable beyond the stub. Infrastructure hosts need a route back. DNS or DNS Service Discovery needs to reveal the service. These conditions can all be necessary, but none is sufficient for the application transaction that motivated the connection.

That distinction becomes visible during restart. “The network is back” can mean that a router has resumed sending advertisements, that a host has configured a new address, that a Route Information Option has appeared, that a service name is visible, or that a command has completed. Each statement has its own observer and expiry rule.

Suitability has two tests

When a SNAC router attaches to the adjacent infrastructure link, it first performs IPv6 router discovery under RFC 4861. If it finds a suitable on-link prefix, the interface enters STATE-SUITABLE. If discovery concludes without one, it enters STATE-BEGIN-ADVERTISING and supplies a prefix itself.

A received prefix is not suitable merely because its PIO parses and its lifetime has not reached zero. Revision 12 requires two complementary observations. First, the router records when each Router Advertisement arrived. An RA older than STALE_RA_TIME—ten minutes by default—cannot support suitability. Second, it monitors neighbor reachability to the router that advertised the prefix, using a maximum suitable reachable time of sixty seconds before active solicitation is required.

The difference matters. A router may still answer as a neighbor while silently failing to refresh the RA that new hosts need. An RA may also be recent while the advertiser has since disappeared. The state machine refuses to let the prefix string stand in for the continuing behaviour of its source.

If the last non-stale suitable RA ages out, the SNAC router begins advertising. If a Router Solicitation arrives and none of the relevant routers is reachable, it does the same. The resulting decision is local and timed: this observer, at this moment, has insufficient evidence that another router continues to provide usable addressability.

Deprecation deliberately permits overlap

In STATE-BEGIN-ADVERTISING, the SNAC router generates an on-link prefix and advertises it with preferred and valid lifetimes equal to STUB_PROVIDED_PREFIX_LIFETIME, thirty minutes by default. It also includes a Route Information Option for each off-stub-network-routable, or OSNR, prefix known on the stub network.

Later, a preferable prefix may appear. A non-SNAC infrastructure prefix outranks a different SNAC-provided prefix; between two ULA prefixes, the draft supplies a deterministic comparison. The current router then enters STATE-DEPRECATING.

Deprecating does not mean erasing. The router keeps advertising its old prefix, sets its preferred lifetime to zero and decreases its valid lifetime as time passes. If the alternative disappears before that period ends, the router can return to advertising its own prefix with renewed lifetimes. This is a sensible rollback path. It is also an explicit interval in which old and new state coexist.

Hosts do not share one memory. They received different RAs at different times, may have missed a multicast packet, and make their own address-selection decisions. The router's clean transition from advertising to deprecating does not reveal which host still holds which address, which source address a new connection will select, or whether an existing flow can survive.

RFC 8978 describes the wider flash-renumbering problem: a new prefix can appear without reliable withdrawal of the old one, leaving hosts to retain stale state. Its seven-day preferred and thirty-day valid default example belongs to general SLAAC, not to SNAC's thirty-minute default for a prefix it supplies. The numbers must not be blended. The governance lesson is common: lifetime validity and operational usefulness are different predicates.

A returning router can inherit its own ghost

The draft's first restart scenario is unusually concrete. Suppose two SNAC routers share an adjacent link. Router A was providing an on-link prefix, then went offline. Router B took over with a different prefix. When A returns, it sees B's suitable advertisement and therefore does not resume advertising its own old prefix.

Some hosts may still use addresses from A's prefix. A can receive packets for those addresses, yet it no longer considers the prefix on-link. It may forward the traffic toward its default router or drop it. The specification states the user-facing consequence plainly: control of IoT devices may be temporarily lost and automations may fail.

This is not evidence that every restart renumbers the network. Revision 12 expects a router to persist its self-generated OSNR prefix across reboots, and a DHCPv6-PD client commonly receives the same prefix again. The dangerous interval arises when state is not preserved, absence lasts long enough for takeover, the attachment changes, a lease expires or returns differently, or a mesh partitions and heals.

The second scenario reduces the risk by letting all routers for one stub network derive the same stable /64. Thread's Extended PAN ID is the example. Even that continuity has an operational condition: the draft expects stability so long as all routers supporting the same stub network do not restart at once. The prefix is durable because a distributed set retains the necessary state, not because the identifier has escaped failure.

The OSNR prefix has another continuity problem

An OSNR prefix is the address space a stub host can use with hosts beyond the stub. It may be delegated through DHCPv6 Prefix Delegation under RFC 9915, or it may be a self-generated ULA under RFC 4193.

If the sole router advertising that prefix disappears, other SNAC routers can continue advertising routes to it on the infrastructure link. Ideally they would preserve the prefix until the original router returns. Revision 12 deliberately leaves the coordination method out of scope. If the old prefix nears expiry, another router can advertise its own OSNR prefix. Routers that remember the old prefix continue advertising a route to it until it expires.

That overlap protects communication which may still exist. It also creates an evidence problem: a route to an old valid prefix and a new preferred prefix can both be correct at the same time. “There is a route” cannot say which address a host selected, whether the route terminates at the correct partition, or whether the application accepted the change.

Discovery can succeed while the route is absent

The troubleshooting section gives a useful falsifier. An infrastructure network may use RA Guard to block Router Advertisements from the SNAC router. Multicast DNS can remain unaffected, so the service is discoverable. But infrastructure hosts do not receive the RIO and therefore install no route to the OSNR prefix.

The service card can look healthy while packets cannot return. Outbound communication through SNAC-provided NAT64 may still work, adding another apparently positive signal. Diagnosis requires comparing the router's record that it advertised the route with a representative host's actual route table. RFC 6762 and RFC 6763 explain discovery; RFC 4191 explains the route option. Neither observation can impersonate the other.

A continuity receipt should preserve the disagreement

Revision 12 recommends timestamped records of renumbering, deprecation and invalidation, changes in the router providing the AIL prefix, and loss or return of a default route. That is the right starting point. Leadership needs the record to extend across observers.

For each transition, preserve the router and boot identity; timestamp and clock quality; prefix and whether it is AIL on-link or stub OSNR; previous and new state; the RA source, time and bounded reference; the staleness and neighbor-reachability decision; preferred and valid lifetimes; deprecation start and expected expiry; RIO advertisement; a representative host's installed route; discovery result; and a controlled application transaction with the address actually selected.

This is not a proposal for a global prefix registry. It is a portable shape for local evidence. Storage duration, access, remediation and product policy remain with the operator. Heng Lu's Minimum Initial Specification principle applies precisely because the receipt should make different implementations comparable without relocating future operating authority.

The receipt also respects the Reality Layers doctrine. A message is a symbolic assertion. A state-machine transition is a local model. An installed route is an operating condition. A completed transaction is an event. Keeping them adjacent but separate is how an automatic network becomes auditable without pretending that one layer governs all the others.

Sources

  1. SNAC revision 12
  2. SNAC revision history
  3. Revision 12 HTML
  4. Revision 12 text
  5. Official revision 11 to 12 diff
  6. RFC 4861 — IPv6 Neighbor Discovery
  7. RFC 4191 — Router Preferences and More-Specific Routes
  8. RFC 4193 — Unique Local IPv6 Unicast Addresses
  9. RFC 8978 — Reaction to SLAAC Flash Renumbering
  10. RFC 6762 — Multicast DNS
  11. RFC 6763 — DNS-Based Service Discovery
  12. RFC 7084 — IPv6 Customer Edge Router Requirements
  13. RFC 6146 — Stateful NAT64
  14. RFC 7050 — Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
  15. RFC 9915 — DHCPv6
  16. Lu Heng — Minimum Initial Specification
  17. Lu Heng — On Reality Layers
  18. Lu Heng — Running Code Primary