Address-Protected Neighbor Discovery for Low-Power and Lossy Networks
updated by
- rfc-9926 — Prefix Registration for IPv6 Neighbor Discovery
- rfc-9927 — Fixing the C-Flag in the Extended Address Registration Option (EARO)
updates
- rfc-8505 — Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
Extracted elements (31)
AP-ND separates the IID from cryptographic material, unlike SEND/CGA which derive the IID from the public key. This allows 6LoWPAN address compression (which requires L2-derived IIDs) to remain functional while still providing cryptographic proof of ownership via the ROVR/Crypto-ID.
Both the 6LR and 6LN contribute nonces (NonceLR and NonceLN), both included in the signed material. This 'contributory nonce' design provides protection against replay attacks even when one party's nonces are not generated with strong randomness.
The CIPO Modifier field (8-bit) allows a 6LN to derive multiple distinct Crypto-IDs from the same key pair for different addresses, reducing traceability without requiring multiple key pairs — a privacy enhancement specifically for constrained nodes.
The proof of ownership is validated at the edge (6LR), not the center (6LBR), to reduce DoS risk to the central registry and avoid back-and-forth exchanges across a large constrained network. The downside is that the 6LBR must trust the 6LR to perform the check, requiring protected communication between them.
This specification is only compatible with 6LRs upgraded to support it; in mixed deployments the 'A' flag must remain unset until all 6LRs are upgraded. An attacker can defeat protection by attaching to any legacy 6LR in the subnet.
A node in possession of the necessary cryptographic primitives SHOULD use Crypto-ID by default as ROVR in its registrations. A minimal size of 128 bits for the Crypto-ID is RECOMMENDED unless backward compatibility with RFC 8505 is needed (in which case at least 64 bits).
An ND message that carries an NDPSO MUST have one and only one EARO, and the EARO MUST contain a Crypto-ID in the ROVR field associated with the key pair used for the digital signature.
If the 6LR does not support the Crypto-Type presented by a 6LN, it MUST reply with EARO status code 10 'Validation Failed' without a challenge; Crypto-Type 0 (ECDSA256) MUST be supported by all 6LRs.
Public keys in the CIPO MUST be validated: for Ed25519, verify the point is not in the small subgroup; for ECDSA (ECDSA256 and ECDSA25519), verify the point has the same order as the base point (full public key validation).
The 6LR MUST indicate to the 6LBR that it performed a successful validation by setting status code 5 ('Validation Requested') in the EDAR. Upon a subsequent EDAR from a new 6LR without status 5 for a validated Binding, the 6LBR MUST return status 5 in the EDAC to require re-challenge.
The 6LR MUST protect itself against registration overflows and reject excessive registrations with status code 2 'Neighbor Cache Full' to prevent a DoS attack via mass address registration.
The 6LR MUST store the information associated with a Crypto-ID on the first NS exchange in a fashion that the CIPO parameters can be retrieved from the Crypto-ID alone. A valid registration MUST NOT be altered until a challenge is complete.
The ECDSA256 signature scheme (ECDSA with NIST P-256 and SHA-256) MUST be supported by all implementations. The Ed25519 and ECDSA25519 schemes MAY be supported as alternatives.
The same private key MUST NOT be reused with more than one instantiation of the signature scheme, and MUST NOT be used for anything other than computing NDPSO signatures. Each ECDSA signing operation MUST use a freshly randomly generated ephemeral private key k.
When the 'A' flag in a subnet is set, the 6LR MUST challenge the 6LN before creating a Binding with the 'C' flag set in the EARO, and MUST also challenge when a new registration attempts to change a parameter of an already-validated Binding.
Using the same Crypto-ID across multiple address registrations enables an attacker observing registrations to correlate traffic to the same 6LN. The Modifier field enables multiple Crypto-IDs per key pair, improving privacy; however, if 6LR state is compromised, the shared public key still links the registrations.
The 6LoWPAN Capability Indication Option (6CIO) gains a new 1-bit 'A' flag (bit 9) to indicate AP-ND is globally activated in the network. It is set by the 6LBR and propagated unchanged by 6LRs, and SHOULD be turned on only after all 6LRs are upgraded.
The Crypto-ID is derived by applying the hash function indicated by the Crypto-Type to the CIPO (with all reserved and padding bits set to zero), then taking the leftmost bits of the resulting hash up to the desired size. It is transported in the ROVR field of the EARO and associated with the Registered Address at the 6LR and 6LBR.
The NDPSO signature is computed over: the 128-bit CGA Message Type tag, the CIPO, the 16-byte Target Address, the NonceLR, the NonceLN, and the 1-byte EARO option length — concatenated in that order and signed with the private key using the algorithm indicated by Crypto-Type.
IANA assigned a new 128-bit CGA Extension Type Tag under the 'CGA Extension Type Tags' subregistry: 0x870155c80ccadd326ab7e415f14884d0, for use as the message type tag in NDPSO signature computation.
IANA created the 'Crypto-Types' subregistry in the ICMPv6 Parameters registry, indexed 0–255. Each entry specifies elliptic curve, hash function, signature algorithm, representation conventions, public key size, and signature size. Values 0 (ECDSA256), 1 (Ed25519), and 2 (ECDSA25519) are defined. New values require 'Specification Required' or 'IESG Approval'.
IANA registered a new 6LoWPAN Capability Bit (bit 9) for 'AP-ND Enabled' in the '6LoWPAN Capability Bits' subregistry created for RFC 7400.
IANA registered two new IPv6 Neighbor Discovery Option types: Type 39 for the Crypto-ID Parameters Option (CIPO) and Type 40 for the NDP Signature Option (NDPSO), both under the 'IPv6 Neighbor Discovery Option Formats' subregistry.
Careless implementations of Ed25519 signing may leak private key material via micro-architectural side channels; a secure Ed25519 implementation requires a protected SHA-512 implementation, which is not necessary for ECDSA256/ECDSA25519 using SHA-256.
If a 6LR is compromised and knows the real owner's ROVR, it can falsely claim the owner moved and passed validation, then attract/inject traffic or allow an attacker to steal address ownership. The 6LBR–6LR link MUST be integrity-protected to limit this threat.
In a brown (mixed) network, an attacker may attach to a legacy 6LR that cannot perform the Crypto-ID challenge. Security is only fully effective after all 6LRs in the network are upgraded; the 'A' flag should be set only at that point.
ROVR (Crypto-ID) collisions are possible but rare; a 64-bit Crypto-ID yields a 0.01% collision probability for 66 million nodes. To avoid an honest node accidentally claiming another's address, nodes SHOULD NOT derive their registered address from the ROVR.
First exchange with a 6LR: 6LN sends NS(EARO, C-flag) → 6LR challenges with NA(EARO, status=Validation Requested, NonceLR) → 6LN responds with NS(EARO, CIPO, NonceLN, NDPSO) → 6LR verifies and replies with NA(EARO). Subsequent renewals skip the challenge if state is consistent.
The Crypto-ID Parameters Option (CIPO) carries the public key and algorithm parameters: Type=39, 8-bit Length, 5-bit Reserved1, 11-bit Public Key Length, 8-bit Crypto-Type, 8-bit Modifier, 8-bit EARO Length, variable-length Public Key, and zero-padded to the next 8-byte boundary.
The NDP Signature Option (NDPSO) carries the digital signature: Type=40, 8-bit Length, 5-bit Reserved1, 11-bit Digital Signature Length, 32-bit Reserved2, variable-length Digital Signature, and zero-padded to the next 8-byte boundary.
The updated Extended Address Registration Option (EARO) adds a 1-bit 'C' flag (bit 4 of the second word) to indicate the ROVR field contains a Crypto-ID. Type is 33; reserved bits MUST be zero on send and ignored on receive.