Summary

  • The individual HCGA draft proposes deriving the IPv6 subnet bits between an operator-controlled aggregate and /64 from a public key, extending the interface-identifier binding in RFC 3972.
  • With a /48 aggregate, those subnet bits number 16. A second key can find a matching /64 in roughly 2^16 trials, so the operator needs an exclusive admission record and source-address enforcement before treating that /64 as evidence of a workload.

Two keys can arrive at the same subnet door. The address does not appoint the winner. That is the less glamorous rule inside Hierarchical Cryptographically Generated Addresses, an individual Internet-Draft dated 27 October. It tries to give a workload or agent a key-derived IPv6 /64 beneath an operator’s aggregate. The cryptography makes a recorded relationship checkable; the operator must still say which key got the /64.

Under RFC 3972, a cryptographically generated IPv6 address derives its lower interface identifier from a public key, while infrastructure supplies the /64 prefix. HCGA proposes to derive the subnet bits above that boundary from the same key, plus a prefix modifier. The aggregate remains controlled by the network operator. A verifier can recalculate the relationship if it has the key, modifiers and collision count. That extra information has to reach the verifier somehow.

The paper’s own security section puts a number on the problem. With a /48 aggregate, only 16 bits stand between the aggregate and each /64. A second key or prefix modifier can be tried until those bits collide, at roughly 2^16 attempts. This is a lookalike subnet, not a 2^16 attack on the whole 128-bit address or its private key. The full interface identifier has its own, much larger hash-output bound. The /64 alone therefore cannot name a unique key.

The draft asks a surrounding architecture to record which public key and prefix modifier were admitted to a /64 and to enforce exclusivity. It also says the address alone does not prove who sent a packet: a signature from the corresponding private key or network source-address controls must join it. For an investigator away from the local link, the generation parameters have to have been retained. Lose that admission record, and the convenient self-checking address has no recoverable owner at the granularity the proposal wants.

The route evidence has a different scope. The operator advertises the aggregate via BGP under an RPKI ROA; internal /64 routes are not announced externally. A valid aggregate route helps establish who may originate the broad prefix. It does not identify which workload key was accepted for one internal /64. That narrower appointment sits with the operator’s local admission and enforcement process.

There is a privacy price for a successful appointment. The draft says a /64 remains stable when the lower interface identifier changes, making traffic under that subnet linkable. RFC 8981 describes temporary IPv6 address practice with a different privacy aim. Key assurance is another separate decision: the HCGA check cannot tell a hardware-protected key from a software key. The RATS architecture supplies a framework for attestation evidence; this proposal leaves its use to the wider deployment.

The Datatracker record lists an individual Standards Track draft at I-D Exists. A useful trial would generate two keys whose subnet bits collide under one test /48, reject the second at admission, then ask an off-link verifier to reconstruct the first key, parameters and packet-origin proof from retained records. The address can help catch a changed registry entry. The registry still has to exist.