Discovering Provisioning Domain Names and Data
Extracted elements (34)
PvD Additional Information is carried as a JSON object retrieved over HTTPS rather than embedded in the RA because the data is typically too large or not critical enough for inclusion in an RA option, yet may be valuable to applications or users when selecting among PvDs. IoT devices that prefer CBOR representation are acknowledged but out of scope for this document.
PvD IDs are FQDNs rather than arbitrary strings because domain name ownership provides a lightweight authorization mechanism: TLS certificate validation against the PvD ID FQDN confirms that the FQDN owner authorizes use of that PvD ID with the advertised prefix, without requiring any modifications to the Neighbor Discovery security model.
The R-flag and inner RA message header mechanism allows operators to send two distinct sets of RA configuration—one visible to all hosts and one visible only to PvD-aware hosts—within a single RA transmission, avoiding the need for separate RA sources when differentiation is desired.
DNS recursive server addresses SHOULD be associated with their corresponding PvD and queries sent using a local IP address provisioned for that PvD. To support non-PvD-aware applications, PvD-aware hosts SHOULD ensure that non-PvD-aware name resolution APIs (e.g., getaddrinfo) only use resolvers from a single PvD per query.
Non-PvD-aware hosts ignore the PvD Option (Type 21) and all RA options it contains per RFC 4861 Section 4.2, ensuring backward compatibility. This allows mixed-mode networks with both PvD-aware and non-PvD-aware hosts to coexist without disruption.
When a host shares connectivity via tethering (e.g., cellular to Wi-Fi), it SHOULD propagate the upstream PvD Option downstream with the same PvD ID FQDN, H-flag, Delay, Sequence Number, and with the L-flag set if IPv4 connectivity is also being shared. All options from the upstream PvD Option that are included in the downstream RA SHOULD be placed inside the downstream PvD Option.
A router MAY send RAs containing one PvD Option but MUST NOT include more than one PvD Option in each RA. The PvD Option MUST NOT contain further PvD Options. To provide multiple Explicit PvDs, a router MUST send multiple RAs.
After retrieval, hosts MUST remember the last Sequence Number in RAs for that PvD ID. When a new RA arrives with a different Sequence Number, or when the expiry date is reached, hosts MUST deprecate the Additional Information and stop using it.
DNS name resolution, OCSP certificate validation connections, and the HTTP request for PvD Additional Information MUST all be performed using exclusively the configuration information (DNS servers, source address, next-hop router) attached to the considered PvD.
Hosts MUST verify that the TLS server certificate is valid for the request and that a DNS-ID on the certificate equals the PvD ID FQDN. If validation fails, hosts MUST close the connection and treat the PvD as having no Additional Information.
If exactly one Explicit PvD sets the L-flag, hosts MUST associate DHCPv4 information with that PvD. If multiple Explicit PvDs set the L-flag (a misconfiguration), hosts SHOULD NOT associate the DHCPv4 information with any Explicit PvD. If no Explicit PvD claims association, DHCPv4 configuration MUST be associated with all Implicit PvDs on that interface.
Network operators MUST use PvD ID FQDNs that they own or manage to avoid naming conflicts. The same PvD ID MAY be reused across access networks that provide identical services; otherwise the PvD ID MUST differ per RFC 7556 Section 2.4.
PvD-aware hosts MUST associate received RA configuration information with the Explicit PvD identified by the first PvD Option in the RA, or with the Implicit PvD (identified by host interface and RA source address) if no PvD Option is present. In case multiple PvD Options appear, hosts MUST ignore all but the first.
PvD IDs MUST be compared in a case-insensitive manner as defined by RFC 4343. For example, 'pvd.example.com.' and 'PvD.Example.coM.' refer to the same PvD.
Servers MUST mark responses with the 'application/pvd+json' Content-Type header. Clients SHOULD include this media type as an Accept header in GET requests. If the HTTP response status is ≥ 400, hosts MUST close the connection and consider no Additional Information available; status 300–399 MUST trigger redirect following.
The PvD Additional Information JSON object's 'prefixes' list MUST be checked against all PIO prefixes in the associated RA. If any PIO prefix is not covered by at least one listed prefix, the Additional Information MUST be considered a misconfiguration and MUST NOT be used.
To prevent DoS amplification, hosts MUST enforce a minimum interval of 10 seconds (RECOMMENDED) between Additional Information requests for a given PvD, limit total PvD Additional Information requests to no more than five on a given network within 10 seconds, stop requesting a PvD ID that consistently returns invalid JSON, and stop requesting all PvD IDs after reaching 10 or more failures on a network.
When a host retrieves stateful DHCPv6 assignments, they MUST be associated with the PvD received with RAs having the M-flag set and including a matching Prefix Information Option (PIO), where matching means the PIO prefix includes the DHCPv6 assignment.
When multiple RAs are required to avoid MTU fragmentation, the PvD Option header (all fields except the Options field) MUST be repeated in all transmitted RAs; individual options MAY appear in only one of the transmitted PvD Options.
When the H-flag is set, hosts MAY retrieve PvD Additional Information via an HTTP-over-TLS GET to 'https://<PvD-ID>/.well-known/pvd'. Hosts MUST NOT perform this retrieval when the H-flag is not set.
To minimize identity leakage when fetching PvD Additional Information, hosts SHOULD use an IPv6 temporary address (RFC 4941), SHOULD NOT include a User-Agent header or HTTP cookies, and MAY deprecate and regenerate the temporary address after the fetch to reduce linkability.
To prevent an attacker from probing which PvD IDs are allowed by a host, hosts SHOULD either fetch Additional Information for all eligible PvD IDs on a given local network or fetch it for none of them, rather than selectively fetching based on internal allow-lists.
PvD Additional Information is a JSON object (restricted to the I-JSON profile, RFC 7493) with three mandatory keys: 'identifier' (PvD ID FQDN string), 'expires' (RFC 3339 date after which the object is invalid), and 'prefixes' (array of IPv6 prefix strings valid for this PvD). Optional keys include 'dnsZones' and 'noInternet'.
The Delay field (4-bit unsigned integer) controls randomized backoff before hosts fetch updated PvD Additional Information. When a Sequence Number change is detected, the host waits a uniformly random time between 0 and 2^(10 + Delay) milliseconds before querying. When the H-flag is not set, senders SHOULD set Delay to zero.
The Sequence Number field (16-bit unsigned integer) in the PvD Option signals when PvD Additional Information has been updated. Routers SHOULD increment it whenever new Additional Information is available; if the value exceeds the field width it MUST wrap to zero. Hosts use this to trigger re-fetching of the JSON object.
Vendor-specific or experimental extensions to the PvD Additional Information JSON MUST use sub-dictionaries rather than top-level keys. Sub-dictionary keys SHOULD use a URN namespace if available, or follow the format 'vendor-*' for other private use (e.g., 'vendor-foobar'). Unknown sub-dictionary keys MUST be ignored.
IANA added URI suffix 'pvd' to the 'Well-Known URIs' registry (RFC 8615) with status 'permanent', establishing 'https://<PvD-ID>/.well-known/pvd' as the canonical endpoint for retrieving PvD Additional Information.
IANA created the 'Additional Information PvD Keys' registry under a new 'Provisioning Domains (PvDs)' registry group. Initial entries are the mandatory keys ('identifier', 'expires', 'prefixes') and optional keys ('dnsZones', 'noInternet') from Section 4.3. New assignments require Expert Review; vendor-specific keys SHOULD use sub-dictionaries.
IANA created the 'PvD Option Flags' registry reserving bit positions 0–11 in the PvD Option bitmask. Bits 0 (H-flag), 1 (L-flag), and 2 (R-flag) are assigned by RFC 8801; bits 3–11 are unassigned. Future assignments require Standards Action. The registry is placed under 'ICMPv6 Parameters'.
IANA removed the 'reclaimable' tag for value 21 in the 'IPv6 Neighbor Discovery Option Formats' registry, formally reserving Type 21 for the PvD Option defined in RFC 8801.
An attacker can use the H-flag and arbitrary PvD IDs in forged RAs to amplify a DoS attack by causing hosts to initiate TLS connections to arbitrary servers. Mitigation requires hosts to rate-limit per-PvD requests, rate-limit total requests per network, stop requesting PvDs returning invalid JSON, and cease all PvD requests after 10 or more failures on a given network.
Expiration times in PvD Additional Information use absolute time values and may be skewed by clock errors or hosts without an accurate time base. Such time values MUST NOT be used for security-sensitive functionality or decisions.
The prefix validation check (Section 4.4) provides reasonable assurance against misconfigured or mismatched routers but cannot prevent a hostile router using NPTv6 to spoof PvD ownership. The HTTPS server SHOULD reject requests whose source addresses are not covered by the advertised prefixes as an additional layer of defense.
The PvD Option (Type 21) for Router Advertisements contains: Type (8 bits), Length (8 bits in units of 8 octets), H/L/R flags (1 bit each), Reserved (9 bits), Delay (4 bits), Sequence Number (16 bits), PvD ID FQDN encoded in DNS format (RFC 1035 Section 3.1), padding to next 8-octet boundary, an optional RA message header (16 octets when R-flag set), and zero or more encapsulated RA options.