jschoubben
274bd3b304
Address family was not a field. IPv6 usually has no NAT, so a machine behind a household gateway is typically unforwardable on v4 and DIRECTLY ATTACHED on v6, at the same moment. The three positions therefore apply per family, and reachability is a property of (machine, family) rather than of a machine. The consequence is bigger than the syntax: 'can these two nodes reach each other' stops being a yes/no question. It is asked once per family, and the asymmetric answers are the interesting ones. A mesh treating reachability as one fact per node reaches a peer over one family, fails over the other, and reports whichever it tried. That distinction did not exist in the model and would have been found by a failure rather than by reading. Two fields follow from it. inbound: allow|deny became necessary because with NAT unreachability was implied by topology, while a globally routable v6 address is reachable unless something refuses — so refusing has to be sayable or v6 addressing silently implies reachability. And nat: became a list of families rather than a boolean, because a real gateway translates v4 and routes v6 and a boolean cannot say that. mapping_ttl closes the keepalive gap: a mesh holding a connection through NAT without refreshing it works perfectly until the far side goes quiet for longer than the mapping lives. segments[].mtu closes the fragmentation gap: an overlay adds a header, so a tunnel over a reduced-MTU path establishes a connection and then silently drops large packets. at: takes a list, so a multi-homed machine is expressible — which the model already implicitly required, since a border machine sits on two segments. v6 uses RFC 3849 documentation space, the exact counterpart of the RFC 5737 rule and load-bearing for the same reason. Remaining: nested forwarding and an address changing in place, both extensible when needed. Path quality stays deliberately out — it changes performance, not correctness, and modelling it makes a network simulator rather than a fixture.
03-DESIGN / 01-to-be
The mesh being built toward. Every statement here traces to a record in
02-DECISIONS/; nothing arrives by drafting.
A document here describes an intention. What currently runs is in
00-as-is/, and the two are never merged — when something ships, the as-is
document is written and this one's status becomes implemented.
| Document | Covers | Rests on |
|---|---|---|
00-work-breakdown.md |
How the decomposition gets built, in what order, and where a human must look | ADR 0015 |
01-end-to-end-testing.md |
The lab: a real mesh a change can be run against before it reaches nodes | ADR 0016, 0029 |
02-scenario-declaration.md |
What a scenario declares — the underlay, and what to place on it | ADR 0031 |
Not yet written
- The eight bounded contexts. ADR 0015 decides the decomposition; the per-context specifications do not exist yet. The work breakdown says in what order they are needed.
- Domain grouping outside the core. ADR 0017 settles the principle and explicitly does not settle the domain list. That is a research effort, not a design document, until it concludes.