Home Networking Control Protocol
updated by
- rfc-8375 — Special-Use Domain 'home.arpa.'
Extracted elements (35)
HNCP should not be used for data that changes rapidly and constantly, because it is built on DNCP which is designed for slowly-changing state. For services like naming and service discovery, HNCP only transports DNS server addresses rather than per-name or per-service data, keeping state churn proportional to the number of external connections rather than the home network size.
HNCP uses the "HOMENET" DHCP user class string to distinguish internal DHCP servers from external ones. Because other HNCP nodes will reject requests containing this user class, any DHCP server that replies is unambiguously external (or a malicious internal node), enabling reliable automatic border detection without requiring out-of-band coordination.
IPv4 addresses and prefixes are encoded using IPv4-mapped IPv6 address format (RFC 4291) in all HNCP TLVs, with IPv4 prefix lengths increased by 96. This allows a single TLV format to handle both IPv4 and IPv6 without requiring duplicate field definitions for the dual-stack case.
All internal devices running DHCP servers on links where auto-detection is used MUST ignore or reject DHCP-Requests containing a DHCP user class consisting of the ASCII string "HOMENET". The DHCP client performing auto-detection MUST include this user class in all requests.
An HNCP router SHOULD create a ULA prefix if there is no other IPv6 prefix with a preferred time greater than 0. An HNCP router MUST create a private IPv4 prefix whenever it wishes to provide IPv4 Internet connectivity and no other private IPv4 prefix with Internet connectivity currently exists. Creation of ULA and IPv4 prefixes MUST be delayed by a random time between 0 and 10 seconds.
An HNCP router using auto-detection on an interface MUST run the appropriately configured DHCP clients as long as the interface without a fixed category is active and SHOULD wait for a reasonable time period (5 seconds default) before treating a newly activated or previously external interface as internal.
Each HNCP router sends Router Advertisements on interfaces intended to be used by clients and MUST at least include a Prefix Information Option for each Applied Assigned Prefix that it assigned to the respective link in every advertisement.
Each node MUST include an HNCP-Version TLV indicating the currently supported version in its node data and MUST ignore (except for DNCP synchronization) any TLVs with type greater than 32 published by nodes that did not also publish an HNCP-Version TLV.
For IPv6 prefix assignment, whenever at least one available prefix of length 64 exists, a /64 MUST be selected unless configured otherwise. For IPv4 delegated prefixes, a prefix of length 24 SHOULD be preferred.
HNCP nodes MUST ignore all Node-State TLVs received via multicast on a link that has DNCP security enabled, to prevent spoofing of node state changes.
HNCP nodes MUST NOT start advertising a node address already advertised by another node. An address MUST NOT be used unless it has been advertised for at least ADDRESS_APPLY_DELAY (default 3 seconds) consecutive seconds. When the same address is advertised by more than one node, all but the one with the greatest node identifier MUST be removed.
HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on all endpoints. The default keep-alive interval is 20 seconds with a multiplier of 2.1 on virtually lossless links; a considerably higher multiplier (e.g., 15) should be used on lossy links.
HNCP nodes MUST use the leading 64 bits of the MD5 message digest as the DNCP hash function H(x) for building the DNCP hash tree.
HNCP unicast traffic SHOULD be secured using DTLS over UDP port 8232. A node implementing HNCP security MUST support the DNCP Pre-Shared Key (PSK) method, SHOULD support the PKI-based trust method, and MAY support the certificate-based trust consensus method.
HNCP uses UDP datagrams on port 8231 over link-local scoped IPv6, with unicast and multicast (FF02:0:0:0:0:0:0:11). Received datagrams where either IPv6 source or destination address is not link-local scoped MUST be ignored. Each node MUST be able to receive UDP datagrams with a payload of at least 4000 bytes.
If no Managed-PSK TLV is currently being announced, an HNCP node using this mechanism MUST create one after a random delay of 0–10 seconds with a 32-byte random key. The node advertising the Managed-PSK TLV MUST generate and advertise a new random one whenever an unreachable node is removed from the DNCP topology.
In case of DNS zone naming conflicts, the announcement of the node with the greatest node identifier takes precedence and all other nodes MUST cease to announce the conflicting TLV. The default network-wide zone is ".home" but an administrator MAY configure a Domain-Name TLV for a different one.
PSKs for individual protocols SHOULD be derived from the managed random PSK using a suitable one-way hashing algorithm (e.g., HKDF based on HMAC-SHA256 with the protocol name in the info field), so that disclosure of any derived key does not impact other users. Derived PSKs MUST be updated whenever the managed PSK changes.
The elected stateful DHCPv6 server MUST serve stateful DHCPv6 and all other nodes MUST NOT. DHCPv6 stateful address lease renew and rebind times SHOULD NOT exceed 5 minutes to support fast renumbering.
Trickle Imin SHOULD be 200 milliseconds but MUST NOT be lower, and Imax SHOULD be 7 doublings of Imin but MUST NOT be lower. The redundancy constant k SHOULD be 1.
Whenever information about reserved parts (e.g., DHCPv6-PD Exclude Prefix) is received for a delegated prefix, the reserved parts MUST be advertised using Assigned-Prefix TLVs with the greatest priority (15), as if assigned to a Private Link.
DHCP server and service elections on a Common Link are capability-based: the router with the greatest H-capability wins for stateful DHCPv6, greatest P-capability for DHCPv6-PD, greatest L-capability for DHCPv4, and greatest M-capability for mDNS proxy. Ties are broken by Capability Value, then by greatest node identifier.
HNCP defines six interface categories: Internal (DNCP endpoint, forwards traffic), External (no DNCP endpoint, firewall perimeter), Leaf (Internal but no DNCP endpoint), Guest (Leaf with added isolation from homenet resources), Ad Hoc (Internal without transitivity assumption), and Hybrid (Internal while still running DHCP clients for external config).
The border discovery algorithm evaluates each interface in order: (1) use fixed category if configured, (2) if DHCPv6 PD lease acquired with "HOMENET" user class, classify as external, (3) if DHCPv4 address acquired with "HOMENET" user class, classify as external, (4) otherwise classify as internal.
IANA created an "HNCP TLV Types" registry under DNCP (range 32–511, registration procedure: RFC Required) with initial entries: 32 HNCP-Version through 43 Prefix-Policy, 44–511 Unassigned, 768–1023 Reserved for Private Use. IANA also registered UDP ports 8231 (hncp-udp-port) and 8232 (hncp-dtls-port), and IPv6 multicast address FF02:0:0:0:0:0:0:11 (All-Homenet-Nodes).
Automatic interface classification cannot be secured by encrypting or authenticating HNCP traffic because external routers do not participate in the protocol. Threats include forged uplinks to redirect traffic and forged internal status by external routers to circumvent the perimeter firewall. Mitigation requires securing individual links at the physical or link layer, or preconfiguring adjacent interfaces to a fixed category.
On links where lower layers do not provide adequate protection, DTLS-based secure unicast transport MUST be used. Without it, attackers may perform traffic redirection, eavesdropping, spoofing, or denial-of-service on HNCP services including address assignment, service discovery, and HNCP-derived protocol keys.
The Managed-PSK scheme SHOULD NOT be used unless HNCP unicast transport is secured with DTLS, since transferring the PSK in plaintext is a potential risk especially as the originator may not know about security on all links. The PSK MUST be regenerated whenever a node is removed from the DNCP topology to prevent access by former members.
The Assigned-Prefix TLV (type 35, length >= 6) carries a 32-bit Endpoint Identifier, a 4-bit Reserved field, a 4-bit Priority (0–15), a 1-byte Prefix Length, the prefix padded to the next byte boundary, and optional nested TLVs. Endpoint Identifier value 0 indicates a Private Link.
The Delegated-Prefix TLV (type 34, length >= 9) carries a 32-bit Valid Lifetime Since Origination, a 32-bit Preferred Lifetime Since Origination, a 1-byte Prefix Length, and the prefix padded to the next byte boundary, followed by optional nested TLVs.
The DNS-Delegated-Zone TLV (type 39, length >= 17) carries a 128-bit IP Address of the authoritative DNS server, 5 Reserved bits, and L/B/S flag bits for DNS-SD legacy-browse, browse, and fully-qualified-domain enrollment respectively, followed by a variable-length DNS label sequence Zone field.
The HNCP-Version TLV (type 32, length >= 5) contains a 16-bit Reserved field, and four 4-bit capability fields M (mDNS proxy priority), P (DHCPv6-PD priority), H (stateful DHCPv6 priority), and L (DHCPv4 priority), each 0–7 for active use (values 8–15 reserved), followed by a variable-length UTF-8 User-Agent string.
The Managed-PSK TLV (type 42, fixed length 32) carries a 256-bit random PSK used for bootstrapping third-party protocols that only support symmetric cryptography.
The Node-Address TLV (type 36, fixed length 20) carries a 32-bit Endpoint Identifier and a 128-bit IP Address (IPv6 globally scoped address, or IPv4 address encoded as an IPv4-mapped IPv6 address per RFC 4291).
The Prefix-Policy TLV (type 43, length >= 1) carries a 1-byte Policy Type (0 = Internet connectivity, 1–128 = explicit destination prefix, 129 = DNS domain, 130 = opaque UTF-8, 131 = restrictive assignment, 132–255 reserved) followed by a variable-length value field.