Summary

  • RFC 9915 uses lease terminology for self-generated-address registration: the device selects its SLAAC or static address, while the DHCPv6 server creates a lease representing the registration. A lease record therefore does not necessarily mean that DHCPv6 assigned the address.
  • RFC 9686 supplies a standard observation mechanism for non-link-local, self-generated and statically configured IPv6 addresses. Its reply confirms receipt and stops client retransmission; it does not guarantee storage, authenticate a user, prove reachability or show that the address sent a particular packet.
  • RFC 9915’s lease and RFC 9686’s Client-Identifier-to-address binding are related but normatively distinct. The current DHCPv6 architecture says the server creates the lease; RFC 9686 separately says the server SHOULD create the binding.
  • Inventory systems should preserve address origin, assertion provenance, validation status, receipt, persistence, lifetime and identity evidence as separate fields. Flattening them into a generic “lease owner” object creates misleading certainty.

The word “lease” once gave many network operators a convenient mental shortcut. A DHCP server had allocated an address, the client had accepted it, and the server held a time-bounded record of that allocation. The shortcut was never a complete theory of identity, but it often captured the origin and lifecycle of a resource well enough for inventory work.

Self-generated IPv6 address registration breaks that compression.

RFC 9915, which obsoletes RFC 8415 and incorporates RFC 9686 into the current DHCPv6 base specification, says in Section 6.6 that the device performs address selection for self-generated-address registration and the server creates a lease for the registered address. Both statements matter. A host may select an address through SLAAC or use a static configuration established outside DHCPv6. DHCPv6 did not assign that address. The server nevertheless creates a lease to represent its registration lifecycle.

The resulting terminology is precise at protocol level but hazardous in a coarse data model. “Lease” can describe server-side state without implying server-originated address selection. A database column that treats lease as synonymous with assigned_by_dhcpv6 therefore loses a distinction the standards preserve.

RFC 9686, an IETF Standards Track specification published through the DHC working group in December 2024, exists because DHCPv6 servers otherwise have limited visibility into self-generated or statically configured IPv6 addresses. It gives clients a DHCPv6 mechanism for registering those addresses. It does not transfer address selection to the server.

The protocol begins with an explicit capability exchange. A client requests the capability, and a server advertises support by including OPTION_ADDR_REG_ENABLE in an Advertise or Reply. If the client has not received that indication, it MUST NOT use the registration procedure. Support advertisement is thus a prerequisite, but it is not evidence that any later registration occurred.

After a valid address has been created or configured, the client multicasts an ADDR-REG-INFORM containing a Client Identifier and an IA Address. The IA Address must match the IPv6 source address of the message or, in a relayed exchange, the peer-address in the innermost Relay-forward message. Link-local addresses are outside the mechanism’s scope.

That matching rule constrains what a client can present. It ties the registered address to network-visible message context rather than permitting an unrestricted statement about an arbitrary address. It does not transform the Client Identifier into a person, establish ownership, authenticate the claimant or demonstrate that the address is reachable from elsewhere.

The server’s processing requirements need equally careful translation into schema semantics. It discards malformed or contradictory messages. It SHOULD verify that the address is appropriate to the link from which the message was received or belongs to a prefix delegated to the client. If the server performs that verification and it fails, it MUST discard the message and SHOULD log the failure.

The conditional structure matters. Appropriate-link or delegated-prefix verification is a SHOULD, not an unconditional MUST. An inventory should therefore record whether the check was performed, what context supported it and what result it produced. Seeing an accepted registration does not justify silently upgrading a recommended verification into a universally completed one.

For an accepted registration, the server MUST log the event unless configured not to do so. It SHOULD create a binding between the Client Identifier and the registered address, and it SHOULD mark the address as unavailable for assignment by the server. It MUST return ADDR-REG-REPLY.

Those requirements must not be collapsed. RFC 9915 says the server creates a lease for the registered self-generated address. RFC 9686 separately gives SHOULD strength to creation of the Client-Identifier-to-address binding. The lease terminology describes the server-side registration lifecycle in the current DHCPv6 architecture; it does not convert RFC 9686’s binding recommendation into a MUST.

ADDR-REG-REPLY has a still narrower meaning. Its arrival tells the client that the server received the registration and causes the client to stop retransmitting. It does not guarantee that the recommended binding was created or persisted. It does not prove that logging was enabled, that the address was valid beyond the client’s assertion, or that any later packet used the address.

A migration therefore has to preserve several outcomes that a single “lease successful” field would erase:

Protocol or system fact Defensible interpretation Unsafe expansion
Lease created under RFC 9915 The server created lifecycle state for a registered, device-selected address DHCPv6 assigned the address
ADDR-REG-REPLY returned The server received the registration; retransmission may stop The registration was durably stored
RFC 9686 binding present The recommended Client-Identifier-to-address binding was created A person or device owner was authenticated
Log entry present The configured logging path recorded the event The lease or binding remained valid at another time
Address marked unavailable The server reserved it from its own assignment pool The address was unique everywhere or legitimately used

The lease should consequently carry explicit origin. Useful values might distinguish DHCPv6 address assignment, DHCPv6 prefix delegation and client-selected address registration. The exact local vocabulary matters less than retaining the distinction. A common resource table can still be used, but every consumer must be able to determine who selected the address, how the server learned about it and which lifecycle rules apply.

The lifecycle of a registered SLAAC address contains another trap for monitoring systems. RFC 9686 defines NextAddrRegRefreshTime from 80% of the address’s Valid Lifetime, multiplied by a 0.9–1.1 desynchronisation factor. Calculating that value does not, by itself, schedule a periodic refresh transmission.

For SLAAC, refresh scheduling is driven by a network-advertised change in Valid Lifetime beyond the tolerance specified by the RFC. The client recalculates the timing information when that change occurs. If the address’s expected expiration time continues to decline normally and does not materially change, a refresh need not be scheduled or sent merely because the previously calculated interval has elapsed. Absence of periodic SLAAC refresh traffic is therefore not, on its own, an integrity anomaly.

This is materially different from treating 80% of Valid Lifetime as a recurring heartbeat. A monitor designed around that mistaken model would manufacture missing-refresh alarms for compliant clients and might incorrectly expire or distrust valid registration evidence. The useful records are the advertised lifetime inputs, the calculated NextAddrRegRefreshTime, any qualifying lifetime change, the resulting scheduling decision and any registration actually transmitted.

Static addresses follow another pattern. Their registration refresh interval defaults to a configurable four hours. A registration carrying a zero Valid Lifetime expires the binding. In both cases, time remains essential, but the timer model must be interpreted according to the address origin rather than imposed uniformly across all leases.

Address uniqueness belongs to a separate subsystem. RFC 4862 describes Duplicate Address Detection as testing whether an address is likely to be unique on the link, while warning that DAD is not completely reliable. It does not authenticate the claimant. Passing DAD, registering an address, creating a lease and receiving a reply are related operational events, but none substitutes for the others.

Link attachment can sometimes be supported more strongly by Source Address Validation Improvement. RFC 9686 notes that with First-Come, First-Served SAVI, the server can trust that the registration came from the legitimate holder of the address. The scope of that trust is defined by RFC 6620: it depends on the SAVI protection perimeter and binding anchor, and the solution is no stronger than that anchor. Within RFC 6620 FCFS SAVI, only switch ports are permitted as binding anchors.

A switch port can be excellent attachment evidence while remaining poor human-identity evidence. It may sit upstream of a phone, access point, hypervisor, downstream router or shared workstation. Even when SAVI strongly supports an address-to-anchor relationship, other records are needed to determine which managed device, subscriber account or user session occupied the context at the relevant time.

Nor does any kind of lease demonstrate packet use. A firewall event, application log or flow record is a separate observation. RFC 9099 recommends combining multiple sources for IPv6 forensic work, including application and IPFIX logs, Neighbor Cache history, DHCPv6 state, SAVI bindings, switch and router interface information, firewall records, authentication data and RADIUS accounting.

An operational evidence model should therefore resist the urge to build a universal address-owner row:

Dimension Questions the record should answer
Address origin Was the address assigned by DHCPv6, selected through SLAAC, statically configured or learned another way?
Lease lifecycle When did the server create the lease, and what lifetime or expiry rules govern it?
Registration assertion Which Client Identifier asserted which address, and when?
Message context What source address, relay peer-address, relay chain and ingress context were observed?
Validation Which checks were performed, omitted or failed?
Server response Was ADDR-REG-REPLY sent, and when?
Persistence Was the recommended binding created? Was logging enabled?
Attachment evidence What Neighbor Cache, SAVI, interface or topology records support network location?
Traffic evidence Which independent sensor observed the packet or flow?
Identity evidence Which authentication, subscriber, device-management or accounting record supplies an identity link?
Policy authority Which rule permits notification, restriction, quarantine or disconnection?

This structure accommodates related IPv6 mechanisms without confusing them. RFC 9131 describes gratuitous Neighbor Discovery as a way for nodes to advertise link-layer address changes rapidly; that signalling has different purpose and evidentiary content from DHCPv6 address registration. RFC 7844 defines anonymity profiles for DHCP clients, reminding operators that Client Identifier availability and stability are policy-sensitive rather than universal assumptions.

The upgrade path from an older DHCPv6 inventory is therefore semantic as well as technical. Operators should identify every place where “lease” is interpreted as “server assigned”: database views, APIs, SIEM enrichments, incident playbooks, support screens, billing joins and access controls. Origin and provenance fields should exist before registration leases are imported. Historical records may need an “unknown origin” value rather than a confident but unsupported reclassification.

Interfaces should expose the distinction in ordinary language. “DHCPv6-assigned address” and “device-selected, DHCPv6-registered address” are longer labels than “lease”, but they prevent the interface from implying an authority the transaction never exercised. Where space is limited, origin badges or filters can preserve the difference.

The architecture reflects a broader design principle: a common protocol can standardise observation while leaving local systems responsible for interpretation. Lu Heng’s discussion of running-code primacy is useful because operational behaviour—not a familiar label—reveals who selected the address and what the server did. The principle of a minimum common specification and local choice explains why interoperable registration need not dictate one retention or enforcement policy. The account of reality layers helps distinguish a protocol event, its database representation and the institutional meaning later attached to it.

RFC 9686 restores visibility into an important class of IPv6 addresses. RFC 9915 places that function within the modern DHCPv6 architecture and explicitly says the server creates a lease for the registration. The engineering task in 2026 is not to resist that terminology. It is to ensure that “lease” records how state is maintained without erasing how the address came into being.

Sources