1.1.Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.1.PvD Option for Router Advertisements

This document introduces a Router Advertisement (RA) option calledthe PvD Option. It is used to convey the FQDN identifying a given PvD (seeFigure 1), bind the PvD ID with configurationinformation received over DHCPv4 (seeSection 3.4.2), enablethe use of HTTP over TLS to retrieve the PvD Additional InformationJSON object (seeSection 4), as well as containany otherRA options that would otherwise be valid in the RA.¶

 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      |    Length     |H|L|R|     Reserved    | Delay |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|       Sequence Number         |                             ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             ......                         PvD ID FQDN                       ......             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...             |                  Padding                      |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                             ......            Router Advertisement message header            ......             (Only present when R-flag is set)             ......                                                             |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|   Options ...+-+-+-+-+-+-+-+-+-+-+-+-

Type:

(8 bits) Set to 21.¶

Length:

(8 bits) The length of the option inunits of 8 octets, including the Type and Length fields, theRouter Advertisement message header, if any, as well as the RAoptions that are included within the PvD Option.¶

H-flag:

(1 bit) 'HTTP' flag stating whether some PvD Additional Information is made available through HTTP over TLS, as described inSection 4.¶

L-flag:

(1 bit) 'Legacy' flag stating whether the PvD is associated withIPv4 information assigned using DHCPv4 (seeSection 3.4.2).¶

R-flag:

(1 bit) 'Router Advertisement' flag stating whether the PvD Option header is followed (right after padding to the next 64-bit boundary) by a Router Advertisement message header (seeSection 4.2 of [RFC4861]). The usage of the inner message header is described inSection 3.4.¶

Reserved:

(9 bits) Reserved for later use. ItMUST be set to zero by the sender and ignored by the receiver.¶

Delay:

(4 bits) Unsigned integer used to delay HTTP GET queries from hosts by a randomized backoff (seeSection 4.1). If the H-flag is not set, sendersSHOULD set the delay to zero, and receiversSHOULD ignore the value.¶

Sequence Number:

(16 bits) Sequence number for the PvD Additional Information, as described inSection 4. If the H-flag is not set, sendersSHOULD set the Sequence Number to zero, and receiversSHOULD ignore the value.¶

PvD ID FQDN:

The FQDN used as PvD ID encoded in DNS format, as described inSection 3.1 of [RFC1035]. Domain name compression as described inSection 4.1.4 of [RFC1035]MUST NOT be used.¶

Padding:

Zero or more padding octets to the next 8-octet boundary (seeSection 4.6 of [RFC4861]). ItMUST be set to zero by the sender and ignored by the receiver.¶

RA message header:

(16 octets) When the R-flag is set, a full Router Advertisement message header as specified in[RFC4861]. The senderMUST set the Type field to 134 (the value for "Router Advertisement") and set the Code field to 0. ReceiversMUST ignore both of these fields. The Checksum fieldMUST be set to 0 by the sender; non-zero checksumsMUST be ignored by the receiver without causing the processing of the message to fail. All other fields are to be set and parsed as specified in[RFC4861] or any updating documents.¶

Options:

Zero or more RA options that would otherwise be valid as part of the Router Advertisement main body but are instead included in the PvD Option so as to be ignored by hosts that are not PvD aware.¶

Figure 2 shows an example of a PvD Option with "example.org" as the PvD ID FQDN and includes both a Recursive DNS Server (RDNSS) option and a Prefix Information Option. It has a Sequence Number of 123 and indicates the presence of PvD Additional Information that is expected to be fetched with a delay factor of 1.¶

 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: 21      |  Length: 12   |1|0|0|     Reserved    |Delay:1|+---------------+-------------------------------+---------------+|       Seq number: 123         |      7        |       e       |+---------------+-----------------------------------------------+|      x        |       a       |      m        |       p       |+---------------------------------------------------------------+|      l        |       e       |      3        |       o       |+---------------------------------------------------------------+|      r        |       g       |      0        |   0 (padding) |+---------------------------------------------------------------+|   0 (padding) |  0 (padding)  |   0 (padding) |   0 (padding) |+---------------+---------------+---------------+---------------+|  RDNSS option (RFC 8106) length: 5                          ......                                                           ......                                                             |+---------------------------------------------------------------+| Prefix Information Option (RFC 4861) length: 4              ......                                                             |...                                                             |+---------------------------------------------------------------+

3.2.Router Behavior

A routerMAY send RAs containing one PvD Option butMUST NOT include more than one PvD Option in each RA. The PvD OptionMUST NOT contain further PvD Options.¶

The PvD OptionMAY contain zero, one, or more RA options that would otherwise be valid as part of the same RA. Such options are processed by PvD-aware hosts and ignored by other hosts as perSection 4.2 of [RFC4861].¶

In order to provide multiple different PvDs, a routerMUST send multiple RAs. RAs sent from different link-local source addresses establish distinct Implicit PvDs in the absence of a PvD Option. Explicit PvDsMAY share link-local source addresses with an Implicit PvD and any number of other Explicit PvDs.¶

In other words, different Explicit PvDsMAY be advertised with RAs using the same link-local source address, but different Implicit PvDs, advertised by different RAs,MUST use different link-local addresses because these Implicit PvDs are identified by the source addresses of the RAs. If a link-local address on the router is changed, then any new RA will be interpreted as a different Implicit PvD by PvD-aware hosts.¶

As specified in[RFC4861] and[RFC6980], when the set of options causes the size of an advertisement to exceed the link MTU, multiple router advertisementsMUST be sent to avoid fragmentation, each containing a subset of the options. In such cases, the PvD Option header (i.e., all fields except the Options field)MUST be repeated in all the transmitted RAs. The options within the Options fieldMAY be transmitted onlyonce, included in one of the transmitted PvD Options.¶

3.3.Non-PvD-Aware Host Behavior

As the PvD Option has a new option code, non-PvD-aware hosts will simply ignore the PvD Option and all the options it contains (seeSection 4.2 of [RFC4861]). This ensures the backward compatibility required inSection 3.3 of [RFC7556]. This behavior allows for a mixed-mode network where a mix of PvD-aware and non-PvD-aware hosts coexist.¶

3.4.PvD-Aware Host Behavior

HostsMUST associate received RAs and included configuration information (e.g., Router Valid Lifetime, Prefix Information[RFC4861], Recursive DNS Server[RFC8106], and Routing Information[RFC4191] options) with the Explicit PvD identified by the first PvD Option present in the received RA, if any, or with the Implicit PvD identified by the host interface and the source address of the received RA otherwise. If an RA message header is present both within the PvD Option and outside it, the header within the PvD Option takes precedence.¶

In case multiple PvD Options are found in a given RA, hostsMUST ignore all but the first PvD Option.¶

If a host receives PvD Options flags that it does not recognize (currently in the Reserved field), itMUST ignore these flags.¶

Similarly, hostsMUST associate all network configuration objects (e.g., default routers, addresses, more specific routes, and DNS Recursive Resolvers) with the PvD associated with the RA that provisioned the object. For example, addresses that are generated using a received Prefix Information Option (PIO) are associated with the PvD of the last received RA that included the given PIO.¶

PvD IDsMUST be compared in a case-insensitive manner as defined by[RFC4343]. For example, "pvd.example.com." or"PvD.Example.coM."would refer to the same PvD.¶

While performing PvD-specific operations such as resolving names, executing the default address selection algorithm[RFC6724], or executing the default router selection algorithm when forwarding packets[RFC4861][RFC4191][RFC8028], hosts and applicationsMAY consider only the configuration associated with any non-empty subset of PvDs. For example, a hostMAY associate a given process with a specific PvD, or a specific set of PvDs, while associating another process with another PvD. A PvD-aware application might also be able to select, on a per-connection basis, which PvDs should be used. In particular, constrained devices such as small battery-operated devices (e.g., Internet of Things (IoT)) or devices with limited CPU or memory resources may purposefully use a single PvD while ignoring some received RAs containing different PvD IDs.¶

The way an application expresses its desire to use a given PvD, or a set of PvDs, and the way this selection is enforced are out of the scope of this document. Useful insights about these considerations can be found in[MPVD-API].¶

4.1.Retrieving the PvD Additional Information

When the H-flag of the PvD Option is set, hostsMAY attempt to retrieve the PvD Additional Information associated with a given PvD by performing an HTTP-over-TLS[RFC2818] GET query tohttps://<PvD-ID>/.well-known/pvd. Inversely, hostsMUST NOT do so whenever the H-flag is not set.¶

Recommendations for how to use TLS securely can be found in[RFC7525].¶

When a host retrieves the PvD Additional Information, itMUSTverify that the TLS server certificate is valid for the performedrequest, specifically, that a DNS-ID[RFC6125]on the certificate is equal tothe PvD ID expressed as an FQDN. This validation indicates that theowner of the FQDN authorizes its use with the prefix advertised by the router.If this validation fails, hostsMUST close the connection andtreat the PvDas if it has no Additional Information.¶

HTTP requests and responses for PvD Additional Information use the"application/pvd+json" media type (seeSection 8.5). ClientsSHOULD include this media type as an Accept header field intheir GETrequests, and serversMUST mark this media type as theirContent-Typeheader field in responses.¶

Note that the DNS name resolution of the PvD ID, any connections madefor certificate validation (such as Online Certificate Status Protocol (OCSP)[RFC6960]), andthe HTTP request itselfMUST be performed using the consideredPvD.In other words, the name resolution, PKI checks, source addressselection, as well as the next-hop router selectionMUST beperformedwhile exclusively using the set of configuration information attachedwith the PvD, as defined inSection 3.4. In somecases, itmay therefore be necessary to wait for an address to be available foruse (e.g., once the Duplicate Address Detection or DHCPv6 processesare complete) before initiating the HTTP-over-TLS query. In order toaddress privacy concerns around linkability of the PvD HTTP connectionwith future user-initiated connections, if the host has a temporary addressper[RFC4941] in this PvD, then itSHOULD use a temporary addressto fetch the PvD Additional Information andMAY deprecate theusedtemporary address and generate a new temporary address afterward.¶

If the HTTP status of the answer is greater than or equal to 400, the hostMUST close its connection and consider that there is no PvD Additional Information. If the HTTP status of the answer is between 300 and 399, inclusive, itMUST follow the redirection(s). If the HTTP status of the answer is between 200 and 299, inclusive, the response is expected to be a single JSON object.¶

After retrieval of the PvD Additional Information, hostsMUST rememberthe last Sequence Number value received in an RA including the samePvD ID. Whenever a new RA for the same PvD is received with a differentSequence Number value, or whenever the expiry date for the additionalinformation is reached, hostsMUST deprecate the AdditionalInformationand stop using it.¶

Hosts retrieving a new PvD Additional Information objectMUST checkfor the presence and validity of the mandatory fields specified inSection 4.3. A retrieved object including anexpirationtime that is already past or missing a mandatory elementMUSTbeignored.¶

In order to avoid synchronized queries toward the server hostingthe PvD Additional Information when an object expires, object updatesare delayed by a randomized backoff time.¶

• When a host performs a JSON object update after it detected achange in the PvD Option Sequence Number, itMUST add a delaybefore sending the query. The target time for the delay is calculatedas a random time between zero and 2^{(10 + Delay)} milliseconds,where 'Delay' corresponds to the 4-bit unsigned integer inthe last received PvD Option.¶
• When a host last retrieved a JSON object at time A that includes anexpiry time B using the "expires" key, and the host is configured to keepthe PvD Additional Information up to date, itMUST add somerandomness intoits calculation of the time to fetch the update. The target time forfetching the updated object is calculated as a uniformly random timein the interval [(B-A)/2,B].¶

In the example inFigure 2, the Delay field value is 1; this means that the host calculates its delay by choosing a uniformly random time between 0 and 2^{(10 + 1)} milliseconds, i.e., between 0 and 2048 milliseconds.¶

Since the Delay value is directly within the PvD Option rather than the object itself, an operator may perform a push-based update by incrementing the Sequence Number value while changing the Delay value depending on the criticality of the update and the capacity of its PvD Additional Information servers.¶

In addition to adding a random delay when fetching Additional Information, hostsMUST enforce a minimum time between requesting AdditionalInformationfor a given PvD on the same network. This minimum time isRECOMMENDEDto be 10 seconds, in order to avoid hosts causing a denial-of-service on thePvD server. Hosts alsoMUST limit the number of requests thatare made todifferent PvD Additional Information servers on the same network within ashortperiod of time. ARECOMMENDED value is to issue no more thanfive PvDAdditional Information requests in total on a given network within 10 seconds.For more discussion, seeSection 6.¶

The PvD Additional Information object includes a set of IPv6prefixes (under the key "prefixes") thatMUST be checkedagainst allthe Prefix Information Options advertised in the RA. If any of theprefixes included in any associated PIO is not covered by at least one of thelisted prefixes, the PvD Additional InformationMUST beconsideredto be a misconfiguration andMUST NOT be used by the host. SeeSection 4.4 for more discussion on handlingsuch misconfigurations.¶

If the request for PvD Additional Information fails due to a TLS certificate validationerror, an HTTP error, or because the retrieved file does not contain valid PvDJSON,hostsMUST close any connection used to fetch the PvDAdditional InformationandMUST NOT request the information for that PvD ID again forthe durationof the local network attachment. If a host detects 10 or more such failuresto fetch PvD Additional Information, the local network is assumed to bemisconfigured or under attack and the hostMUST NOT make anyfurtherrequests for any PvD Additional Information, belonging to any PvD ID, forthe duration of the local network attachment. For more discussion, seeSection 6.¶

4.2.Operational Consideration to Providing the PvD Additional Information

Whenever the H-flag is set in the PvD Option, a valid PvD Additional Information objectMUST be made available to all hosts receiving the RA by the network operator. In particular, when a captive portal is present, hostsMUST still be allowed to perform DNS, certificate validation, and HTTP-over-TLS operations related to the retrieval of the object, even before logging into the captive portal.¶

RoutersSHOULD increment the PvD Option Sequence Number by one whenever a new PvD Additional Information object is available and should be retrieved by hosts. If the value exceeds what can be stored in the Sequence Number field, itMUST wrap back to zero.¶

The server providing the JSON filesSHOULD also check whether the client address is contained by the prefixes listed in the Additional Information andSHOULD return a 403 response code if there is no match.¶

4.3.PvD Additional Information Format

The PvD Additional Information is a JSON object.¶

The following table presents the mandatory keys, whichMUST be included in the object:¶

A retrieved object that does not include all three of these keys atthe root of the JSON objectMUST be ignored. All three keysneedto be validated; otherwise, the objectMUST be ignored. Thevalue storedfor "identifier"MUST be matched against the PvD ID FQDNpresented in thePvD Option using the comparison mechanism described inSection 3.4.The value stored for "expires"MUST be a valid date in thefuture.If the PIO of the received RA is not covered by at least one of the "prefixes"key, the retrieved objectSHOULD be ignored.¶

The following table presents some optional keys thatMAY beincluded in the object.¶

It is worth noting that the JSON format allows for extensions.Whenever an unknown key is encountered, itMUST be ignoredalong withits associated elements.¶

Private-use or experimental keysMAY be used in the JSONdictionary. In order to avoid such keys colliding with the keys registered byIANA,implementers or vendors defining private-use or experimentalkeysMUST create sub-dictionaries. If a set of PvD AdditionalInformation keysare defined by an organization that has a formal URN namespace[IANA-URN],the URN namespaceSHOULD be used as the top-level JSON key forthe sub-dictionary. For other private uses, the sub-dictionary keySHOULD follow the format of "vendor-*", where the "*" isreplaced by theimplementer's or vendor's identifier. For example, keys specific to the FooBarorganization could use "vendor-foobar". If a host receives a sub-dictionarywithan unknown key, the hostMUST ignore the contents of the sub-dictionary.¶

{  "identifier": "cafe.example.com.",  "expires": "2020-05-23T06:00:00Z",  "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],}{  "identifier": "company.foo.example.com.",  "expires": "2020-05-23T06:00:00Z",  "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],  "vendor-foo":    {        "private-key": "private-value",    },}

4.4.Detecting Misconfiguration and Misuse

HostsMUST validate the TLS server certificate when retrieving PvDAdditional Information, as detailed inSection 4.1.¶

HostsMUST verify that all prefixes in all the RA PIOs are covered by aprefix from the PvD Additional Information. An adversarial routerattempting to spoof the definition of an Explicit PvD, without the ability tomodify the PvD Additional Information, would need to perform IPv6-to-IPv6NetworkPrefix Translation (NPTv6)[RFC6296] in orderto circumvent this check.Thus, this check cannot prevent all spoofing, but it can detectmisconfigurationor mismatched routers that are not adding a NAT.¶

If NPTv6 is being added in order to spoof PvD ownership, the HTTPS server for Additional Information can detect this misconfiguration. The HTTPS serverSHOULD validate the source addresses of incoming connections (seeSection 4.1). This check gives reasonable assurance that NPTv6 was not used and restricts the information to the valid network users.If the PvD does not provision IPv4 (it does not include the L-flag in the RA), the server cannot validate the source addresses of connections using IPv4. Thus, the PvD ID FQDN for such PvDsSHOULD NOT have a DNS A record.¶

5.1.Exposing Extra RA Options to PvD-Aware Hosts

In this example, there is one RA message sent by the router. This message contains some options applicable to all hosts on the network and also a PvD Option that also contains other options only visible to PvD-aware hosts.¶

• RA Header: router lifetime = 6000¶
• Prefix Information Option: length = 4, prefix =2001:db8:cafe::/64¶

• PvD Option header: length = 3 + 5 + 4, PvD ID FQDN =example.org., R-flag = 0 (actual length of the header with padding24 bytes = 3 * 8 bytes)¶

  • Recursive DNS Server: length = 5, addresses = [2001:db8:cafe::53, 2001:db8:f00d::53]¶
  • Prefix Information Option: length = 4, prefix = 2001:db8:f00d::/64¶

Note that a PvD-aware host will receive two different prefixes,2001:db8:cafe::/64 and2001:db8:f00d::/64, both associated with the same PvD (identified by "example.org."). A non-PvD-aware host will only receive one prefix,2001:db8:cafe::/64.¶

5.2.Different RAs for PvD-Aware and Non-PvD-Aware Hosts

It is expected that for some years, networks will have a mixedenvironment of PvD-aware hosts and non-PvD-aware hosts. If there is aneed to give specific information to PvD-aware hosts only, then it isRECOMMENDED to send two RA messages, one for each class ofhosts.This approach allows for two distinct sets of configuration informationto be sent in a way that will not disrupt non-PvD-aware hosts. It alsolowers the risk that a single RA message will approach its MTU limit dueto duplicated information.¶

If two RA messages are sent for this reason, theyMUST be sent from twodifferent link-local source addresses (Section 3.2). For example, here is theRA sent for non-PvD-aware hosts:¶

• RA Header: router lifetime = 6000 (non-PvD-aware hosts will use this router as a default router)¶
• Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64¶
• Recursive DNS Server Option: length = 3, addresses = [2001:db8:cafe::53]¶

• PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org., R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes)¶

  • RA Header: router lifetime = 0 (PvD-aware hosts will not use this router as a default router), implicit length = 2¶

And here is the RA sent for PvD-aware hosts:¶

• RA Header: router lifetime = 0 (non-PvD-aware hosts will not use this router as a default router)¶

• PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = bar.example.org., R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes)¶

  • RA Header: router lifetime = 1600 (PvD-aware hosts will use this router as a default router), implicit length = 2¶
  • Prefix Information Option: length = 4, prefix = 2001:db8:f00d::/64¶
  • Recursive DNS Server Option: length = 3, addresses = [2001:db8:f00d::53]¶

In the above example, non-PvD-aware hosts will only use the first listed RA sent by their default router and use the2001:db8:cafe::/64 prefix. PvD-aware hosts will autonomously configure addresses from both PIOs but will only use the source address in2001:db8:f00d::/64 to communicate past the first-hop router since only the router sending the second RA will be used as the default router; similarly, they will use the DNS server2001:db8:f00d::53 when communicating from this address.¶

5.3.Enabling Multihoming for PvD-Aware Hosts

In this example, the goal is to have one prefix from one RA be usable by both non-PvD-aware and PvD-aware hosts and to have another prefix usable only by PvD-aware hosts. This allows PvD-aware hosts to be able to effectively multihome on the network.¶

The first RA is usable by all hosts. The only difference for PvD-aware hosts is that they can explicitly identify the PvD ID associated with the RA. PvD-aware hosts will also use this prefix to communicate with non-PvD-aware hosts on the same network.¶

• RA Header: router lifetime = 6000 (non-PvD-aware hosts will use this router as a default router)¶
• Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64¶
• Recursive DNS Server Option: length = 3, addresses = [2001:db8:cafe::53]¶
• PvD Option header: length = 3, PvD ID FQDN = foo.example.org., R-flag = 0 (actual length of the header 24 bytes = 3 * 8 bytes)¶

The second RA contains a prefix usable only by PvD-aware hosts. Non-PvD-awarehosts will ignore this RA; hence, only the PvD-aware hosts will be multihomed.¶

• RA Header: router lifetime = 0 (non-PvD-aware hosts will not usethis router as a default router)¶

• PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = bar.example.org., R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes)¶

  • RA Header: router lifetime = 1600 (PvD-aware hosts will use this router as a default router), implicit length = 2¶
  • Prefix Information Option: length = 4, prefix = 2001:db8:f00d::/64¶
  • Recursive DNS Server Option: length = 3, addresses = [2001:db8:f00d::53]¶

Note: the above examples assume that the router has received its PvD IDs from upstream routersor via some other configuration mechanism. Another document could define waysfor the routerto generate its own PvD IDs to allow the above scenario in the absence of PvDID provisioning.¶

5.4.Providing Additional Information to PvD-Aware Hosts

In this example, the router indicates that it provides Additional Information using the H-flag.The Sequence Number on the PvD Option is set to 7 in this example.¶

• RA Header: router lifetime = 6000¶
• Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64¶
• Recursive DNS Server Option: length = 3, addresses = [2001:db8:cafe::53]¶
• PvD Option header: length = 3, PvD ID FQDN = cafe.example.com.,Sequence Number = 7, R-flag = 0, H-flag = 1 (actual length of the header withpadding24 bytes = 3 * 8 bytes)¶

A PvD-aware host will fetch <https://cafe.example.com/.well-known/pvd> to get the additional information. The following example shows a GET request that the host sends, in HTTP/2 syntax[RFC7540]:¶

:method = GET:scheme = https:authority = cafe.example.com:path = /.well-known/pvdaccept = application/pvd+json

The HTTP server will respond with the JSON Additional Information:¶

:status = 200content-type = application/pvd+jsoncontent-length = 116{  "identifier": "cafe.example.com.",  "expires": "2020-05-23T06:00:00Z",  "prefixes": ["2001:db8:cafe::/48"],}

At this point, the host has the PvD Additional Information and knows the expiry time. When either the expiry time passes or a new Sequence Number is provided in an RA, the host will re-fetch the Additional Information.¶

For example, if the router sends a new RA with the Sequence Number set to 8,the host will re-fetch the Additional Information:¶

• PvD Option header: length = 3 + 5 + 4 , PvD ID FQDN = cafe.example.com.,Sequence Number = 8, R-flag = 0, H-flag = 1 (actual length of the header withpadding24 bytes = 3 * 8 bytes)¶

However, if the router sends a new RA, but the Sequence Number has not changed,the host would not re-fetch the Additional Information (until and unless theexpiry timeof the Additional Information has passed).¶

8.1.Change to IPv6 Neighbor Discovery Option Formats Registry

IANA has removed the'reclaimable' tag for value 21 for the PvD Option in the "IPv6 Neighbor Discovery Option Formats" registry.¶

8.2.New Entry in the Well-Known URIs Registry

IANA has added a new entry in the "Well-Known URIs" registry[RFC8615] with the following information:¶

URI suffix: pvd¶

Change controller: IETF¶

Specification document: RFC 8801¶

Status: permanent¶

Related information: N/A¶

8.3.New Additional Information PvD Keys Registry

IANA has created and will maintain a new registry called "Additional Information PvD Keys", which reserves JSON keys for use in PvD Additional Information. The initial contents of this registry are given inSection 4.3 (both the table of mandatory keys and the table of optional keys).¶

The status of a key as mandatory or optional is intentionally not denoted in the table to allow for flexibility in future use cases. Any new assignments of keys will be considered as optional for the purpose of the mechanism described in this document.¶

New assignments in the "Additional Information PvD Keys" registry will be administered by IANA through Expert Review[RFC8126]. Experts are requested to ensure that defined keys do not overlap in names or semantics and that they represent non-vendor-specific use cases. Vendor-specific keysSHOULD use sub-dictionaries, as described inSection 4.3.¶

IANA has placed the "Additional Information PvD Keys" registry within a new registry entitled "Provisioning Domains (PvDs)".¶

8.4.New PvD Option Flags Registry

IANA has also created and will maintain a new registry entitled "PvD Option Flags". This new registry reserves bit positions from 0 to 11 to be used in the PvD Option bitmask. This document assigns bit positions 0, 1, and 2 as shown in the table below. Future assignments require Standards Action[RFC8126].¶

Since these flags apply to an IPv6 Router Advertisement Option, IANA has placed this registry under the existing "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry and provided a link on the new "Provisioning Domains (PvDs)" registry.¶

8.5.PvD JSON Media Type Registration

This document registers the media type for PvD JSON text,"application/pvd+json".¶

Type name:

application¶

Subtype name:

pvd+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

Encoding considerations are identical tothose specified for the "application/json" media type.¶

Security considerations:

SeeSection 6 of RFC 8801.¶

Interoperability considerations:

This document specifies the format ofconforming messages and the interpretation thereof.¶

Published specification:

RFC 8801¶

Applications that use this media type:

This media type is intended to be used by networks advertising additional Provisioning Domain information and clients looking up such information.¶

Fragment identifier considerations:

N/A¶

Additional information:

N/A¶

Person & email address to contact for further information:

SeeAuthors' Addresses section¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

IETF¶

Change controller:

IETF¶