idnits 2.17.1 draft-ietf-intarea-provisioning-domains-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2019) is 1774 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 intarea P. Pfister 3 Internet-Draft E. Vyncke, Ed. 4 Intended status: Standards Track Cisco 5 Expires: December 20, 2019 T. Pauly 6 Apple 7 D. Schinazi 8 Google LLC 9 W. Shao 10 Cisco 11 June 18, 2019 13 Discovering Provisioning Domain Names and Data 14 draft-ietf-intarea-provisioning-domains-05 16 Abstract 18 An increasing number of hosts access the Internet via multiple 19 interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix 20 configurations context. 22 This document describes a way for hosts to identify such contexts, 23 called Provisioning Domains (PvDs), where Fully Qualified Domain 24 Names (FQDNs) act as PvD identifiers. Those identifiers are 25 advertised in a new Router Advertisement (RA) option and, when 26 present, are associated with the set of information included within 27 the RA. 29 Based on this FQDN, hosts can retrieve additional information about 30 their network access characteristics via an HTTP over TLS query. 31 This allows applications to select which Provisioning Domains to use 32 as well as to provide configuration parameters to the transport layer 33 and above. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 20, 2019. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Provisioning Domain Identification using Router 71 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 5 73 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 8 75 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 8 76 3.4.1. DHCPv6 configuration association . . . . . . . . . . 9 77 3.4.2. DHCPv4 configuration association . . . . . . . . . . 9 78 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 9 79 3.4.4. Usage of DNS Servers . . . . . . . . . . . . . . . . 10 80 4. Provisioning Domain Additional Information . . . . . . . . . 11 81 4.1. Retrieving the PvD Additional Information . . . . . . . . 11 82 4.2. Operational Consideration to Providing the PvD Additional 83 Information . . . . . . . . . . . . . . . . . . . . . . . 13 84 4.3. PvD Additional Information Format . . . . . . . . . . . . 13 85 4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 15 87 5. Operational Considerations . . . . . . . . . . . . . . . . . 16 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 8.1. Additional Information PvD Keys Registry . . . . . . . . 18 92 8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 19 93 8.3. PvD JSON Media Type Registration . . . . . . . . . . . . 19 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 10.1. Normative references . . . . . . . . . . . . . . . . . . 20 97 10.2. Informative references . . . . . . . . . . . . . . . . . 21 98 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 23 99 A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 23 100 A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 23 101 A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 24 102 A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 24 103 A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 25 104 A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 25 105 A.7. WG Document version 04 . . . . . . . . . . . . . . . . . 26 106 A.7.1. WG Document version 05 . . . . . . . . . . . . . . . 26 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 109 1. Introduction 111 It has become very common in modern networks for hosts to access the 112 internet through different network interfaces, tunnels, or next-hop 113 routers. For example, if Alice has a mobile phone provider and a 114 broadband provider in her home, her devices and her applications 115 should be capable of seamlessly transitioning from one to the other 116 and be able to use her Wi-Fi to access local resources or use the 117 more suitable link on a per-application base. This document provides 118 the basic information necessary to make this choice intelligently. 119 There are similar use cases for IPsec Virtual Private Networks that 120 are already considered Explicit PvDs in [RFC7556]. 122 To describe the set of network configurations associated with each 123 access method, the concept of Provisioning Domain (PvD) was defined 124 in [RFC7556]. 126 This document specifies a way to identify PvDs with Fully Qualified 127 Domain Names (FQDN), called PvD IDs. Those identifiers are 128 advertised in a new Router Advertisement (RA) [RFC4861] option called 129 the PvD ID Router Advertisement option which, when present, 130 associates the PvD ID with all the information present in the Router 131 Advertisement as well as any configuration object, such as addresses, 132 deriving from it. The PVD ID Router Advertisement option may also 133 contain a set of other RA options. Since such options are only 134 considered by hosts implementing this specification, network 135 operators may configure hosts that are 'PvD-aware' with PvDs that are 136 ignored by other hosts. 138 Since PvD IDs are used to identify different ways to access the 139 internet, multiple PvDs (with different PvD IDs) could be provisioned 140 on a single host interface. Similarly, the same PvD ID could be used 141 on different interfaces of a host in order to inform that those PvDs 142 ultimately provide identical services. 144 This document also introduces a way for hosts to retrieve optional 145 and additional information related to a specific PvD by means of an 146 HTTP over TLS query using an URI derived from the PvD ID. The 147 retrieved JSON object contains additional information that would 148 typically be considered unfit, or too large, to be directly included 149 in the Router Advertisement, but might be considered useful to the 150 applications, or even sometimes users, when choosing which PvD should 151 be used. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in 158 [RFC2119]. 160 In addition, this document uses the following terminology: 162 Provisioning Domain (PvD): A set of network configuration 163 information; for more information, see [RFC7556]. 165 PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a 166 PvD. 168 Explicit PvD: A PvD uniquely identified with a PvD ID. For more 169 information, see [RFC7556]. 171 Implicit PvD: A PvD that, in the absence of a PvD ID, is identified 172 by the host interface to which it is attached and the address of 173 the advertising router. See also [RFC7556]. 175 PvD-aware host A host that supports the association of network 176 configuration information into PvDs and the use of these PvDs. 177 Also named PvD-aware node in [RFC7556]. 179 3. Provisioning Domain Identification using Router Advertisements 181 Explicit PvDs are identified by a PvD ID. The PvD ID is a Fully 182 Qualified Domain Name (FQDN) which MUST belong to the network 183 operator in order to avoid naming collisions. The same PvD ID MAY be 184 used in several access networks when they ultimately provide 185 identical services (e.g., in all home networks subscribed to the same 186 service); else, the PvD ID MUST be different to follow section 2.4 of 187 [RFC7556]. 189 3.1. PvD ID Option for Router Advertisements 191 This document introduces a Router Advertisement (RA) option called 192 PvD option. It is used to convey the FQDN identifying a given PvD 193 (see Figure 1), bind the PvD ID with configuration information 194 received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over 195 TLS to retrieve the PvD Additional Information JSON object (see 196 Section 4), as well as contain any other RA options which would 197 otherwise be valid in the RA. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length |H|L|R| Reserved | Delay | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Sequence Number | ... 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 206 ... PvD ID FQDN ... 207 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ... | Padding | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | ... 211 ... Router Advertisement message header ... 212 ... (Only present when R-flag is set) ... 213 ... | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Options ... 216 +-+-+-+-+-+-+-+-+-+-+-+- 218 Figure 1: PvD ID Router Advertisements Option format 220 Type : (8 bits) Set to 21. 222 Length : (8 bits) The length of the option in units of 8 223 octets, including the Type and Length fields, the Router 224 Advertisement message header, if any, as well as the RA options 225 that are included within the PvD Option. 227 H-flag : (1 bit) 'HTTP' flag stating whether some PvD 228 Additional Information is made available through HTTP over TLS, as 229 described in Section 4. 231 L-flag : (1 bit) 'Legacy' flag stating whether the router is 232 also providing IPv4 information using DHCPv4 (see Section 3.4.2). 234 R-flag : (1 bit) 'Router Advertisement' flag stating whether 235 the PvD Option is followed (right after padding to the next 64 236 bits boundary) by a Router Advertisement message header (See 237 section 4.2 of [RFC4861]). 239 Delay : (4 bits) Unsigned integer used to delay HTTP GET 240 queries from hosts by a randomized backoff (see Section 4.1). 242 Reserved : (13 bits) Reserved for later use. It MUST be set to 243 zero by the sender and ignored by the receiver. 245 Sequence Number: (16 bits) Sequence number for the PvD Additional 246 Information, as described in Section 4. 248 PvD ID FQDN : The FQDN used as PvD ID encoded in DNS format, as 249 described in Section 3.1 of [RFC1035]. Domain names compression 250 described in Section 4.1.4 of [RFC1035] MUST NOT be used. 252 Padding : Zero or more padding octets to the next 8 octets 253 boundary. It MUST be set to zero by the sender, and ignored by 254 the receiver. 256 RA message header : (16 octets) When the R-flag is set, a full 257 Router Advertisement message header as specified in [RFC4861]. 258 The sender MUST set the 'Type' to 134, the value for "Router 259 Advertisement", and set the 'Code' to 0. Receivers MUST ignore 260 both of these fields. The 'Checksum' MUST be set to 0 by the 261 sender; non-zero checksums MUST be ignored by the receiver. All 262 other fields are to be set and parsed as specified in [RFC4861] or 263 any updating documents. 265 Options : Zero or more RA options that would otherwise be valid as 266 part of the Router Advertisement main body, but are instead 267 included in the PvD Option such as to be ignored by hosts that are 268 not 'PvD-aware'. 270 Here is an example of a PvD option with example.org as the PvD ID 271 FQDN and including a RDNSS and prefix information options (it also 272 have the sequence number 123, presence of additional information to 273 be fetched with a delay indicated as 5): 275 0 1 2 3 276 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 277 +---------------+-----------------------------------------------+ 278 | Type: 21 | Length: 12 |1|0|0| Reserved |Delay:5| 279 +---------------+-------------------------------+---------------+ 280 | Seq number: 123 | 7 | e | 281 +---------------+-----------------------------------------------+ 282 | x | a | m | p | 283 +---------------------------------------------------------------+ 284 | l | e | 3 | o | 285 +---------------------------------------------------------------+ 286 | r | g | 0 | 0 (padding) | 287 +---------------------------------------------------------------+ 288 | 0 (padding) | 0 (padding) | 0 (padding) | 0 (padding) | 289 +---------------+---------------+---------------+---------------+ 290 | RDNSS option (RFC 6106) length: 5 ... 291 ... ... 292 ... | 293 +---------------------------------------------------------------+ 294 | Prefix Information Option (RFC 4861) length: 4 ... 295 ... | 296 ... | 297 +---------------------------------------------------------------+ 299 Figure 2 301 3.2. Router Behavior 303 A router MAY send RAs containing one PvD option, but MUST NOT include 304 more than one PvD option in each RA. In particular, the PvD option 305 MUST NOT contain further PvD options. 307 The PvD Option MAY contain zero, one, or more RA options which would 308 otherwise be valid as part of the same RA. Such options are 309 processed by PvD-aware hosts, while ignored by others. 311 In order to provide multiple different PvDs, a router MUST send 312 multiple RAs. Different explicit PvDs MAY be advertised with RAs 313 using the same IPv6 source address; but different implicit PvDs, 314 advertised by different RAs, MUST use different link-local addresses 315 because these implicit PvDs are identified by the source addresses of 316 the RAs. 318 As specified in [RFC4861], when the set of options causes the size of 319 an advertisement to exceed the link MTU, multiple router 320 advertisements can be sent, each containing a subset of the options. 321 In such cases, the PvD option header (i.e., all fields except the 322 'Options' field) MUST be repeated in all the transmitted RAs. The 323 options within the 'Options' field, MAY be transmitted only once, 324 included in one of the transmitted PvD options. 326 3.3. Non-PvD-aware Host Behavior 328 As the PvD Option has a new option code, non-PvD-aware hosts will 329 simply ignore the PvD Option and all the options it contains. This 330 ensure the backward compatibility required in section 3.3 of 331 [RFC7556]. This behavior allows for a mixed-mode network with a mix 332 of PvD-aware and non-PvD-aware hosts coexist. 334 3.4. PvD-aware Host Behavior 336 Hosts MUST associate received RAs and included configuration 337 information (e.g., Router Valid Lifetime, Prefix Information 338 [RFC4861], Recursive DNS Server [RFC8106], Routing Information 339 [RFC4191] options) with the explicit PvD identified by the first PvD 340 Option present in the received RA, if any, or with the implicit PvD 341 identified by the host interface and the source address of the 342 received RA otherwise. 344 In case multiple PvD options are found in a given RA, hosts MUST 345 ignore all but the first PvD option. 347 If a host receives PvD options flags that it does not recognize 348 (currently in the Reserved field), it MUST ignore these flags. 350 Similarly, hosts MUST associate all network configuration objects 351 (e.g., default routers, addresses, more specific routes, DNS 352 Recursive Resolvers) with the PvD associated with the RA which last 353 updated the object. For example, addresses that are generated using 354 a received Prefix Information option (PIO) are associated with the 355 PvD of the last received RA which included the given PIO. 357 PvD IDs MUST be compared in a case-insensitive manner (i.e., A=a), 358 assuming ASCII with zero parity while non-alphabetic codes must match 359 exactly (see also Section 3.1 of [RFC1035]). For example, 360 "pvd.example.com." or "PvD.Example.coM." would refer to the same PvD. 362 While resolving names, executing the default address selection 363 algorithm [RFC6724] or executing the default router selection 364 algorithm when forwarding packets ([RFC2461], [RFC4191] and 365 [RFC8028]), hosts MAY consider only the configuration associated with 366 an arbitrary set of PvDs. 368 For example, a host MAY associate a given process with a specific 369 PvD, or a specific set of PvDs, while associating another process 370 with another PvD. A PvD-aware application might also be able to 371 select, on a per-connection basis, which PvDs should be used. In 372 particular, constrained devices such as small battery operated 373 devices (e.g. IoT), or devices with limited CPU or memory resources 374 may purposefully use a single PvD while ignoring some received RAs 375 containing different PvD IDs. 377 The way an application expresses its desire to use a given PvD, or a 378 set of PvDs, or the way this selection is enforced, is out of the 379 scope of this document. Useful insights about these considerations 380 can be found in [I-D.kline-mif-mpvd-api-reqs]. 382 3.4.1. DHCPv6 configuration association 384 When a host retrieves configuration elements using DHCPv6 (e.g., 385 addresses or DNS recursive resolvers), they MUST be associated with 386 the explicit or implicit PvD of the RA received on the same 387 interface, sent from the same LLA, and with the O-flag or M-flag set 388 [RFC4861]. If no such PvD is found, or whenever multiple different 389 PvDs are found, the host behavior is unspecified. 391 This process requires hosts to keep track of received RAs, associated 392 PvD IDs, and routers LLA; it also assumes that the router either acts 393 as a DHCPv6 server or relay and uses the same LLA for DHCPv6 and RA 394 traffic (which may not be the case when the router uses VRRP to send 395 its RA). 397 3.4.2. DHCPv4 configuration association 399 When a host retrieves configuration elements from DHCPv4, they MUST 400 be associated with the explicit PvD received on the same interface, 401 whose PVD Options L-flag is set and, in the case of a non point-to- 402 point link, using the same datalink address. If no such PvD is 403 found, or whenever multiple different PvDs are found, the 404 configuration elements coming from DHCPv4 MUST be associated with the 405 implicit PvD identified by the interface on which the DHCPv4 406 transaction happened. The case of multiple explicit PvD for an IPv4 407 interface is undefined. 409 3.4.3. Connection Sharing by the Host 411 The situation when a host shares connectivity from an upstream 412 interface (e.g. cellular) to a downstream interface (e.g. Wi-Fi) is 413 known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share 414 [RFC7278] or prefix delegation (e.g. using DHCPv6-PD [RFC8415]) may 415 be used for that purpose. 417 Whenever the RAs received from the upstream interface contain a PVD 418 RA option, hosts that are sharing connectivity SHOULD include a PVD 419 Option within the RAs sent downstream with: 421 The same PVD-ID FQDN. 423 The same H-bit, Delay and Sequence Number values. 425 The L bit set whenever the host is sharing IPv4 connectivity 426 received from the same upstream interface. 428 The bits from the Reserved field set to 0. 430 The values of the R-bit, Router Advertisement message header and 431 Options field depend on whether the connectivity should be shared 432 only with PvD-aware hosts or not (see Section 3.2). In particular, 433 all options received within the upstream PvD option and included in 434 the downstream RA SHOULD be included in the downstream PvD option. 436 3.4.4. Usage of DNS Servers 438 PvD-aware hosts can be provisioned with recursive DNS servers via RA 439 options passed within an explicit PvD, via RA options associated with 440 an implicit PvD, via DHCPv6 or DHCPv4, or from some other 441 provisioning mechanism that creates an implicit PvD (such as a VPN). 442 In all of these cases, the DNS server addresses SHOULD be strongly 443 associated with the corresponding PvD. Specificially, queries sent 444 to a configured recursive DNS server SHOULD be sent from a local IP 445 address that belongs to the matching PvD. Answers received from the 446 DNS server SHOULD only be used on the same PvD. 448 Maintaining the correct usage of DNS within PvDs avoids various 449 practical errors, such as: 451 A PvD associated with a VPN or otherwise private network may 452 provide DNS answers that contain addresses inaccessible over 453 another PvD. 455 A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will 456 synthesize IPv6 addresses in DNS answers that are not globally 457 routable, and cannot be used on other PvDs. Conversely, an IPv4 458 address resolved via DNS on another PvD cannot be directly used on 459 a NAT64 network without the host synthesizing an IPv6 address. 461 4. Provisioning Domain Additional Information 463 Additional information about the network characteristics can be 464 retrieved based on the PvD ID. This set of information is called PvD 465 Additional Information, and is encoded as a JSON object [RFC7159]. 467 The purpose of this additional set of information is to securely 468 provide additional information to applications about the connectivity 469 that is provided using a given interface and source address pair. It 470 typically includes data that would be considered too large, or not 471 critical enough, to be provided within an RA option. The information 472 contained in this object MAY be used by the operating system, network 473 libraries, applications, or users, in order to decide which set of 474 PvDs should be used for which connection, as described in 475 Section 3.4. 477 4.1. Retrieving the PvD Additional Information 479 When the H-flag of the PvD Option is set, hosts MAY attempt to 480 retrieve the PvD Additional Information associated with a given PvD 481 by performing an HTTP over TLS [RFC2818] GET query to https:///.well-known/pvd [RFC5785]. Inversely, hosts MUST NOT do so 483 whenever the H-flag is not set. 485 HTTP requests and responses for PvD additional information use the 486 "application/pvd+json" media type (see Section 8). Clients SHOULD 487 include this media type as an Accept header in their GET requests, 488 and servers MUST mark this media type as their Content-Type header in 489 responses. 491 Note that the DNS name resolution of the PvD ID, the PKI checks as 492 well as the actual query MUST be performed using the considered PvD. 493 In other words, the name resolution, PKI checks, source address 494 selection, as well as the next-hop router selection MUST be performed 495 while using exclusively the set of configuration information attached 496 with the PvD, as defined in Section 3.4. In some cases, it may 497 therefore be necessary to wait for an address to be available for use 498 (e.g., once the Duplicate Address Detection or DHCPv6 processes are 499 complete) before initiating the HTTP over TLS query. If the host has 500 a temporary address per [RFC4941] in this PvD, then hosts SHOULD use 501 a temporary address to fetch the PvD Additional Information and 502 SHOULD deprecate the used temporary address and generate a new 503 temporary address afterward. 505 If the HTTP status of the answer is greater than or equal to 400 the 506 host MUST abandon and consider that there is no additional PvD 507 information. If the HTTP status of the answer is between 300 and 508 399, inclusive, it MUST follow the redirection(s). If the HTTP 509 status of the answer is between 200 and 299, inclusive, the host MAY 510 get a file containing a single JSON object. When a JSON object could 511 not be retrieved, an error message SHOULD be logged and/or displayed 512 in a rate-limited fashion. 514 After retrieval of the PvD Additional Information, hosts MUST keep 515 track of the Sequence Number value received in subsequent RAs 516 including the same PvD ID. In case the new value is greater than the 517 value that was observed when the PvD Additional Information object 518 was retrieved (using serial number arithmetic comparisons [RFC1982]), 519 or whenever the validity time included in the PVD Additional 520 Information JSON object is expired, hosts MUST either perform a new 521 query and retrieve a new version of the object, or, failing that, 522 deprecate the object and stop using the additional information 523 provided in the JSON object. 525 Hosts retrieving a new PvD Additional Information object MUST check 526 for the presence and validity of the mandatory fields specified in 527 Section 4.3. A retrieved object including an expiration time that is 528 already past or missing a mandatory element MUST be ignored. 530 In order to avoid synchronized queries toward the server hosting the 531 PvD Additional Information when an object expires, object updates are 532 delayed by a randomized backoff time. 534 When a host performs an object update after it detected a change 535 in the PvD Option Sequence number, it MUST delay the query by a 536 random time between zero and 2**(Delay * 2) milliseconds, where 537 'Delay' corresponds to the 4 bits long unsigned integer in the 538 last received PvD Option. 540 When a host last retrieved an object at time A including a 541 validity time B, and is configured to keep the object up to date, 542 it MUST perform the update at a uniformly random time in the 543 interval [(B-A)/2,B]. 545 In the example Figure 2, the delay field value is 5, this means that 546 host MUST delay the query by a random number between 0 and 2**(5 * 2) 547 milliseconds, i.e., between 0 and 1024 milliseconds. 549 Since the 'Delay' value is directly within the PvD Option rather than 550 the object itself, an operator may perform a push-based update by 551 incrementing the Sequence value while changing the Delay value 552 depending on the criticality of the update and its PvD Additional 553 Information servers capacity. 555 The PvD Additional Information object includes a set of IPv6 prefixes 556 (under the key "prefixes") which MUST be checked against all the 557 Prefix Information Options advertised in the RA. If any of the 558 prefixes included in the PIO is not covered by at least one of the 559 listed prefixes, the PvD associated with the tested prefix MUST be 560 considered unsafe and MUST NOT be used. While this does not prevent 561 a malicious network provider, it does complicate some attack 562 scenarios, and may help detecting misconfiguration. 564 4.2. Operational Consideration to Providing the PvD Additional 565 Information 567 Whenever the H-flag is set in the PvD Option, a valid PvD Additional 568 Information object MUST be made available to all hosts receiving the 569 RA by the network operator. In particular, when a captive portal is 570 present, hosts MUST still be allowed to perform DNS, PKI and HTTP 571 over TLS operations related to the retrieval of the object, even 572 before logging into the captive portal. 574 Routers MAY increment the PVD Option Sequence number in order to 575 inform host that a new PvD Additional Information object is available 576 and should be retrieved. 578 The server providing the JSON files SHOULD also check whether the 579 client address is part of the prefixes listed into the additional 580 information and SHOULD return a 403 response code if there is no 581 match. 583 4.3. PvD Additional Information Format 585 The PvD Additional Information is a JSON object. 587 The following table presents the mandatory keys which MUST be 588 included in the object: 590 +----------+-----------------+-------------+------------------------+ 591 | JSON key | Description | Type | Example | 592 +----------+-----------------+-------------+------------------------+ 593 | name | Human-readable | UTF-8 | "Awesome Wi-Fi" | 594 | | service name | string | | 595 | | | [RFC3629] | | 596 | expires | Date after | [RFC3339] | "2017-07-23T06:00:00Z" | 597 | | which this | | | 598 | | object is not | | | 599 | | valid | | | 600 | prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", | 601 | | prefixes valid | strings | "2001:db8:4::/48"] | 602 | | for this PVD | | | 603 +----------+-----------------+-------------+------------------------+ 604 A retrieved object which does not include a valid string associated 605 with the "name" key at the root of the object, or a valid date 606 associated with the "expires" key, also at the root of the object, 607 MUST be ignored. In such cases, an error message SHOULD be logged 608 and/or displayed in a rate-limited fashion. If the PIO of the 609 received RA is not covered by at least one of the "prefixes" key, the 610 retrieved object SHOULD be ignored. 612 The following table presents some optional keys which MAY be included 613 in the object. 615 +---------------+-----------------+---------+-----------------------+ 616 | JSON key | Description | Type | Example | 617 +---------------+-----------------+---------+-----------------------+ 618 | localizedName | Localized user- | UTF-8 | "Wi-Fi Genial" | 619 | | visible service | string | | 620 | | name, language | | | 621 | | can be selected | | | 622 | | based on the | | | 623 | | HTTP Accept- | | | 624 | | Language header | | | 625 | | in the request. | | | 626 | dnsZones | DNS zones | array | ["example.com","sub.e | 627 | | searchable and | of DNS | xample.org"] | 628 | | accessible | zones | | 629 | noInternet | No Internet, | boolean | true | 630 | | set when the | | | 631 | | PvD only | | | 632 | | provides | | | 633 | | restricted | | | 634 | | access to a set | | | 635 | | of services | | | 636 +---------------+-----------------+---------+-----------------------+ 638 It is worth noting that the JSON format allows for extensions. 639 Whenever an unknown key is encountered, it MUST be ignored along with 640 its associated elements. 642 Private-use or experimental keys MAY be used in the JSON dictionary. 643 In order to avoid such keys colliding with IANA registry keys, 644 implementers or vendors defining private-use or experimental keys 645 MUST create sub-dictionaries, where the sub-dictionary is added into 646 the top-level JSON dictionary with a key of the format "vendor-*" 647 where the "*" is replaced by the implementers or vendors 648 denomination. Upon receiving such a sub-dictionary, host MUST ignore 649 this sub-dictionary if it is unknown. When the vendor or implementor 650 is part of an IANA URN namespace [URN], the URN namespace SHOULD be 651 used rather than the "vendor-*" format. 653 4.3.1. Example 655 The following examples show how the JSON keys defined in this 656 document can be used: 658 { 659 "name": "Foo Wireless", 660 "localizedName": "Foo-France Wi-Fi", 661 "expires": "2017-07-23T06:00:00Z", 662 "prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"], 663 } 665 { 666 "name": "Bar 4G", 667 "localizedName": "Bar US 4G", 668 "expires": "2017-07-23T06:00:00Z", 669 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 670 } 672 { 673 "name": "Company Network", 674 "localizedName": "Company Network", 675 "expires": "2017-07-23T06:00:00Z", 676 "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], 677 "vendor-foo": { "private-key": "private-value" }, 678 } 680 4.4. Detecting misconfiguration and misuse 682 When a host retrieves the PvD Additional Information, it MUST verify 683 that the TLS server certificate is valid for the performed request 684 (e.g., that the Subject Name is equal to the PvD ID expressed as an 685 FQDN). This authentication creates a secure binding between the 686 information provided by the trusted Router Advertisement, and the 687 HTTPS server. However, this does not mean the Advertising Router and 688 the PvD server belong to the same entity. 690 Hosts MUST verify that all prefixes in the RA PIO are covered by a 691 prefix from the PvD Additional Information. An adversarial router 692 willing to fake the use of a given explicit PvD, without any access 693 to the actual PvD Additional Information, would need to perform NAT66 694 in order to circumvent this check. 696 It is also RECOMMENDED that the HTTPS server checks the IPv6 source 697 addresses of incoming connections (see Section 4.1). This check give 698 reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used 699 and restricts the information to the valid network users. 701 Note that this check cannot be performed when the HTTPS query is 702 performed over IPv4. Therefore, the PvD ID FQDN SHOULD NOT have a 703 DNS A record whenever all hosts using the given PvD have IPv6 704 connectivity. 706 5. Operational Considerations 708 This section describes some use cases of PvD. For the sake of 709 simplicity, the RA messages will not be described in the usual ASCII 710 art but rather in an indented list. For example, a RA message 711 containing some options and a PvD option that also contains other 712 options will be described as: 714 o RA Header: router lifetime = 6000 716 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 718 o PvD Option header: length = 3 + 5 + 4 , PvD ID FQDN = 719 example.org., R-flag = 0 (actual length of the header with padding 720 24 bytes = 3 * 8 bytes) 722 * Recursive DNS Server: length = 5, addresses= 723 [2001:db8:cafe::53, 2001:db8:f00d::53] 725 * Prefix Information Option: length = 4, prefix = 726 2001:db8:f00d::/64 728 It is expected that for some years, networks will have a mixed 729 environment of PvD-aware hosts and non-PvD-aware hosts. If there is 730 a need to give specific information to PvD-aware hosts only, then it 731 is recommended to send TWO RA messages: one for each class of hosts. 732 For example, here is the RA for non-PvD-aware hosts: 734 o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use 735 this router as a default router) 737 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 739 o Recursive DNS Server Option: length = 3, addresses= 740 [2001:db8:cafe::53] 742 o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org., 743 R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes) 745 * RA Header: router lifetime = 0 (PvD-aware hosts will not use 746 this router as a default router), implicit length = 2 748 And here is a RA example for PvD-aware hosts: 750 o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use 751 this router as a default router) 753 o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = 754 example.org., R-flag = 1 (actual length of the header 24 bytes = 3 755 * 8 bytes) 757 * RA Header: router lifetime = 1600 (PvD-aware hosts will use 758 this router as a default router), implicit length = 2 760 * Prefix Information Option: length = 4, prefix = 761 2001:db8:f00d::/64 763 * Recursive DNS Server Option: length = 3, addresses= 764 [2001:db8:f00d::53] 766 In the above example, non-PvD-aware hosts will only use the first RA 767 sent from their default router and using the 2001:db8:cafe::/64 768 prefix. PvD-aware hosts will autonomously configure addresses from 769 both PIOs, but will only use the source address in 2001:db8:f00d::/64 770 to communicate past the first hop router since only the router 771 sending the second RA will be used as default router; similarly, they 772 will use the DNS server 2001:db8:f00d::53 when communicating with 773 this adress. 775 6. Security Considerations 777 Although some solutions such as IPsec or SeND [RFC3971] can be used 778 in order to secure the IPv6 Neighbor Discovery Protocol, in practice 779 actual deployments largely rely on link layer or physical layer 780 security mechanisms (e.g. 802.1x [IEEE8021X]) in conjunction with RA 781 Guard [RFC6105]. 783 This specification does not improve the Neighbor Discovery Protocol 784 security model, but extends the purely link-local trust relationship 785 between the host and the default routers with HTTP over TLS 786 communications which servers are authenticated as rightful owners of 787 the FQDN received within the trusted PvD ID RA option. 789 It must be noted that Section 4.4 of this document only provides 790 reasonable assurance against misconfiguration but does not prevent an 791 hostile network access provider to advertize wrong information that 792 could lead applications or hosts to select an hostile PvD. Users 793 should always apply caution when connecting to an unknown network. 795 7. Privacy Considerations 797 Retrieval of the PvD Additional Information over HTTPS requires early 798 communications between the connecting host and a server which may be 799 located further than the first hop router. Although this server is 800 likely to be located within the same administrative domain as the 801 default router, this property can't be ensured. Therefore, hosts 802 willing to retrieve the PvD Additional Information before using it 803 without leaking identity information, SHOULD make use of an IPv6 804 Privacy Address and SHOULD NOT include any privacy sensitive data, 805 such as User Agent header or HTTP cookie, while performing the HTTP 806 over TLS query. 808 From a privacy perspective, retrieving the PvD Additional Information 809 is not different from establishing a first connection to a remote 810 server, or even performing a single DNS lookup. For example, most 811 operating systems already perform early queries to well known web 812 sites, such as http://captive.example.com/hotspot-detect.html, in 813 order to detect the presence of a captive portal. 815 There may be some cases where hosts, for privacy reasons, should 816 refrain from accessing servers that are located outside a certain 817 network boundary. In practice, this could be implemented as a 818 whitelist of 'trusted' FQDNs and/or IP prefixes that the host is 819 allowed to communicate with. In such scenarios, the host SHOULD 820 check that the provided PvD ID, as well as the IP address that it 821 resolves into, are part of the allowed whitelist. 823 8. IANA Considerations 825 Upon publication of this document, IANA is asked to remove the 826 'reclaimable' tag off the value 21 for the PvD option (from the IPv6 827 Neighbor Discovery Option Formats registry). 829 IANA is asked to assign the value "pvd" from the Well-Known URIs 830 registry. 832 8.1. Additional Information PvD Keys Registry 834 IANA is asked to create and maintain a new registry called 835 "Additional Information PvD Keys", which will reserve JSON keys for 836 use in PvD additional information. The initial contents of this 837 registry are given in Section 4.3. 839 New assignments for Additional Information PvD Keys Registry will be 840 administered by IANA through Expert Review RFC8126 [RFC8126]. 842 8.2. PvD Option Flags Registry 844 IANA is also asked to create and maintain a new registry entitled 845 "PvD Option Flags" reserving bit positions from 0 to 15 to be used in 846 the PvD option bitmask. Bit position 0, 1 and 2 are reserved by this 847 document (as specified in Figure 1). Future assignments require 848 Standards Action RFC8126 [RFC8126], via a Standards Track RFC 849 document. 851 8.3. PvD JSON Media Type Registration 853 This document registers the media type for PvD JSON text, 854 "application/pvd+json". 856 Type Name: application 858 Subtype Name: pvd+json 860 Required parameters: None 862 Optional parameters: None 864 Encoding considerations: Encoding considerations are identical to 865 those specified for the "application/json" media type. 867 Security considerations: See Section 6. 869 Interoperability considerations: This document specifies format of 870 conforming messages and the interpretation thereof. 872 Published specification: This document 874 Applications that use this media type: This media type is intended to 875 be used by network advertising additional Provisioning Domain 876 information, and clients looking up such information. 878 Additional information: None 880 Person and email address to contact for further information: See 881 Authors' Addresses section 883 Intended usage: COMMON 885 Restrictions on usage: None 887 Author: IETF 889 Change controller: IETF 891 9. Acknowledgements 893 Many thanks to M. Stenberg and S. Barth for their earlier work: 894 [I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was 895 author of an early version of this document. 897 Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen 898 Cao, Tim Chow, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer, 899 Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted 900 Lemon, Jen Lenkova, Veronika McKillop, Mark Townsley and James 901 Woodyatt for useful and interesting discussions and reviews. 903 Finally, special thanks to Thierry Danis and Wenqin Shao for their 904 valuable inputs and implementation efforts ([github]), Tom Jones for 905 his integration effort into the NEAT project and Rigil Salim for his 906 implementation work. 908 10. References 910 10.1. Normative references 912 [RFC1035] Mockapetris, P., "Domain names - implementation and 913 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 914 November 1987, . 916 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 917 DOI 10.17487/RFC1982, August 1996, 918 . 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, 922 DOI 10.17487/RFC2119, March 1997, 923 . 925 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 926 Discovery for IP Version 6 (IPv6)", RFC 2461, 927 DOI 10.17487/RFC2461, December 1998, 928 . 930 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 931 DOI 10.17487/RFC2818, May 2000, 932 . 934 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 935 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 936 2003, . 938 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 939 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 940 DOI 10.17487/RFC4861, September 2007, 941 . 943 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 944 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 945 2014, . 947 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 948 Writing an IANA Considerations Section in RFCs", BCP 26, 949 RFC 8126, DOI 10.17487/RFC8126, June 2017, 950 . 952 10.2. Informative references 954 [github] Cisco, "IPv6-mPvD github repository", 955 . 957 [I-D.kline-mif-mpvd-api-reqs] 958 Kline, E., "Multiple Provisioning Domains API 959 Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in 960 progress), November 2015. 962 [I-D.stenberg-mif-mpvd-dns] 963 Stenberg, M. and S. Barth, "Multiple Provisioning Domains 964 using Domain Name System", draft-stenberg-mif-mpvd-dns-00 965 (work in progress), October 2015. 967 [IEEE8021X] 968 IEEE, "IEEE Standards for Local and Metropolitan Area 969 Networks: Port based Network Access Control, IEEE Std". 971 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 972 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 973 . 975 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 976 "SEcure Neighbor Discovery (SEND)", RFC 3971, 977 DOI 10.17487/RFC3971, March 2005, 978 . 980 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 981 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 982 November 2005, . 984 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 985 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 986 2006, . 988 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 989 Extensions for Stateless Address Autoconfiguration in 990 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 991 . 993 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 994 Uniform Resource Identifiers (URIs)", RFC 5785, 995 DOI 10.17487/RFC5785, April 2010, 996 . 998 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 999 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1000 DOI 10.17487/RFC6105, February 2011, 1001 . 1003 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1004 NAT64: Network Address and Protocol Translation from IPv6 1005 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1006 April 2011, . 1008 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1009 Beijnum, "DNS64: DNS Extensions for Network Address 1010 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1011 DOI 10.17487/RFC6147, April 2011, 1012 . 1014 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1015 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1016 . 1018 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1019 "Default Address Selection for Internet Protocol Version 6 1020 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1021 . 1023 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 1024 /64 Prefix from a Third Generation Partnership Project 1025 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 1026 DOI 10.17487/RFC7278, June 2014, 1027 . 1029 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 1030 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 1031 . 1033 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 1034 Hosts in a Multi-Prefix Network", RFC 8028, 1035 DOI 10.17487/RFC8028, November 2016, 1036 . 1038 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1039 "IPv6 Router Advertisement Options for DNS Configuration", 1040 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1041 . 1043 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1044 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1045 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1046 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1047 . 1049 [URN] IANA, "URN Namespaces", . 1052 Appendix A. Changelog 1054 Note to RFC Editors: Remove this section before publication. 1056 A.1. Version 00 1058 Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke 1059 and based on Basile's work. 1061 A.2. Version 01 1063 Major rewrite intended to focus on the the retained solution based on 1064 corridors, online, and WG discussions. Edited by Pierre Pfister. 1065 The following list only includes major changes. 1067 PvD ID is an FQDN retrieved using a single RA option. This option 1068 contains a sequence number for push-based updates, a new H-flag, 1069 and a L-flag in order to link the PvD with the IPv4 DHCP server. 1071 A lifetime is included in the PvD ID option. 1073 Detailed Hosts and Routers specifications. 1075 Additional Information is retrieved using HTTP-over-TLS when the 1076 PvD ID Option H-flag is set. Retrieving the object is optional. 1078 The PvD Additional Information object includes a validity date. 1080 DNS-based approach is removed as well as the DNS-based encoding of 1081 the PvD Additional Information. 1083 Major cut in the list of proposed JSON keys. This document may be 1084 extended later if need be. 1086 Monetary discussion is moved to the appendix. 1088 Clarification about the 'prefixes' contained in the additional 1089 information. 1091 Clarification about the processing of DHCPv6. 1093 A.3. Version 02 1095 The FQDN is now encoded with ASCII format (instead of DNS binary) 1096 in the RA option. 1098 The PvD ID option lifetime is removed from the object. 1100 Use well known URI "https:///.well-known/pvd" 1102 Reference RFC3339 for JSON timestamp format. 1104 The PvD ID Sequence field has been extended to 16 bits. 1106 Modified host behavior for DHCPv4 and DHCPv6. 1108 Removed IKEv2 section. 1110 Removed mention of RFC7710 Captive Portal option. A new I.D. 1111 will be proposed to address the captive portal use case. 1113 A.4. WG Document version 00 1115 Document has been accepted as INTAREA working group document 1117 IANA considerations follow RFC8126 [RFC8126] 1119 PvD ID FQDN is encoded as per RFC 1035 [RFC1035] 1121 PvD ID FQDN is prepended by a one-byte length field 1123 Marcus Keane added as co-author 1125 dnsZones key is added back 1126 draft of a privacy consideration section and added that a 1127 temporary address should be used to retrieve the PvD additional 1128 information 1130 per Bob Hinden's request: the document is now aiming at standard 1131 track and security considerations have been moved to the main 1132 section 1134 A.5. WG Document version 01 1136 Removing references to 'metered' and 'characteristics' keys. 1137 Those may be in scope of the PvD work, but this document will 1138 focus on essential parts only. 1140 Removing appendix section regarding link quality and billing 1141 information. 1143 The PvD RA Option may now contain other RA options such that PvD- 1144 aware hosts may receive configuration information otherwise 1145 invisible to non-PvD-aware hosts. 1147 Clarify that the additional PvD Additional Information is not 1148 intended to modify host's networking stack behavior, but rather 1149 provide information to the Application, used to select which PvDs 1150 must be used and provide configuration parameters to the transport 1151 layer. 1153 The RA option padding is used to increase the option size to the 1154 next 64 (was 32) bits boundary. 1156 Better detail the Security model and Privacy considerations. 1158 A.6. WG Document version 02 1160 Use the IANA value of 21 in the text and update the IANA 1161 considerations section accordingly 1163 add the Delay field to avoid the thundering herd effect 1165 add Wenqin Shao as author 1167 keep the 1 PvD per RA model 1169 changed the intro (per Zhen Cao) "when choosing which PvD and 1170 transport should be used" => "when choosing which PvD should be 1171 used" 1173 rename A-flag in R-flag to avoid A-flag of PIO 1174 use the wording "PvD Option", removing the ID token as it is now a 1175 container with more then just an ID, removing 'RA' in the option 1176 name to be consistent with other IANA NDP option 1178 use "non-PvD-aware" rather than "PvD-ignorant" 1180 added more reference to RFC 7556 (notably for PvD being globally 1181 unique, introducing PvD-aware host vs. PvD-aware node) 1183 Section 3.4.3 renamed from "interconnection shared by node" to 1184 'connection shared by node" 1186 Section 3.4 renamed into "PvD-aware Host Behavior" 1188 Added a section "Non-PvD-aware Host Behavior" 1190 A.7. WG Document version 04 1192 Updated reference for DHCPv6-PD from RFC 3633 to RFC 8415. 1194 Enhanced IANA considerations to clarify review process and new 1195 registries. 1197 Added a section on considerations for handling DNS on a PvD-aware 1198 host. 1200 A.7.1. WG Document version 05 1202 Fixed nits about IPSEC and WiFi 1204 Added use case per Phillip Hallam-Baker 1206 Clarified some sentences 1208 Authors' Addresses 1210 Pierre Pfister 1211 Cisco 1212 11 Rue Camille Desmoulins 1213 Issy-les-Moulineaux 92130 1214 France 1216 Email: ppfister@cisco.com 1217 Eric Vyncke (editor) 1218 Cisco 1219 De Kleetlaan, 6 1220 Diegem 1831 1221 Belgium 1223 Email: evyncke@cisco.com 1225 Tommy Pauly 1226 Apple 1227 One Apple Park Way 1228 Cupertino, California 95014 1229 USA 1231 Email: tpauly@apple.com 1233 David Schinazi 1234 Google LLC 1235 1600 Amphitheatre Parkway 1236 Mountain View, California 94043 1237 USA 1239 Email: dschinazi.ietf@gmail.com 1241 Wenqin Shao 1242 Cisco 1243 11 Rue Camille Desmoulins 1244 Issy-les-Moulineaux 92130 1245 France 1247 Email: wenshao@cisco.com