6.2 Addresses
6.2.1 Which prefixes form addresses #
A prefix information option forms addresses only when its A flag is set, its prefix length is exactly 64, and its preferred lifetime does not exceed its valid lifetime. Any other prefix option is ignored whole. A prefix with only the L flag gets no address, and no on-link route, because the kernel's RA handling is off.
A prefix seen for the first time is taken only with a valid lifetime above zero.
6.2.2 The stable address #
Each accepted prefix gets one stable address (RFC 7217): the prefix's first 64 bits, followed by the first 8 bytes of a SHA-1 digest of:
- the bytes
peios-ndp-stable-iid|; - the machine's 32-byte secret;
- the prefix's first 8 bytes;
- the interface id's text;
- a one-byte counter, starting at 0.
When the resulting interface identifier is reserved (RFC 5453: all zeros,
0200:5eff:fe00::/40, or fdff:ffff:ffff:ff80 to
fdff:ffff:ffff:ffff), the counter is incremented and the digest taken
again, up to 8 times.
So the same machine on the same network has the same address on every boot, a different network sees an unrelated address, and no MAC address ever appears in it. The address is a function of the interface id, so a kernel rename does not change it either.
6.2.2.1 The secret #
The 32-byte secret is read from /var/state/netd/secret the first time an
interface starts router discovery. When the file does not hold exactly
32 bytes, a new secret is drawn from /dev/urandom and written there; a
failure to write is logged and the new secret used for the rest of the
process's life. Losing the secret renumbers the machine, and does
nothing else.
6.2.3 Lifetimes #
A lifetime of 0xffffffff is forever. Others count from the moment the
advertisement arrived.
When an advertisement updates a prefix already held:
- the on-link flag and the preferred lifetime are taken as advertised;
- the valid lifetime uses the two-hour rule from RFC 4862 §5.5.3(e), with the infinite-lifetime exception described below:
| Advertised valid lifetime | Remaining valid lifetime | Result |
|---|---|---|
| above two hours, or above what remains | any finite | the advertised lifetime |
| two hours or less, not above what remains | two hours or less | unchanged |
| two hours or less, not above what remains | above two hours | two hours from now |
| above two hours | forever | the advertised lifetime |
| two hours or less | forever | forever |
The table records the 0.1.7 behaviour this manual describes; it is also present in netd 0.1.8 source. The final row is a known deviation: infinity is above two hours, so RFC 4862 §5.5.3(e)(3) requires two hours from the new advertisement, including when the advertised lifetime is zero. A source build containing the proposed source correction uses that deadline; it still accepts advertised lifetimes above two hours, including infinity, and takes the preferred lifetime as advertised. This source correction does not establish that an installed package or image has changed.
When a prefix's preferred lifetime runs out, its addresses are deprecated: kept on the interface for standing connections, with a preferred lifetime of zero so that nothing new chooses them (§4.3). When its valid lifetime runs out, the prefix and its addresses are removed.
6.2.4 Flags on the address #
An address in a prefix advertised on-link (L set) is added normally,
so the kernel adds the prefix route. One advertised off-link is added
with IFA_F_NOPREFIXROUTE, so the kernel adds no prefix route for it.
6.2.5 Temporary addresses #
With Address.Temporary in the profile, each prefix also carries
temporary addresses (RFC 8981):
- one is formed with the prefix when the prefix arrives with a preferred lifetime above zero;
- its interface identifier is random, avoiding the reserved identifiers, the stable address and the prefix's other temporaries;
- its preferred lifetime is one day minus a random 0 to 599 s, so a rack of machines does not regenerate together, and its valid lifetime is two days. Each is cut to the prefix's own lifetimes.
When the newest temporary is no longer preferred while the prefix still is, a new one is formed. The old one stays, deprecated, until its valid lifetime ends. A prefix keeps at most four temporaries, dropping the oldest beyond that.
A temporary is deprecated when its own preferred lifetime or its prefix's has run out, and removed when its own valid lifetime or its prefix's has.
Address.Temporary is read when router discovery starts. Changing it is a
profile edit, which restarts discovery (§3.3).