RFC 7788

Home Networking Control Protocol

📅 published April 2016, from ietf

RFC 7788: Home Networking Control Protocol 🎀

okay bestie, let's talk about RFC 7788! 💖 It's the Home Networking Control Protocol (HNCP), and it's a Standards Track document from April 2016. The authors are M. Stenberg and S. Barth (both Independent) and P. Pfister from Cisco Systems. It's published as ISSN 2070-1721. The header doesn't list any RFCs this one obsoletes or updates, so it's standing on its own. 🧚

Abstract

okay so the abstract says HNCP is an extensible configuration protocol 🦋 plus a set of requirements for home network devices. It's described as a profile of and an extension to the Distributed Node Consensus Protocol (DNCP), and it's giving multi-purpose energy: it handles discovery of network borders, automated address configuration, name resolution, service discovery, and using any routing protocol that can route based on both the source and destination address. 💅

Status of This Memo

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741. 🌸

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7788. 🫶

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 📜

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   7
3.  DNCP Profile  . . . . . . . . . . . . . . . . . . . . . . . .   7
4.  HNCP Versioning and Router Capabilities . . . . . . . . . . .   9
5.  Interface Classification  . . . . . . . . . . . . . . . . . .   9
  5.1.  Interface Categories  . . . . . . . . . . . . . . . . . .   9
  5.2.  DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . .  10
  5.3.  Algorithm for Border Discovery  . . . . . . . . . . . . .  11
6.  Autonomous Address Configuration  . . . . . . . . . . . . . .  12
  6.1.  Common Link . . . . . . . . . . . . . . . . . . . . . . .  12
  6.2.  External Connections  . . . . . . . . . . . . . . . . . .  13
  6.3.  Prefix Assignment . . . . . . . . . . . . . . . . . . . .  14
    6.3.1.  Prefix Assignment Algorithm Parameters  . . . . . . .  14
    6.3.2.  Making New Assignments  . . . . . . . . . . . . . . .  16
    6.3.3.  Applying Assignments  . . . . . . . . . . . . . . . .  17
    6.3.4.  DHCPv6 Prefix Delegation  . . . . . . . . . . . . . .  17
  6.4.  Node Address Assignment . . . . . . . . . . . . . . . . .  17
  6.5.  Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . .  18
7.  Configuration of Hosts and Non-HNCP Routers . . . . . . . . .  19
  7.1.  IPv6 Addressing and Configuration . . . . . . . . . . . .  19
  7.2.  DHCPv6 for Prefix Delegation  . . . . . . . . . . . . . .  20
  7.3.  DHCPv4 for Addressing and Configuration . . . . . . . . .  20
  7.4.  Multicast DNS Proxy . . . . . . . . . . . . . . . . . . .  21
8.  Naming and Service Discovery  . . . . . . . . . . . . . . . .  21
9.  Securing Third-Party Protocols  . . . . . . . . . . . . . . .  22
10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . .  23
  10.1.  HNCP-Version TLV . . . . . . . . . . . . . . . . . . . .  23
  10.2.  External-Connection TLV  . . . . . . . . . . . . . . . .  24
    10.2.1.  Delegated-Prefix TLV . . . . . . . . . . . . . . . .  25
    10.2.2.  DHCPv6-Data TLV  . . . . . . . . . . . . . . . . . .  27
    10.2.3.  DHCPv4-Data TLV  . . . . . . . . . . . . . . . . . .  27
  10.3.  Assigned-Prefix TLV  . . . . . . . . . . . . . . . . . .  28
  10.4.  Node-Address TLV . . . . . . . . . . . . . . . . . . . .  29
  10.5.  DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . .  30
  10.6.  Domain-Name TLV  . . . . . . . . . . . . . . . . . . . .  31
  10.7.  Node-Name TLV  . . . . . . . . . . . . . . . . . . . . .  31
  10.8.  Managed-PSK TLV  . . . . . . . . . . . . . . . . . . . .  32
11. General Requirements for HNCP Nodes . . . . . . . . . . . . .  32
12. Security Considerations . . . . . . . . . . . . . . . . . . .  34
  12.1.  Interface Classification . . . . . . . . . . . . . . . .  34
  12.2.  Security of Unicast Traffic  . . . . . . . . . . . . . .  35
  12.3.  Other Protocols in the Home  . . . . . . . . . . . . . .  35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  37
  14.1.  Normative References . . . . . . . . . . . . . . . . . .  37
  14.2.  Informative References . . . . . . . . . . . . . . . . .  39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  40
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1. Introduction ✨

okay so HNCP is designed to help home routers share state with each other 🏠 so they can cover what the IPv6 homenet architecture [RFC7368] needs. That architecture assumes zero-configuration operation, multiple subnets, multiple home routers, and (potentially) multiple upstream service providers handing out (potentially) multiple prefixes to the home network. 🌈

RFC 7368 doesn't set any requirements for IPv4 support, but HNCP aims to support dual-stack operation, so the functionality is designed with that in mind. 💜 The state gets shared as TLVs carried in the DNCP node state among the routers (and potentially advanced hosts) so that they can do the following things: 🧚

  • Autonomic discovery of network borders (Section 5.3) based on Distributed Node Consensus Protocol (DNCP) topology. 🦋
  • Automated portioning of prefixes delegated by the service providers, as well as assigned prefixes for both HNCP and non-HNCP routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP routers get used to:
    • Provide addresses to non-HNCP aware nodes (using Stateless Address Autoconfiguration (SLAAC) and DHCP). 🎀
    • Provide space in which HNCP nodes assign their own addresses (Section 6.4). 🫶
  • Internal and external name resolution, as well as multi-link service discovery (Section 8). 🔥
  • Other services not defined in this document that do need to share state among homenet nodes and do not cause rapid and constant TLV changes (see the following applicability section). 🍓

HNCP is a protocol based on DNCP [RFC7787], and it includes a DNCP profile that defines the transport and synchronization details for sharing state across nodes, which is defined in Section 3. 💅 The rest of the document defines how the services above behave, how the required TLVs are encoded (Section 10), and the additional requirements on how HNCP nodes should behave (Section 11). 👑

1.1. Applicability 🌸

HNCP doesn't deal with routing protocols directly. The exception is that it can potentially tell them about internal and external interfaces, if the classification in Section 5.3 is used. 🙈 In homenet environments where multiple IPv6 source prefixes can show up, routing based on the source and destination address is necessary [RFC7368]. Ideally, the routing protocol is zero configuration too (for example, no need to configure identifiers or metrics), although HNCP can also be used with a manually configured routing protocol. ✨

HNCP uses DNCP as its actual state synchronization protocol, so the applicability statement of DNCP applies here as well. HNCP should not be used for any data that changes rapidly and constantly. ⚠️ If that kind of data needs to be published in an HNCP network, then 1) a more applicable protocol should be used for those portions, and 2) locators to a server of that protocol should be announced using HNCP instead. An example is naming and service discovery (Section 8), where HNCP only transports DNS server addresses and no actual per-name or per-service data of hosts. 💖

HNCP TLVs specified in this document stay constant in steady state, with one exception: Delegated-Prefix TLVs (Section 10.2.1) do contain lifetimes, so they force that data to be republished every time the valid or preferred lifetimes of prefixes get updated (significantly). 😭 It's therefore desirable for ISPs to provide large enough valid and preferred lifetimes to avoid unnecessary HNCP state churn in homes. Even given non-cooperating ISPs, though, the state churn is proportional only to the number of externally received delegated prefixes and not to the home network size, so it should be relatively low. 🌷

HNCP assumes a certain level of control over host configuration servers (for example, DHCP [RFC2131]) on links that are managed by its routers. 🎀 Some HNCP functionality (such as border discovery or some aspects of naming) might be affected by existing DHCP servers that aren't aware of the HNCP-managed network, so they might need to be reconfigured to avoid unexpected behavior. 🙃

HNCP routers can provide configuration to, and receive configuration from, non-HNCP routers. But they can't traverse such devices based solely on the protocol defined in this document. In other words, HNCP routers that are connected only through different interfaces of a non-HNCP router won't be part of the same HNCP network. 🚧

HNCP is designed to be used by (home) routers, but it can also be used by advanced hosts that want to do things like their own address assignment and routing. 🧑‍💻

HNCP is link-layer agnostic. If a link supports IPv6 (link-local) multicast and unicast, HNCP will work on it. 🌈 Trickle retransmissions and keep-alives handle both packet loss and non-transitive connectivity, which ensures eventual convergence. 🦄

2. Terminology ✨

okay bestie, time for the vocab list 📚 this part is important because the rest of the doc leans on it, so let's go 🫶

Some terms are borrowed from [RFC7695] and mean exactly what that doc says 💅

  • Advertised Prefix Priority
  • Advertised Prefix
  • Assigned Prefix
  • Delegated Prefix
  • Prefix Adoption
  • Private Link
  • Published Assigned Prefix
  • Applied Assigned Prefix
  • Shared Link

Then a few more come from [RFC7787], also used exactly as defined there 🌸

  • DNCP profile
  • Node identifier
  • Link
  • Interface

And these are HNCP's own terms, the ones that are actually ours 🦋

  • (HNCP) node: a device implementing this specification.
  • (HNCP) router: a device implementing this specification, which forwards traffic on behalf of other devices.
  • Greatest node identifier: when you compare the DNCP node identifiers of multiple nodes, it's the one with the greatest value in a bitwise comparison. the biggest one wins 👑
  • Border: the separation point between administrative domains. in this case, that's between the home network and any other network, which usually means an ISP network 🏠
  • Internal link: a link that does not cross borders.
  • Internal interface: an interface connected to an internal link.
  • External interface: an interface connected to a link that is not an internal link.
  • Interface category: a local configuration that says how an interface is being used. the category tells an HNCP node how to treat that particular interface 🎀 External and Internal mark the interface as outside or inside the network border, and there are a bunch of Internal subcategories that tweak local node behavior even more. see Section 5.1 for the full list and how each one acts. the Internal or External category can also be auto-detected (Section 5.3) ✨
  • Border router: a router that announces external connectivity and forwards traffic across the network border 🌈
  • Common Link: a set of nodes on a link that all share the same view of it, so they see each other's traffic and the same set of hosts. unless it's configured otherwise, transitive connectivity is assumed 🦋
  • DHCPv4: refers to the Dynamic Host Configuration Protocol [RFC2131] in this document.
  • DHCPv6: refers to the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] in this document.
  • DHCP: refers to cases that apply to both DHCPv4 and DHCPv6 in this document 💜

2.1. Requirements Language

okay this part is the decoder ring for the capital letters 🔥 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [RFC2119] anywhere they show up in this doc 🫶 so when you see them in caps, that's the real deal, not vibes ✨

3. DNCP Profile

the DNCP profile for HNCP is set up like this 💖

  • HNCP uses UDP datagrams on port 8231 as its transport over link-local scoped IPv6, using both unicast and multicast. FF02:0:0:0:0:0:0:11 is the HNCP group address 🧚 datagrams where either or both of the IPv6 source or destination addresses are not link-local scoped MUST be ignored 🙈 replies to multicast and unicast messages MUST be sent to the IPv6 source address and port of the original message. and every node MUST be able to receive (and possibly reassemble) UDP datagrams with a payload of at least 4000 bytes 💅
  • HNCP only works on multicast-capable interfaces 🌸 HNCP nodes MUST assign a non-zero 32-bit endpoint identifier to each interface where HNCP is enabled. the value 0 isn't used in DNCP TLVs but it has a special meaning in HNCP TLVs (see Sections 6.4 and 10.3). these identifiers MUST be locally unique within the scope of the node, and using values equivalent to the IPv6 link-local scope identifiers for the given interfaces is RECOMMENDED 🦋
  • HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 32) ✨ a node implementing HNCP SHOULD use a random node identifier. if there's a node identifier collision (as specified in the Node-State TLV handling of Section 4.4 of [RFC7787]), the node MUST immediately generate and use a new random node identifier that isn't used by any other node at that time, based on the current DNCP network state 🔥
  • HNCP nodes MUST use the leading 64 bits of the MD5 message digest [RFC1321] as the DNCP hash function H(x) used when building the DNCP hash tree 🌈
  • HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on all endpoints. the following parameters are suggested 🎀
    • Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 seconds.
    • Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually lossless links works fine, since it allows for one lost keep-alive. if you're on a lossy link, a way higher multiplier, like 15, should be used instead. in that case, an implementation might prefer shorter keep-alive intervals on that link too, so the timeout (equal to DNCP_KEEPALIVE_INTERVAL * DNCP_KEEPALIVE_MULTIPLIER) after which entirely lost nodes time out stays low enough 😭
  • HNCP nodes use the following Trickle parameters for the per-interface Trickle instances 🍓
    • k SHOULD be 1, since the timer resets when data is updated, and further retransmissions should handle packet loss. even on a non-transitive lossy link, the eventual per-endpoint keep-alives should make sure status synchronization happens 💜
    • Imin SHOULD be 200 milliseconds but MUST NOT be lower. note: the earliest transmissions may occur at Imin / 2 🧚
    • Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be lower 🌸
  • HNCP unicast traffic SHOULD be secured using Datagram Transport Layer Security (DTLS) [RFC6347], as described in DNCP, if it's exchanged over unsecured links. UDP on port 8232 is used for this purpose 🔐 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 DNCP certificate-based trust consensus method. [RFC7525] has guidance on how to use DTLS securely 💖
  • HNCP nodes MUST ignore all Node-State TLVs received via multicast on a link that has DNCP security enabled, so nobody can spoof node state changes 🙅‍♀️💀

4. HNCP Versioning and Router Capabilities

so multiple versions of HNCP based on compatible DNCP profiles can be running on the same network while you're transitioning between versions 🔄 and for troubleshooting, it can be super helpful to figure out which HNCP agent version is running 🕵️‍♀️ so each node MUST include an HNCP-Version TLV (Section 10.1) indicating the version it currently supports in its node data. it MUST ignore (except for DNCP synchronization purposes) any TLVs with a type greater than 32 that are published by nodes that didn't also publish an HNCP-Version TLV 🌈

HNCP routers can also have different capabilities when it comes to interacting with hosts, like for configuration or service discovery ✨ these are shown by the M, P, H, and L values. the combined "capability value" is a metric you get by reading the bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L) 🧮 these values are used to elect certain servers on a Common Link, as described in Section 7 👑 nodes that aren't routers MUST announce the value 0 for all capabilities. and any node announcing the value 0 for a capability is considered to not advertise that capability, so it doesn't take part in the matching election 💅

5. Interface Classification

5.1. Interface Categories

HNCP specifies the following categories that interfaces can be set to 🎀

  • Internal category: declares an interface to be internal, i.e., inside the borders of the HNCP network. the interface MUST operate as a DNCP endpoint. routers MUST forward traffic with appropriate source addresses between their internal interfaces and allow internal traffic to reach external networks. ALL nodes MUST implement this category, and nodes that don't implement any other category implicitly use it as a fixed default 🏡

Wait, that line used ALL in caps, which isn't a key word but still reads like one. Fixing that below. I'm also keeping the BCP 14 words exact, so ignore the stray caps above.

  • Internal category: declares an interface to be internal, i.e., inside the borders of the HNCP network. The interface MUST operate as a DNCP endpoint. Routers MUST forward traffic with appropriate source addresses between their internal interfaces and allow internal traffic to reach external networks. All nodes MUST implement this category, and nodes that don't implement any other category implicitly use it as a fixed default 🏡
  • External category: declares an interface to be external, i.e., not inside the borders of the HNCP network. The interface MUST NOT operate as a DNCP endpoint. Access to internal resources from external interfaces is restricted, i.e., the use of Recommended Simple Security Capabilities in Customer Premises Equipments (CPEs) [RFC6092] is RECOMMENDED 🛡️ HNCP routers SHOULD announce acquired configuration information for use in the network as described in Section 6.2, if the interface appears to be connected to an external network. HNCP routers MUST implement this category 🌸
  • Leaf category: declares an interface used by client devices only. It uses the Internal category, with the exception that it MUST NOT operate as a DNCP endpoint. This category SHOULD be supported by HNCP routers 🍃
  • Guest category: declares an interface used by untrusted client devices only. On top of the Leaf category restrictions, HNCP routers MUST filter traffic from and to the interface so connected devices can't reach other devices inside the HNCP network or query services they advertise, unless that's explicitly allowed 🙈 This category SHOULD be supported by HNCP routers 🫣
  • Ad Hoc category: configures an interface to use the Internal category, but no assumption is made about the link's transitivity. All other interface categories assume transitive connectivity. This affects the Common Link (Section 6.1) definition. Support for this category is OPTIONAL 🧪
  • Hybrid category: declares an interface to use the Internal category while still trying to acquire (external) configuration information on it, e.g., by running DHCP clients. This is useful, e.g., if the link is shared with a non-HNCP router under your control and still within the borders of the same network 🦋 Automatically detecting this category, in addition to manual configuration, is out of scope for this document. Support for this category is OPTIONAL ✨

5.2. DHCP-Aided Auto-Detection

auto-detection of interface categories is possible by talking to DHCPv4 [RFC2131] and DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] servers on connected links 🔍 HNCP defines special DHCP behavior so it can tell its internal servers apart from external ones 🕵️‍♀️ so all internal devices (including HNCP nodes) running DHCP servers on links where any HNCP node uses auto-detection MUST use the following mechanism, based on "The User Class Option for DHCP" [RFC3004] and its DHCPv6 counterpart [RFC3315] 💜

  • The device MUST ignore or reject DHCP-Requests containing a DHCP user class consisting of the ASCII string HOMENET 🏠

not following this rule (e.g., running unmodified DHCP servers) might lead to false positives when auto-detection is used. that means HNCP nodes would assume an interface isn't internal even though it was meant to be 🙃💀

5.3. Algorithm for Border Discovery

okay so this section is the interface classification algorithm, and it's giving main character energy 💅 It works for IPv4, IPv6, or dual stack, and it figures out the category of an interface either automatically or from a fixed config 🎀 Once every interface has a category, the network borders basically draw themselves ✨ Anything that isn't External counts as inside the network, and everything else is outside it 🏠

The following algorithm MUST be implemented by any node implementing HNCP. 🔥 BUT if the node doesn't do auto-detection, only the first and last step are required. The algorithm runs in order and stops at the first match 🫶

  1. If a fixed category is configured for an interface, it is used.
  2. If a delegated prefix could be acquired by running a DHCPv6 client, it is considered external. The DHCPv6 client MUST have included a DHCPv6 user class consisting of the ASCII string "HOMENET" in all of its requests. 💜
  3. If an IPv4 address could be acquired by running a DHCPv4 client on the interface, it is considered external. The DHCPv4 client MUST have included a DHCP user class consisting of the ASCII string "HOMENET" in all of its requests. 🦋
  4. The interface is considered internal. 🌸

Note that as other HNCP nodes will ignore the client due to the User Class option, any server that replies is clearly external (or a malicious internal node). 🙈 bestie, that's the whole trick, the User Class option is the bouncer 🧚

An HNCP router SHOULD allow setting the fixed category for each interface that may be connected to either an internal or external device (e.g., an Ethernet port that can be connected to a modem, another HNCP router, or a client). Note that all fixed categories except internal and external cannot be auto-detected and can only be selected using manual configuration. ✨ so manual config is the only way to get those extra categories, no auto-detect for them 💀

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 (including states where auto-detection considers it to be internal) and rerun the algorithm above to react to conditions resulting in a different interface category. The router SHOULD wait for a reasonable time period (5 seconds as a default), during which the DHCP clients can acquire a lease, before treating a newly activated or previously external interface as internal. 😭 that 5 second grace period is giving patience, literally just letting the leases show up before deciding 🕰️

6. Autonomous Address Configuration ✨

This section specifies how HNCP nodes configure host and node addresses. 💖 At first, border routers share information obtained from service providers or local configuration by publishing one or more External-Connection TLVs (Section 10.2). These contain other TLVs such as Delegated-Prefix TLVs (Section 10.2.1) that are then used for prefix assignment. Finally, HNCP nodes obtain addresses either statelessly or using a specific stateful mechanism (Section 6.4). Hosts and non-HNCP routers are configured using SLAAC, DHCP, or DHCPv6-PD. 🎀 it's a whole pipeline, border routers share the info, prefixes get handed out, then everyone gets addresses 🌈

HNCP uses the concept of Common Link both in autonomic address configuration and naming and service discovery (Section 8). 🍓 A Common Link refers to the set of interfaces of nodes that see each other's traffic and presumably also the traffic of all hosts that may use the nodes to, e.g., forward traffic. Common Links are used, e.g., to determine where prefixes should be assigned or which peers participate in the election of a DHCP server. The Common Link is computed separately for each local internal interface, and it always contains the local interface. Additionally, if the local interface is not set to the Ad Hoc category (see Section 5.1), it also contains the set of interfaces that are bidirectionally reachable from the given local interface; that is, every remote interface of a remote node meeting all of the following requirements: 🦋

  • The local node publishes a Peer TLV with:
    • Peer Node Identifier = remote node's node identifier
    • Peer Endpoint Identifier = remote interface's endpoint identifier
    • Endpoint Identifier = local interface's endpoint identifier
  • The remote node publishes a Peer TLV with:
    • Peer Node Identifier = local node's node identifier
    • Peer Endpoint Identifier = local interface's endpoint identifier
    • Endpoint Identifier = remote interface's endpoint identifier

A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces. 🔍 basically the two-way handshake check, so nothing gets wrongly counted as a link 🫶

6.2. External Connections

Each HNCP router MAY obtain external connection information such as address prefixes, DNS server addresses, and DNS search paths from one or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241], or static configuration. Each individual external connection to be shared in the network is represented by one External-Connection TLV (Section 10.2). 💅

Announcements of individual external connections can consist of the following components:

Delegated Prefixes: Address space available for assignment to internal links announced using Delegated-Prefix TLVs (Section 10.2.1). Some address spaces might have special properties that are necessary to understand in order to handle them (e.g., information similar to [RFC6603]). This information is encoded using DHCPv6-Data TLVs (Section 10.2.2) inside the respective Delegated-Prefix TLVs. 🍰

Auxiliary Information: Information about services such as DNS or time synchronization regularly used by hosts in addition to addressing and routing information. This information is encoded using DHCPv6-Data TLVs (Section 10.2.2) and DHCPv4-Data TLVs (Section 10.2.3). 🧚

Whenever information about reserved parts (e.g., as specified in [RFC6603]) is received for a delegated prefix, the reserved parts MUST be advertised using Assigned-Prefix TLVs (Section 10.3) with the greatest priority (i.e., 15), as if they were assigned to a Private Link. 🔒 the reserved bits go to the VIP section, priority 15, no debate 👑

Some connections or delegated prefixes may have a special meaning and are not regularly used for internal or Internet connectivity; instead, they may provide access to special services like VPNs, sensor networks, Voice over IP (VoIP), IPTV, etc. 📺 Care must be taken that these prefixes are properly integrated and dealt with in the network, in order to avoid breaking connectivity for devices who are not aware of their special characteristics or to only selectively allow certain devices to use them. Such prefixes are distinguished using Prefix-Policy TLVs (Section 10.2.1.1). Their contents MAY be partly opaque to HNCP nodes, and their identification and usage depends on local policy. However, the following general rules MUST be adhered to: 🚧

  • Special rules apply when making address assignments for prefixes with Prefix-Policy TLVs with type 131, as described in Section 6.3.2.
  • In the presence of any type 1 to 128 Prefix-Policy TLV, the prefix is specialized to reach destinations denoted by any such Prefix-Policy TLV, i.e., in absence of a type 0 Prefix-Policy TLV, it is not usable for general Internet connectivity. An HNCP router MAY enforce this restriction with appropriate packet filter rules. 🛡️

6.3. Prefix Assignment

HNCP uses the prefix assignment algorithm [RFC7695] in order to assign prefixes to HNCP internal links and uses some of the terminology (Section 2) defined there. HNCP furthermore defines the Assigned-Prefix TLV (Section 10.3), which MUST be used to announce Published Assigned Prefixes. 🎁 the Assigned-Prefix TLV is the only way to announce those, so no skipping it 💖

6.3.1. Prefix Assignment Algorithm Parameters

All HNCP nodes running the prefix assignment algorithm use the following values for its parameters: 📋

Node IDs: HNCP node identifiers are used. The comparison operation is defined as bitwise comparison. 🔢

Set of Delegated Prefixes: The set of prefixes encoded in Delegated-Prefix TLVs that are not strictly included in prefixes encoded in other Delegated-Prefix TLVs. Note that Delegated-Prefix TLVs included in ignored External-Connection TLVs are not considered. It is dynamically updated as Delegated-Prefix TLVs are added or removed. 🌿

Set of Shared Links: The set of Common Links associated with interfaces with the Internal, Leaf, Guest, or Ad Hoc category. It is dynamically updated as interfaces are added, removed, or switched from one category to another. When multiple interfaces are detected as belonging to the same Common Link, prefix assignment is disabled on all of these interfaces except one. 🔗 only one interface per shared link gets to hand out prefixes, one lucky winner 🏆

Set of Private Links: This document defines Private Links as representing DHCPv6-PD clients or as a mean to advertise prefixes included in the DHCPv6 Exclude Prefix option. Other implementation-specific Private Links may be defined whenever a prefix needs to be assigned for a purpose that does not require a consensus with other HNCP nodes. 🤫

Set of Advertised Prefixes: The set of prefixes included in Assigned-Prefix TLVs advertised by other HNCP nodes (prefixes advertised by the local node are not in this set). The associated Advertised Prefix Priority is the priority specified in the TLV. The associated Shared Link is determined as follows:

  • If the Link Identifier is 0, the Advertised Prefix is not assigned on a Shared Link.
  • If the other node's interface identified by the Link Identifier is included in one of the Common Links used for prefix assignment, it is considered as assigned on the given Common Link.
  • Otherwise, the Advertised Prefix is not assigned on a Shared Link.

Advertised Prefixes as well as their associated priorities and associated Shared Links MUST be updated as Assigned-Prefix TLVs are added, updated, or removed, and as Common Links are modified. 📡 keep those in sync or everything gets messy 🫠

ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix adoption is done instantly). ⚡

BACKOFF_MAX_DELAY: The default value is 4 seconds. ⏳

RANDOM_SET_SIZE: The default value is 64. 🎲

Flooding Delay: The default value is 5 seconds. 🌊

Default Advertised Prefix Priority: When a new assignment is created or an assignment is adopted -- as specified in the prefix assignment algorithm routine -- the default Advertised Prefix Priority to be used is 2. 💜 that's the baseline priority, the starting point for every new assignment 🌸

6.3.2. Making New Assignments 🎀

okay so whenever the prefix assignment algorithm subroutine (Section 4.1 of [RFC7695]) runs on a Common Link 🔗, and a new prefix is allowed to get assigned (case 1 of the subroutine: no Best Assignment and no Current Assignment), the decision on whether a new prefix is desired MUST follow these rules in order 💅:

  1. If the Delegated-Prefix TLV contains a DHCPv6-Data TLV, and the meaning of one of the DHCP options is not understood by the HNCP node, the creation of a new prefix is not desired. This rule applies to TLVs living inside Delegated-Prefix TLVs but not to those inside External-Connection TLVs. 🙈
  2. If the remaining preferred lifetime of the prefix is 0 and there is another delegated prefix of the same IP version used for prefix assignment with a non-zero preferred lifetime, the creation of a new prefix is not desired.
  3. If the Delegated-Prefix TLV does not include a Prefix-Policy TLV indicating restrictive assignment (type 131) or if local policy exists to identify it based on, e.g., other Prefix-Policy TLV values and allows assignment, the creation of a new prefix is desired. ✨
  4. Otherwise, the creation of a new prefix is not desired.

okay now the length stuff 🌸. If the considered delegated prefix is an IPv6 prefix, and whenever there is at least one available prefix of length 64, a prefix of length 64 MUST be selected unless configured otherwise. In case no prefix of length 64 would be available, a longer prefix MAY be selected even without configuration.

If the considered delegated prefix is an IPv4 prefix (Section 6.5 details how IPv4-delegated prefixes are generated), a prefix of length 24 SHOULD be preferred. 🍓

And in any case, an HNCP router making an assignment MUST support a mechanism suitable to distribute addresses from the considered prefix if the link is intended to be used by clients. In this case, a router assigning an IPv4 prefix MUST announce the L-capability, and a router assigning an IPv6 prefix with a length greater than 64 MUST announce the H-capability as defined in Section 4. It's giving responsibility 👑.

6.3.3. Applying Assignments 🦋

The prefix assignment algorithm indicates when a prefix gets applied to the respective Common Link. When that happens, each router connected to said link:

  • MUST forward traffic destined to said prefix to the respective link.
  • MUST participate in the client configuration election as described in Section 7, if the link is intended to be used by clients.
  • MAY add an address from said prefix to the respective network interface as described in Section 6.4, e.g., if it is to be used as source for locally originating traffic. 🧚

6.3.4. DHCPv6 Prefix Delegation 💜

When an HNCP router announcing the P-Capability (Section 4) receives a DHCPv6-PD request from a client, it SHOULD assign one prefix per delegated prefix in the network. This set of assigned prefixes is then delegated to the client, after it has been applied as described in the prefix assignment algorithm. Each DHCPv6-PD client MUST be considered as an independent Private Link, and delegation MUST be based on the same set of delegated prefixes as the one used for Common Link prefix assignments; however, the prefix length to be delegated MAY be smaller than 64. bestie that's a lot of rules but they're all giving structure 🫶

The assigned prefixes MUST NOT be given to DHCPv6-PD clients before they are applied and MUST be withdrawn whenever they are destroyed. As an exception to this rule, in order to shorten delays of processed requests, a router MAY prematurely give out a prefix that is advertised but not yet applied if it does so with a valid lifetime of not more than 30 seconds and ensures removal or correction of lifetimes as soon as possible. ⭐

6.4. Node Address Assignment 🌈

This section specifies how HNCP nodes reserve addresses for their own use. Nodes MAY, at any time, try to reserve a new address from any Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 address and -- if it supports IPv4 -- MUST announce an IPv4 address, whenever matching prefixes are assigned to at least one of its Common Links. These addresses are published using Node-Address TLVs and used to locally reach HNCP nodes for other services. Nodes SHOULD NOT create and announce more than one assignment per IP version to avoid cluttering the node data with redundant information unless a special use case requires it. 🧹

Stateless assignment based on Semantically Opaque Interface Identifiers [RFC7217] SHOULD be used for address assignment whenever possible (e.g., the prefix length is 64). Otherwise (e.g., for IPv4 if supported), the following method MUST be used instead: For any assigned prefix for which stateless assignment is not used, the first quarter of the addresses are reserved for HNCP-based address assignments, whereas the last three quarters are left to the DHCP elected router (Section 4 specifies the DHCP server election process). For example, if the prefix 192.0.2.0/24 is assigned and applied to a Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP nodes, and the remaining addresses are reserved for the elected DHCPv4 server. 🍰

HNCP nodes assign addresses to themselves and then (to ensure eventual lack of conflicting assignments) publish the assignments using the Node-Address TLV (Section 10.4). 📣

The process of obtaining addresses is specified as follows:

  • A node MUST NOT start advertising an address if it is already advertised by another node.
  • An assigned address MUST be part of an assigned prefix currently applied on a Common Link that includes the interface specified by the endpoint identifier.
  • An address MUST NOT be used unless it has been advertised for at least ADDRESS_APPLY_DELAY consecutive seconds and is still currently being advertised. The default value for ADDRESS_APPLY_DELAY is 3 seconds. ⏳
  • Whenever the same address is advertised by more than one node, all but the one advertised by the node with the greatest node identifier MUST be removed. 👑

6.5. Local IPv4 and ULA Prefixes 🦋

HNCP routers can create a Unique Local Address (ULA) or private IPv4 prefix to enable connectivity between local devices. These prefixes are inserted in HNCP as if they were delegated prefixes of a (virtual) external connection (Section 6.2). The following rules apply:

  • An HNCP router SHOULD create a ULA prefix if there is no other IPv6 prefix with a preferred time greater than 0 in the network. It MAY also do so if there are other delegated IPv6 prefixes, but none of which is locally generated (i.e., without any Prefix-Policy TLV) and has a preferred time greater than 0. However, it MUST NOT do so otherwise. In case multiple locally generated ULA prefixes are present, only the one published by the node with the greatest node identifier is kept among those with a preferred time greater than 0 -- if there is any. 💖
  • An HNCP router MUST create a private IPv4 prefix [RFC1918] whenever it wishes to provide IPv4 Internet connectivity to the network and no other private IPv4 prefix with Internet connectivity currently exists. It MAY also enable local IPv4 connectivity by creating a private IPv4 prefix if no IPv4 prefix exists, but MUST NOT do so otherwise. In case multiple IPv4 prefixes are announced, only the one published by the node with the greatest node identifier is kept among those with a Prefix-Policy TLV of type 0 -- if there is any. The router publishing a prefix with Internet connectivity MUST forward IPv4 traffic to the Internet and perform NAT on behalf of the network as long as it publishes the prefix; other routers in the network MAY choose not to. 🌐

Creation of such ULA and IPv4 prefixes MUST be delayed by a random time span between 0 and 10 seconds, and in that window the router MUST scan for others trying to do the same. 🎲

When a new ULA prefix is created, the prefix is selected based on the configuration, using the last non-deprecated ULA prefix, or generated based on [RFC4193]. ✨

7. Configuration of Hosts and Non-HNCP Routers 🎀

HNCP routers need to ensure that hosts and non-HNCP downstream routers on internal links are configured with addresses and routes. Since DHCP clients can usually only bind to one server at a time, a per-link and per-service election takes place. 🗳️

HNCP routers may have different capabilities for configuring downstream devices and providing naming services. Each router MUST therefore indicate its capabilities as specified in Section 4 in order to participate as a candidate in the election. 🫶

7.1. IPv6 Addressing and Configuration 🌸

In general, Stateless Address Autoconfiguration [RFC4861] is used for client configuration for its low overhead and fast renumbering capabilities. Therefore, each HNCP router sends Router Advertisements on interfaces that are 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 such advertisement. However, stateful DHCPv6 can be used in addition by administrative choice to, e.g., collect hostnames and use them to provide naming services or whenever stateless configuration is not applicable. 📨

The designated stateful DHCPv6 server for a Common Link (Section 6.1) is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest H-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values. 🏆

The elected router MUST serve stateful DHCPv6 and SHOULD provide naming services for acquired hostnames as outlined in Section 8; all other nodes MUST NOT. Stateful addresses SHOULD be assigned in a way that does not hinder fast renumbering, even if the DHCPv6 server or client do not support the DHCPv6 reconfigure mechanism, e.g., by only handing out leases from locally generated (ULA) prefixes and prefixes with a length different from 64, and by using low renew and rebind times (i.e., not longer than 5 minutes). In case no router was elected, stateful DHCPv6 is not provided. Routers that cease to be elected DHCP servers SHOULD -- when applicable -- invalidate remaining existing bindings in order to trigger client reconfiguration. 🔄

7.2. DHCPv6 for Prefix Delegation 🌈

The designated DHCPv6 server for prefix delegation on a Common Link is elected based on the capabilities described in Section 4. The winner is the router (connected to the Common Link) advertising the greatest P-capability. In case of a tie, Capability Values (Section 4) are compared, and the router with the greatest value is elected. In case of another tie, the router with the greatest node identifier is elected among the routers with tied Capability Values. 👑

The elected router MUST provide prefix delegation services [RFC3633] on the given link (and follow the rules in Section 6.3.4); all other nodes MUST NOT. 💅

7.3. DHCPv4 for Addressing and Configuration 🎀

okay so bestie, the designated DHCPv4 server on a Common Link (Section 6.1) gets picked using the capabilities from Section 4. 💅 The winner is the router (connected to the Common Link) advertising the greatest L-capability. 👑 If there's a tie, the Capability Values (Section 4) get compared and the router with the greatest value wins. ✨ If it's still tied, the router with the greatest node identifier is elected among the tied routers. 🫶 Iconic tiebreaker chain, no cap.

The elected router MUST provide DHCPv4 services on the given link, and all other nodes MUST NOT. 😭 The elected router MUST provide IP addresses from the pool defined in Section 6.4 and MUST announce itself as router [RFC2132] to clients. 🌸 Main character energy for sure.

DHCPv4 lifetimes, meaning renew and rebind times (T1 and T2), SHOULD be short (i.e., not longer than 5 minutes) so responses to changes are reasonably quick. ⭐ Routers that cease to be elected DHCP servers SHOULD, when applicable, invalidate remaining existing bindings so clients get triggered to reconfigure. 🦋

7.4. Multicast DNS Proxy 🧚

The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link is elected based on the capabilities described in Section 4. 💖 The winner is the router (connected to the Common Link) advertising the greatest M-capability. ✨ Tie? Capability Values (Section 4) get compared, and the greatest value wins. 🙈 Still tied? The router with the greatest node identifier is elected among the routers with tied Capability Values. Same energy as before, bestie. 💅

The elected router MUST provide an mDNS proxy on the given link and announce it as described in Section 8. 🔥

8. Naming and Service Discovery 🌈

Network-wide naming and service discovery can greatly level up the user friendliness of a network. 💜 The mechanism below gives you the tools to set up and delegate naming and service discovery across multiple HNCP routers. 🍓

Each HNCP router SHOULD provide and advertise a recursive name resolving server to clients that honor the announcements made in Delegated-Zone TLVs (Section 10.5), Domain-Name TLVs (Section 10.6), and Node-Name TLVs (Section 10.7). 🫶 In other words, it delegates queries to the designated name servers and hands out appropriate A, AAAA, and PTR records according to the mentioned TLVs. 💅

Each HNCP router SHOULD provide and announce an auto-generated or user-configured name for each internal Common Link (Section 6.1) for which it is the designated DHCPv4 server, stateful DHCPv6 server, or mDNS proxy, or for which it provides forward or reverse DNS services on behalf of connected devices. 🦋 This announcement is made using Delegated-Zone TLVs (Section 10.5) and MUST be unique in the whole network. ⭐ If there's a conflict, the announcement of the node with the greatest node identifier takes precedence, and all other nodes MUST cease to announce the conflicting TLV. 💀 HNCP routers providing recursive name resolving services MUST use the included DNS server address within the TLV to resolve names belonging to the zone as if there was an NS record. 👑

Each HNCP node SHOULD announce a node name for itself so it's easily reachable, and MAY announce names on behalf of other devices. 🎀 Announcements are made using Node-Name TLVs (Section 10.7), and the announced names MUST be unique in the whole network. ✨ In case of a conflict, the announcement of the node with the greatest node identifier takes precedence, and all other nodes MUST cease to announce the conflicting TLV. 🙈 HNCP routers providing recursive name resolving services as described above MUST resolve such announced names to their respective IP addresses as if there were corresponding A/AAAA records. 🧚

Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. 💖 A network-wide zone gets appended to all single labels or unqualified zones to qualify them. ".home" is the default 🏠, but an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. 🌸 If multiple are announced, the domain of the node with the greatest node identifier takes precedence. 👑

9. Securing Third-Party Protocols 🔐

PSKs are often required to secure (for example) IGPs and other protocols that lack support for asymmetric security. 🥺 This mechanism manages PSKs using HNCP to enable bootstrapping of such third-party protocols. 💜 The scheme SHOULD NOT be used unless it's in conjunction with secured HNCP unicast transport (i.e., DTLS), because transferring the PSK in plaintext anywhere in the network is a potential risk. 😭 That's especially true since the originator may not know about security (and use of DNCP security) on all links. 💀 The following rules define how such a PSK is managed and used:

  • If no Managed-PSK TLV (Section 10.8) is currently being announced, an HNCP node using this mechanism MUST create one after a random delay of 0 to 10 seconds, with a 32 bytes long random key, and add it to its node data. ✨
  • In case multiple nodes announce such a TLV at the same time, all but the one with the greatest node identifier stop advertising it and adopt the remaining one. 🫶
  • The node currently advertising the Managed-PSK TLV MUST generate and advertise a new random one whenever an unreachable node is removed from the DNCP topology as described in Section 4.6 of [RFC7787]. 🔄

PSKs for individual protocols SHOULD be derived from the random PSK using a suitable one-way hashing algorithm. 🧁 For example, you can use the HMAC-based Key Derivation Function (HKDF) based on HMAC-SHA256 [RFC6234] with the particular protocol name in the info field. 🔑 That way, disclosure of any derived key does not impact other users of the managed PSK. 🛡️ Furthermore, derived PSKs MUST be updated whenever the managed PSK changes. 💅

10. Type-Length-Value Objects 📦

HNCP defines the following TLVs in addition to those defined by DNCP. 🧃 The same general rules and defaults for encoding as noted in Section 7 of [RFC7787] apply. 📝 Most HNCP variable-length TLVs also support optional nested TLVs, which are encoded after the variable-length content, followed by the zero padding of the variable-length content to the next 32-bit boundary. 🎀

TLVs defined here are only valid when they appear in their designated context, meaning only directly within the container TLVs mentioned in their definition or, absent any mentions, only as top-level TLVs within the node data set. 🙅‍♀️ TLVs appearing outside their designated context MUST be ignored. 🚫

TLVs encoding IP addresses or prefixes allow encoding both IPv6 and IPv4 addresses and prefixes. 🌍 IPv6 information is encoded as is. For IPv4, the IPv4-mapped IPv6 addresses format [RFC4291] is used, and prefix lengths are encoded as the original IPv4 prefix length increased by 96. 🧮

10.1. HNCP-Version TLV 🏷️

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: HNCP-Version (32)    |         Length: >= 5          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |   M   |   P   |   H   |   L   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User-agent                           |

This TLV is used to indicate the supported version and router capabilities of an HNCP node, as described in Section 4. 💖

Reserved: Bits are reserved for future use. They MUST be set to 0 when creating this TLV, and their value MUST be ignored when processing the TLV. 🔒

M-capability: Priority value used for electing the on-link mDNS [RFC6762] proxy. It MUST be set to 0 if the router is not capable of proxying mDNS. Otherwise it SHOULD be set to 4, but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use. 🌈

P-capability: Priority value used for electing the on-link DHCPv6-PD server. It MUST be set to 0 if the router is not capable of providing prefixes through DHCPv6-PD (Section 6.3.4). Otherwise it SHOULD be set to 4, but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use. 🧚

H-capability: Priority value used for electing the on-link DHCPv6 server offering non-temporary addresses. It MUST be set to 0 if the router is not capable of providing such addresses. Otherwise it SHOULD be set to 4, but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use. 🦋

L-capability: Priority value used for electing the on-link DHCPv4 server. It MUST be set to 0 if the router is not capable of running a legacy DHCPv4 server offering IPv4 addresses to clients. Otherwise it SHOULD be set to 4, but MAY be set to any value from 1 to 7 to indicate a non-default priority. The values 8-15 are reserved for future use. 🍓

User-Agent: The user-agent is a human-readable UTF-8 string that describes the name and version of the current HNCP implementation. 🤖

10.2. External-Connection TLV 🌐

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: External-Connection (33)|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

An External-Connection TLV is a container TLV used to gather network configuration information associated with a single external connection (Section 6.2) so it can be shared across the HNCP network. ✨ A node MAY publish an arbitrary number of instances of this TLV to share the desired number of external connections. 💅 Upon reception, the information transmitted in any nested TLVs is used for the purposes of prefix assignment (Section 6.3) and host configuration (Section 7). 🫶

10.2.1. Delegated-Prefix TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: Delegated-Prefix (34)  |          Length: >= 9         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Valid Lifetime Since Origination               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Preferred Lifetime Since Origination             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+            Prefix                             +
   ...
   |                                               | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

Okay bestie, this one is the Delegated-Prefix TLV 🎀 HNCP routers use it to advertise prefixes that belong to the whole network and can be handed out for prefix assignment ✨ It's giving "the whole household's prefix pool" energy. Delegated-Prefix TLVs are only valid inside External-Connection TLVs 💅, and their prefixes MUST NOT overlap with the prefixes of any other such TLVs in the same container 🙈 No double-booking, periodt!

  • Valid Lifetime Since Origination: how many seconds the delegated prefix was valid for at the origination time of the node data that holds this TLV 🦋 The value MUST be updated every time the node republishes its Node-State TLV 🔥
  • Preferred Lifetime Since Origination: same vibe, but for how many seconds the prefix was preferred 🌸 This value MUST be updated every time the node republishes its Node-State TLV too 💜
  • Prefix Length: the number of significant bits in the prefix 🧚
  • Prefix: the significant bits of the prefix, padded with zeros up to the next byte boundary 🍓

10.2.1.1. Prefix-Policy TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Prefix-Policy (43)   |          Length: >= 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Policy Type  |                                               |
   +-+-+-+-+-+-+-+-+                    Value                      +
   |                                                               |

The Prefix-Policy TLV is the vibe-check for a delegated prefix ✨ It holds info about the policy or applicability of that prefix 🫶 You can use it to figure out whether prefixes for a certain use case (like local reachability or Internet connectivity) already exist or still need to be acquired 🌈 It also helps you decide which links get which prefixes, or fine-tune border firewalls 🔥 Check Section 6.2 for the deeper tea. This TLV is only valid inside a Delegated-Prefix TLV 💅

  • Policy Type: the type of the policy identifier 💖
    • 0: Internet connectivity (no value) 🌍
    • 1-128: explicit destination prefix. The Policy Type is the actual length of the prefix, and the value holds the significant bits of the destination prefix, padded with zeros up to the next byte boundary 🦋
    • 129: DNS domain. The value contains a DNS label sequence encoded per [RFC1035]. Compression MUST NOT be used 🙅‍♀️ The label sequence MUST end with an empty label 🫶
    • 130: opaque UTF-8 string (for administrative purposes, like a little sticky note) 🎀
    • 131: restrictive assignment (no value) 🔒
    • 132-255: reserved for future additions 🔮
  • Value: a variable-length identifier of the given type 🍓

10.2.2. DHCPv6-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPv6-Data (37)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      DHCPv6 option stream                     |

The DHCPv6-Data TLV carries auxiliary IPv6 configuration info, like recursive DNS servers 🌸 It's encoded as a stream of DHCPv6 options 💜 It's only valid in an External-Connection TLV, or in a Delegated-Prefix TLV that encodes an IPv6 prefix 🦋 It MUST NOT occur more than once in any single container 🙅‍♀️ When it sits inside an External-Connection TLV, it holds DHCPv6 options relevant to the external connection as a whole 🌐 When it sits inside a delegated prefix, it holds options that are mandatory for handling that prefix 🔥

  • DHCPv6 option stream: DHCPv6 options encoded as specified in [RFC3315] 🧚

10.2.3. DHCPv4-Data TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPv4-Data (38)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DHCPv4 option stream                    |

The DHCPv4-Data TLV is the IPv4 twin of the one above 🍓 It carries auxiliary IPv4 configuration info (again, things like recursive DNS servers) as a stream of DHCPv4 options 🎀 It's only valid in an External-Connection TLV, and it MUST NOT occur more than once in any single container 🙈 It holds DHCPv4 options relevant to the external connection as a whole 🌈

  • DHCPv4 option stream: DHCPv4 options encoded as specified in [RFC2131] 💖

10.3. Assigned-Prefix TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: Assigned-Prefix (35)   |          Length: >= 6         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Rsv. | Prty. | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Prefix             +
   ...
   |                                               | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

The Assigned-Prefix TLV announces Published Assigned Prefixes for the purposes of prefix assignment, which you can read more about in Section 6.3 ✨ It's the "here's what we've handed out" announcement 📣

  • Endpoint Identifier: the endpoint identifier of the local interface the prefix is assigned to, or 0 if it's assigned to a Private Link (for example, when the prefix is assigned for downstream prefix delegation) 🦋
  • Rsv.: reserved bits for future use 🔒 They MUST be set to 0 when creating this TLV, and their value MUST be ignored when processing the TLV 🫶
  • Prty.: the Advertised Prefix Priority, from 0 to 15 👑
    • 0-1: low priorities 🌱
    • 2: default priority 💅
    • 3-7: high priorities 🔥
    • 8-11: administrative priorities. MUST NOT be used unless configured otherwise 🙅‍♀️
    • 12-14: reserved for future use 🔮
    • 15: provider priorities. MAY only be used by the router advertising the corresponding delegated prefix, and based on static or dynamic configuration (for example, for excluding a prefix based on the DHCPv6-PD Prefix Exclude Option [RFC6603]) 👑✨
  • Prefix Length: the number of significant bits in the Prefix field 🧚
  • Prefix: the significant bits of the prefix, padded with zeros up to the next byte boundary 🍓

10.4. Node-Address TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Node-Address (36)    |           Length: 20          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

The Node-Address TLV is how a node announces the addresses assigned to it, as described in Section 6.4 🌟 Think of it as the node's business card 💼✨

  • Endpoint Identifier: the endpoint identifier of the local interface the prefix is assigned to, or 0 if it's not assigned on an HNCP-enabled link 🦋
  • IP Address: the globally scoped IPv6 address, or the IPv4 address encoded as an IPv4-mapped IPv6 address [RFC4291] 🌈

10.5. DNS-Delegated-Zone TLV 🌸

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: DNS-Delegated-Zone (39) |        Length: >= 17          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Reserved |L|B|S|                                               |
   +-+-+-+-+-+-+-+-+  Zone  (DNS label sequence - variable length) |
   ...
   |                                               | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

okay so this TLV is how you announce a forward or reverse DNS zone delegation in the HNCP network 🦋 ngl it's basically giving NS and A/AAAA record vibes. The nitty gritty details live in Section 8, bestie 💅

  • IP Address: the IPv6 address of the authoritative DNS server for the zone 🫶. IPv4 addresses are represented as IPv4-mapped addresses [RFC4291]. The special value of :: (all zeros) means the delegation is available in the global DNS hierarchy 🌍.
  • Reserved: those bits MUST be set to 0 when creating the TLV and ignored when parsing it unless defined in a later specification 🔒.
  • L-bit: (DNS-based Service Discovery (DNS-SD) [RFC6763] Legacy-Browse) indicates that this delegated zone SHOULD be included in the network's DNS-SD legacy browse list of domains at lb._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have this bit set; reverse zones SHOULD NOT 🎀.
  • B-bit: (DNS-SD [RFC6763] Browse) indicates that this delegated zone SHOULD be included in the network's DNS-SD browse list of domains at b._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have this bit set; reverse zones SHOULD NOT ✨.
  • S-bit: (Fully qualified DNS-SD [RFC6763] domain) indicates that this delegated zone consists of a fully qualified DNS-SD domain, which should be used as the base for DNS-SD domain enumeration, i.e., _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set; reverse zones MUST NOT. This can be used to provision a DNS search path to hosts for non-local services (such as those provided by an ISP or other manually configured service providers). Zones with this flag SHOULD be added to the search domains advertised to clients 🧚.
  • Zone: the label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label 🍓.

10.6. Domain-Name TLV 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Domain-Name (40)     |         Length: > 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Domain (DNS label sequence - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

this one is used to indicate the base domain name for the network, as specified in Section 8 🌈. Real talk: this TLV MUST NOT be announced unless the domain name was explicitly configured by an administrator 🙈. No freelancing allowed!

  • Domain: the label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The label sequence MUST end with an empty label 💜.

10.7. Node-Name TLV 💅

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: Node-Name (41)      |         Length: > 17          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Length    |       Name                                    |
    ...
   | (not null-terminated, variable length)        | 0-pad if any  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

this TLV is used to assign the name of a node in the network to a certain IP address, as specified in Section 8 🫶✨.

  • IP Address: the IP address associated with the name. IPv4 addresses are encoded using IPv4-mapped IPv6 addresses 🦋.
  • Length: the length of the name (0-63) 🔢.
  • Name: the name of the node as a single DNS label 🎀.

10.8. Managed-PSK TLV 🔐

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Managed-PSK (42)     |          Length: 32           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                                                               |
   |                      Random 256-bit PSK                       |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (Optional nested TLVs)                    |

this TLV is used to announce a PSK for securing third-party protocols exclusively supporting symmetric cryptography, as specified in Section 9 🗝️💖.

11. General Requirements for HNCP Nodes 👑

Each node implementing HNCP is subject to the following requirements 🌸:

  • It MUST implement HNCP versioning (Section 4) and interface classification (Section 5).
  • It MUST implement and run the method for securing third-party protocols (Section 9) whenever it uses the security mechanism of HNCP.

If the node is acting as a router, then the following requirements apply in addition 🧭:

  • It MUST support Autonomous Address Configuration (Section 6) and configuration of hosts and non-HNCP routers (Section 7).
  • It SHOULD implement support for naming and service discovery (Section 8) as defined in this document.
  • It MAY be able to provide connectivity to IPv4 devices using DHCPv4.
  • It SHOULD be able to delegate prefixes to legacy IPv6 routers using DHCPv6-PD (Section 6.3.4).
  • In addition, the normative language of "Basic Requirements for IPv6 Customer Edge Routers" [RFC7084] applies with the following adjustments 💅:
    • The generic requirements G-4 and G-5 are relaxed such that any known default router on any interface is sufficient for a router to announce itself as the default router; similarly, only the loss of all such default routers results in self-invalidation 🙌.
    • "WAN-Side Configuration" (Section 4.2) applies to interfaces classified as external.
    • If the Customer Edge (CE) sends a size hint as indicated in WPD-2, the hint MUST NOT be determined by the number of LAN interfaces of the CE but SHOULD instead be large enough to at least accommodate prefix assignments announced for existing delegated or ULA prefixes, if such prefixes exist and unless explicitly configured otherwise 📏.
    • The dropping of packets with a destination address belonging to a delegated prefix mandated in WPD-5 MUST NOT be applied to destinations that are part of any prefix announced using an Assigned-Prefix TLV by any HNCP router in the network 🚫.
    • "LAN-Side Configuration" (Section 4.3) applies to interfaces not classified as external.
    • The requirement L-2 to assign a separate /64 to each LAN interface is replaced by the participation in the prefix assignment mechanism (Section 6.3) for each such interface 🍭.
    • The requirement L-9 is modified, in that the M flag MUST be set if and only if a router connected to the respective Common Link is advertising a non-zero H-capability. The O flag SHOULD always be set 🚩.
    • The requirement L-12 to make DHCPv6 options available is adapted, in that Canonical Encoding Rules (CER) SHOULD publish the subset of options using the DHCPv6-Data TLV in an External-Connection TLV. Similarly, it SHOULD do the same for DHCPv4 options in a DHCPv4-Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX [RFC3633] MUST be published using a DHCPv6-Data TLV inside the respective Delegated-Prefix TLV. HNCP routers SHOULD make relevant DHCPv6 and DHCPv4 options available to clients, i.e., options contained in External-Connection TLVs that also include delegated prefixes from which a subset is assigned to the respective link 🎁.
    • The requirement L-13 to deprecate prefixes is applied to all delegated prefixes in the network from which assignments have been made on the respective interface. Furthermore, the Prefix Information Options indicating deprecation MUST be included in Router Advertisements for the remainder of the prefixes' respective valid lifetime but MAY be omitted after at least 2 hours have passed ⏳.

12. Security Considerations 🚨

HNCP enables self-configuring networks, requiring as little user intervention as possible. However, this zero-configuration goal usually conflicts with security goals and introduces a number of threats 😭💀. Main character drama, but it's real.

General security issues for existing home networks are discussed in [RFC7368]. The protocols used to set up addresses and routes in such networks to this day rarely have security enabled within the configuration protocol itself. However, these issues are out of scope for the security of HNCP itself 🏠.

HNCP is a DNCP-based state synchronization mechanism carrying information with varying threat potential. For this consideration, the payloads defined in DNCP and this document are reviewed 🔍:

  • Network topology information such as HNCP nodes and their common links.
  • Address assignment information such as delegated and assigned prefixes for individual links.
  • Naming and service discovery information such as auto-generated or customized names for individual links and nodes.

12.1. Interface Classification

okay bestie, so like in Section 5.3, every HNCP node works out whether each interface is internal or external, one interface at a time 🏠✨ External interfaces get a firewall perimeter 🧱, and internal ones let HNCP traffic through, except the Leaf and Guest subcategories 🙅‍♀️ (those two get the velvet rope).

Threats from automatic interface classification can't be fixed by encrypting or authenticating the HNCP traffic itself 😭 because external routers don't take part in the protocol and often can't be authenticated any other way. These threats include forged uplinks showing up in the homenet to, e.g., redirect traffic headed to external locations, and external routers faking internal status to, e.g., get past the perimeter firewall 💀

so it's literally imperative 🫶 to either secure the individual links at the physical or link layer, or preconfigure the adjacent interfaces of HNCP routers to an appropriate fixed category. That's how you lock down the homenet border 🔒 Depending on how secure the external link is, eavesdropping, man-in-the-middle, and similar attacks on external traffic can still happen between a homenet border router and the ISP 😬 but none of that can be stopped from inside the homenet 🚫 For example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 messages, but it's very rarely implemented in large or small networks. Also, PPP can give secure authentication of both sides of a point-to-point link, but it's most often deployed with one-way authentication of the subscriber to the ISP, not the ISP to the subscriber 🙈

12.2. Security of Unicast Traffic

once the homenet border is set up, there are a bunch of ways to secure HNCP against internal threats like manipulation or eavesdropping by compromised devices on a link that has HNCP traffic enabled 🕵️‍♀️ If you leave it unsecured, attackers can do arbitrary traffic redirection, eavesdropping, spoofing, or denial-of-service attacks on HNCP services like address assignment or service discovery, and the protocols are secured using HNCP-derived keys such as routing protocols 🔑

detailed interface categories like "Leaf" or "Guest" are giving protection 💅 They let you bring not fully trusted devices into the homenet to various degrees, either by not exposing them to HNCP traffic at all, or by using firewall rules that stop them from reaching homenet-internal resources 🧱✨

on links where that's not practical, and lower layers don't give adequate protection from attackers, DTLS-based secure unicast transport MUST be used to secure traffic 🔐 no skipping this one, bestie 😤

12.3. Other Protocols in the Home

IGPs and other protocols usually run alongside HNCP 🏡 so the individual security aspects of each protocol must be considered. It can be summed up, though, that many protocols run in the home (like IGPs) give -- to a certain extent -- similar security mechanisms 🤝 Most of these protocols don't support encryption, and they only natively support authentication based on Pre-Shared Keys. This affects how well any encryption-based security mechanism deployed by HNCP can work, since homenet routing information usually isn't encrypted 🥺

13. IANA Considerations 🦋

okay, IANA set up a registry for the decimal values in the range 32-511 called "HNCP TLV Types", under "Distributed Node Consensus Protocol (DNCP)" 📋 The registration procedure is 'RFC Required' [RFC5226] ✨ Here's what's in the starting lineup:

   32: HNCP-Version

   33: External-Connection

   34: Delegated-Prefix

   35: Assigned-Prefix

   36: Node-Address

   37: DHCPv4-Data

   38: DHCPv6-Data

   39: DNS-Delegated-Zone

   40: Domain-Name

   41: Node-Name

   42: Managed-PSK

   43: Prefix-Policy

   44-511: Unassigned.

   768-1023: Reserved for Private Use.  This range is used by HNCP
   for per-implementation experimentation.  How collisions are
   avoided is outside the scope of this document.

IANA also registered the UDP port numbers 8231 (service name: hncp-udp-port, description: HNCP) and 8232 (service name: hncp-dtls-port, description: HNCP over DTLS) 🔌 plus the IPv6 link-local multicast address FF02:0:0:0:0:0:0:11 (description: All-Homenet-Nodes) 📣

14. References 📚

14.1. Normative References

these are the must-read ones, no cap 🤓

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <http://www.rfc-editor.org/info/rfc1321>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <http://www.rfc-editor.org/info/rfc2131>.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <http://www.rfc-editor.org/info/rfc2132>.

   [RFC3004]  Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
              A., Beser, B., and J. Privat, "The User Class Option for
              DHCP", RFC 3004, DOI 10.17487/RFC3004, November 2000,
              <http://www.rfc-editor.org/info/rfc3004>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6092]  Woodyatt, J., Ed., "Recommended Simple Security
              Capabilities in Customer Premises Equipment (CPE) for
              Providing Residential IPv6 Internet Service", RFC 6092,
              DOI 10.17487/RFC6092, January 2011,
              <http://www.rfc-editor.org/info/rfc6092>.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
              March 2011, <http://www.rfc-editor.org/info/rfc6206>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC6603]  Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
              Troan, "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012,
              <http://www.rfc-editor.org/info/rfc6603>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <http://www.rfc-editor.org/info/rfc6763>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.

   [RFC7695]  Pfister, P., Paterson, B., and J. Arkko, "Distributed
              Prefix Assignment Algorithm", RFC 7695,
              DOI 10.17487/RFC7695, November 2015,
              <http://www.rfc-editor.org/info/rfc7695>.

   [RFC7787]  Stenberg, M. and S. Barth, "Distributed Node Consensus
              Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016,
              <http://www.rfc-editor.org/info/rfc7787>.

14.2. Informative References

these ones are good to know, but you don't need them to build the thing 🌸

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC3118]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
              DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
              <http://www.rfc-editor.org/info/rfc3118>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <http://www.rfc-editor.org/info/rfc6234>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <http://www.rfc-editor.org/info/rfc6762>.

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              DOI 10.17487/RFC7084, November 2013,
              <http://www.rfc-editor.org/info/rfc7084>.

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <http://www.rfc-editor.org/info/rfc7368>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

Acknowledgments 💖

huge thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek, and Thomas Clausen for their contributions to the document 🫶

thanks also to Eric Kline for the original border discovery work 🧚

Authors' Addresses 💜

   Markus Stenberg
   Independent
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi


   Steven Barth
   Independent
   Halle  06114
   Germany

   Email: cyrus@openwrt.org


   Pierre Pfister
   Cisco Systems
   Paris
   France

   Email: pierre.pfister@darou.fr
📦 where this page comes from