| < draft-ietf-intarea-provisioning-domains-04.txt | draft-ietf-intarea-provisioning-domains-11.txt > | |||
|---|---|---|---|---|
| intarea P. Pfister | Network Working Group P. Pfister | |||
| Internet-Draft E. Vyncke, Ed. | Internet-Draft E. Vyncke | |||
| Intended status: Standards Track Cisco | Intended status: Standards Track Cisco | |||
| Expires: September 9, 2019 T. Pauly | Expires: August 3, 2020 T. Pauly | |||
| Apple | Apple Inc. | |||
| D. Schinazi | D. Schinazi | |||
| Google LLC | Google LLC | |||
| W. Shao | W. Shao | |||
| Cisco | Cisco | |||
| March 8, 2019 | January 31, 2020 | |||
| Discovering Provisioning Domain Names and Data | Discovering Provisioning Domain Names and Data | |||
| draft-ietf-intarea-provisioning-domains-04 | draft-ietf-intarea-provisioning-domains-11 | |||
| Abstract | Abstract | |||
| An increasing number of hosts access the Internet via multiple | Provisioning Domains (PvDs) are defined as consistent sets of network | |||
| interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix | configuration information. This allows hosts to manage connections | |||
| configurations context. | to multiple networks and interfaces simultaneously, such as when a | |||
| home router provides connectivity through both a broadband and | ||||
| This document describes a way for hosts to identify such contexts, | cellular network provider. | |||
| called Provisioning Domains (PvDs), where Fully Qualified Domain | ||||
| Names (FQDNs) act as PvD identifiers. Those identifiers are | ||||
| advertised in a new Router Advertisement (RA) option and, when | ||||
| present, are associated with the set of information included within | ||||
| the RA. | ||||
| Based on this FQDN, hosts can retrieve additional information about | This document defines a mechanism for explicitly identifying PvDs | |||
| their network access characteristics via an HTTP over TLS query. | through a Router Advertisement (RA) option. This RA option announces | |||
| This allows applications to select which Provisioning Domains to use | a PvD identifier, which hosts can compare to differentiate between | |||
| as well as to provide configuration parameters to the transport layer | PvDs. The option can directly carry some information about a PvD and | |||
| and above. | can optionally point to additional PvD information that can be | |||
| retrieved using HTTP over TLS. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on September 9, 2019. | ||||
| This Internet-Draft will expire on August 3, 2020. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 | ||||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Provisioning Domain Identification using Router | 3. Provisioning Domain Identification using Router | |||
| Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4 | Advertisements . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 4 | 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 5 | |||
| 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 8 | 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 9 | |||
| 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 8 | 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 9 | |||
| 3.4.1. DHCPv6 configuration association . . . . . . . . . . 9 | 3.4.1. DHCPv6 configuration association . . . . . . . . . . 10 | |||
| 3.4.2. DHCPv4 configuration association . . . . . . . . . . 9 | 3.4.2. DHCPv4 configuration association . . . . . . . . . . 11 | |||
| 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 9 | 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 11 | |||
| 3.4.4. Usage of DNS Servers . . . . . . . . . . . . . . . . 10 | 3.4.4. Usage of DNS Servers . . . . . . . . . . . . . . . . 12 | |||
| 4. Provisioning Domain Additional Information . . . . . . . . . 11 | 4. Provisioning Domain Additional Information . . . . . . . . . 13 | |||
| 4.1. Retrieving the PvD Additional Information . . . . . . . . 11 | 4.1. Retrieving the PvD Additional Information . . . . . . . . 13 | |||
| 4.2. Operational Consideration to Providing the PvD Additional | 4.2. Operational Consideration to Providing the PvD Additional | |||
| Information . . . . . . . . . . . . . . . . . . . . . . . 13 | Information . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 4.3. PvD Additional Information Format . . . . . . . . . . . . 13 | 4.3. PvD Additional Information Format . . . . . . . . . . . . 16 | |||
| 4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 14 | 4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 14 | 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 18 | |||
| 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 15 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 | |||
| 5. Operational Considerations . . . . . . . . . . . . . . . . . 15 | 5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 19 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts . . . 19 | |||
| 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 | 5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 21 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | 5.4. Providing Additional Information to PvD-Aware Hosts . . . 22 | |||
| 8.1. Additional Information PvD Keys Registry . . . . . . . . 18 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
| 8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 18 | 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
| 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 8.1. New entry in the Well-Known URIs Registry . . . . . . . . 26 | |||
| 10.1. Normative references . . . . . . . . . . . . . . . . . . 19 | 8.2. Additional Information PvD Keys Registry . . . . . . . . 26 | |||
| 10.2. Informative references . . . . . . . . . . . . . . . . . 20 | 8.3. PvD Option Flags Registry . . . . . . . . . . . . . . . . 26 | |||
| Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 22 | 8.4. PvD JSON Media Type Registration . . . . . . . . . . . . 27 | |||
| A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 22 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 22 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 23 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 | |||
| A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 23 | 10.2. Informative References . . . . . . . . . . . . . . . . . 30 | |||
| A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 24 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 24 | ||||
| A.7. WG Document version 04 . . . . . . . . . . . . . . . . . 25 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
| 1. Introduction | 1. Introduction | |||
| It has become very common in modern networks for hosts to access the | Provisioning Domains (PvDs) are defined in [RFC7556] as consistent | |||
| internet through different network interfaces, tunnels, or next-hop | sets of network configuration information. This information includes | |||
| routers. To describe the set of network configurations associated | properties that are traditionally associated with a single networking | |||
| with each access method, the concept of Provisioning Domain (PvD) was | interface, such as source addresses, DNS configuration, proxy | |||
| defined in [RFC7556]. | configuration, and gateway addresses. | |||
| Clients that are aware of PvDs can take advantage of multiple network | ||||
| interfaces simultaneously. This enables using two PvDs in parallel | ||||
| for separate connections or for multi-path transports. | ||||
| While most PvDs today are discovered implicitly (such as by receiving | ||||
| information via Router Advertisements from a router on a network that | ||||
| a client host directly connects to), [RFC7556] also defines the | ||||
| notion of Explicit PvDs. IPsec Virtual Private Networks are | ||||
| considered Explicit PvDs, but Explicit PvDs can also be discovered | ||||
| via the local network router. Discovering Explicit PvDs allows two | ||||
| key advancements in managing multiple PvDs: | ||||
| 1. The ability to discover and use multiple PvDs on a single | ||||
| interface, such as when a local router can provide connectivity | ||||
| to two different Internet Service Providers. | ||||
| 2. The ability to associate additional information about PvDs to | ||||
| describe the properties of the network. | ||||
| While [RFC7556] defines the concept of Explicit PvDs, it does not | ||||
| define the mechanism for discovering multiple Explicit PvDs on a | ||||
| single network and their additional information. | ||||
| This document specifies a way to identify PvDs with Fully Qualified | This document specifies a way to identify PvDs with Fully Qualified | |||
| Domain Names (FQDN), called PvD IDs. Those identifiers are | Domain Names (FQDN), called PvD IDs. Those identifiers are | |||
| advertised in a new Router Advertisement (RA) [RFC4861] option called | advertised in a new Router Advertisement (RA) [RFC4861] option called | |||
| the PvD ID Router Advertisement option which, when present, | the PvD ID Router Advertisement option which, when present, | |||
| associates the PvD ID with all the information present in the Router | associates the PvD ID with all the information present in the Router | |||
| Advertisement as well as any configuration object, such as addresses, | Advertisement as well as any configuration object, such as addresses, | |||
| deriving from it. The PVD ID Router Advertisement option may also | derived from it. The PVD ID Router Advertisement option may also | |||
| contain a set of other RA options. Since such options are only | contain a set of other RA options, along with an optional inner | |||
| considered by hosts implementing this specification, network | Router Advertisement message header. These options and optional | |||
| operators may configure hosts that are 'PvD-aware' with PvDs that are | inner header are only visible to 'PvD-aware' hosts, allowing such | |||
| ignored by other hosts. | hosts to have a specialized view of the network configuration. | |||
| Since PvD IDs are used to identify different ways to access the | Since PvD IDs are used to identify different ways to access the | |||
| internet, multiple PvDs (with different PvD IDs) could be provisioned | internet, multiple PvDs (with different PvD IDs) can be provisioned | |||
| on a single host interface. Similarly, the same PvD ID could be used | on a single host interface. Similarly, the same PvD ID could be used | |||
| on different interfaces of a host in order to inform that those PvDs | on different interfaces of a host in order to inform that those PvDs | |||
| ultimately provide identical services. | ultimately provide equivalent services. | |||
| This document also introduces a way for hosts to retrieve additional | This document also introduces a mechanism for hosts to retrieve | |||
| information related to a specific PvD by means of an HTTP over TLS | optional additional information related to a specific PvD by means of | |||
| query using an URI derived from the PvD ID. The retrieved JSON | an HTTP over TLS query using a URI derived from the PvD ID. The | |||
| object contains additional information that would typically be | retrieved JSON object contains additional information that would | |||
| considered unfit, or too large, to be directly included in the Router | typically be considered too large to be directly included in the | |||
| Advertisement, but might be considered useful to the applications, or | Router Advertisement, but might be considered useful to the | |||
| even sometimes users, when choosing which PvD should be used. | applications, or even sometimes users, when choosing which PvD should | |||
| be used. | ||||
| 2. Terminology | For example, if Alice has both a cellular network provider and a | |||
| broadband provider in her home, her PvD-aware devices and | ||||
| applications would be aware of both available uplinks. These | ||||
| applications could fail-over between these networks, or run | ||||
| connections over both (potentially using multi-path transports). | ||||
| Applications could also select specific uplinks based on the | ||||
| properties of the network; for example, if the cellular network | ||||
| provides free high-quality video streaming, a video-streaming | ||||
| application could select that network while most of the other traffic | ||||
| on Alice's device uses the broadband provider. | ||||
| 1.1. Specification of Requirements | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| [RFC2119]. | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | ||||
| In addition, this document uses the following terminology: | 2. Terminology | |||
| Provisioning Domain (PvD): A set of network configuration | This document uses the following terminology: | |||
| Provisioning Domain (PvD): A set of network configuration | ||||
| information; for more information, see [RFC7556]. | information; for more information, see [RFC7556]. | |||
| PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a | PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a PvD. | |||
| PvD. | ||||
| Explicit PvD: A PvD uniquely identified with a PvD ID. For more | Explicit PvD: A PvD uniquely identified with a PvD ID. For more | |||
| information, see [RFC7556]. | information, see [RFC7556]. | |||
| Implicit PvD: A PvD that, in the absence of a PvD ID, is identified | Implicit PvD: A PvD that, in the absence of a PvD ID, is identified | |||
| by the host interface to which it is attached and the address of | by the host interface to which it is attached and the address of | |||
| the advertising router. See also [RFC7556]. | the advertising router. See also [RFC7556]. | |||
| PvD-aware host A host that supports the association of network | PvD-aware host: A host that supports the association of network | |||
| configuration information into PvDs and the use of these PvDs. | configuration information into PvDs and the use of these PvDs as | |||
| Also named PvD-aware node in [RFC7556]. | described in this document. Also named PvD-aware node in | |||
| [RFC7556]. | ||||
| 3. Provisioning Domain Identification using Router Advertisements | 3. Provisioning Domain Identification using Router Advertisements | |||
| Explicit PvDs are identified by a PvD ID. The PvD ID is a Fully | Explicit PvDs are identified by a PvD ID. The PvD ID is a Fully | |||
| Qualified Domain Name (FQDN) which MUST belong to the network | Qualified Domain Name (FQDN) that identifies the network operator. | |||
| operator in order to avoid naming collisions. The same PvD ID MAY be | Network operators MUST use names that they own or manage to avoid | |||
| used in several access networks when they ultimately provide | naming conflicts. The same PvD ID MAY be used in several access | |||
| identical services (e.g., in all home networks subscribed to the same | networks when they ultimately provide identical services (e.g., in | |||
| service); else, the PvD ID MUST be different to follow section 2.4 of | all home networks subscribed to the same service); else, the PvD ID | |||
| [RFC7556]. | MUST be different to follow Section 2.4 of [RFC7556]. | |||
| 3.1. PvD ID Option for Router Advertisements | 3.1. PvD ID Option for Router Advertisements | |||
| This document introduces a Router Advertisement (RA) option called | This document introduces a Router Advertisement (RA) option called | |||
| PvD option. It is used to convey the FQDN identifying a given PvD | the PvD Option. It is used to convey the FQDN identifying a given | |||
| (see Figure 1), bind the PvD ID with configuration information | PvD (see Figure 1), bind the PvD ID with configuration information | |||
| received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over | received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over | |||
| TLS to retrieve the PvD Additional Information JSON object (see | TLS to retrieve the PvD Additional Information JSON object (see | |||
| Section 4), as well as contain any other RA options which would | Section 4), as well as contain any other RA options which would | |||
| otherwise be valid in the RA. | otherwise be valid in the RA. | |||
| 0 1 2 3 | 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 | 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 | | | Type | Length |H|L|R| Reserved | Delay | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 5, line 24 ¶ | skipping to change at page 6, line 24 ¶ | |||
| ... | Padding | | ... | Padding | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | ... | | ... | |||
| ... Router Advertisement message header ... | ... Router Advertisement message header ... | |||
| ... (Only present when R-flag is set) ... | ... (Only present when R-flag is set) ... | |||
| ... | | ... | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Options ... | | Options ... | |||
| +-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+- | |||
| Figure 1: PvD ID Router Advertisements Option format | Figure 1: PvD ID Router Advertisements Option Format | |||
| Type : (8 bits) Set to 21. | Type: (8 bits) Set to 21. | |||
| Length : (8 bits) The length of the option in units of 8 | Length: (8 bits) The length of the option in units of 8 octets, | |||
| octets, including the Type and Length fields, the Router | including the Type and Length fields, the Router Advertisement | |||
| Advertisement message header, if any, as well as the RA options | message header, if any, as well as the RA options that are | |||
| that are included within the PvD Option. | included within the PvD Option. | |||
| H-flag : (1 bit) 'HTTP' flag stating whether some PvD | H-flag: (1 bit) 'HTTP' flag stating whether some PvD Additional | |||
| Additional Information is made available through HTTP over TLS, as | Information is made available through HTTP over TLS, as described | |||
| described in Section 4. | in Section 4. | |||
| L-flag : (1 bit) 'Legacy' flag stating whether the router is | L-flag: (1 bit) 'Legacy' flag stating whether the PvD is associated | |||
| also providing IPv4 information using DHCPv4 (see Section 3.4.2). | with IPv4 information assigned using DHCPv4 (see Section 3.4.2). | |||
| R-flag : (1 bit) 'Router Advertisement' flag stating whether | R-flag: (1 bit) 'Router Advertisement' flag stating whether the PvD | |||
| the PvD Option is followed (right after padding to the next 64 | Option header is followed (right after padding to the next 64 bits | |||
| bits boundary) by a Router Advertisement message header (See | boundary) by a Router Advertisement message header (see section | |||
| section 4.2 of [RFC4861]). | 4.2 of [RFC4861]). The usage of the inner message header is | |||
| described in Section 3.4. | ||||
| Delay : (4 bits) Unsigned integer used to delay HTTP GET | Reserved: (13 bits) Reserved for later use. It MUST be set to zero | |||
| queries from hosts by a randomized backoff (see Section 4.1). | by the sender and ignored by the receiver. | |||
| Reserved : (13 bits) Reserved for later use. It MUST be set to | Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from | |||
| zero by the sender and ignored by the receiver. | hosts by a randomized backoff (see Section 4.1). If the H-flag is | |||
| not set, senders SHOULD set the delay to zero, and receivers | ||||
| SHOULD ignore the value. | ||||
| Sequence Number: (16 bits) Sequence number for the PvD Additional | Sequence Number: (16 bits) Sequence number for the PvD Additional | |||
| Information, as described in Section 4. | Information, as described in Section 4. If the H-flag is not set, | |||
| senders SHOULD set the Sequence Number to zero, and receivers | ||||
| SHOULD ignore the value. | ||||
| PvD ID FQDN : The FQDN used as PvD ID encoded in DNS format, as | PvD ID FQDN: The FQDN used as PvD ID encoded in DNS format, as | |||
| described in Section 3.1 of [RFC1035]. Domain names compression | described in Section 3.1 of [RFC1035]. Domain name compression | |||
| described in Section 4.1.4 of [RFC1035] MUST NOT be used. | described in Section 4.1.4 of [RFC1035] MUST NOT be used. | |||
| Padding : Zero or more padding octets to the next 8 octets | Padding: Zero or more padding octets to the next 8 octet boundary | |||
| boundary. It MUST be set to zero by the sender, and ignored by | (see Section 4.6 of [RFC4861]). It MUST be set to zero by the | |||
| the receiver. | sender, and ignored by the receiver. | |||
| RA message header : (16 octets) When the R-flag is set, a full | RA message header: (16 octets) When the R-flag is set, a full Router | |||
| Router Advertisement message header as specified in [RFC4861]. | Advertisement message header as specified in [RFC4861]. The | |||
| The 'Type', 'Code' and 'Checksum' fields (i.e. the first 32 bits), | sender MUST set the 'Type' to 134, the value for "Router | |||
| MUST be set to zero by the sender and ignored by the receiver. | Advertisement", and set the 'Code' to 0. Receivers MUST ignore | |||
| The other fields are to be set and parsed as specified in | both of these fields. The 'Checksum' MUST be set to 0 by the | |||
| [RFC4861] or any updating documents. | sender; non-zero checksums MUST 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 | Options: Zero or more RA options that would otherwise be valid as | |||
| part of the Router Advertisement main body, but are instead | part of the Router Advertisement main body, but are instead | |||
| included in the PvD Option such as to be ignored by hosts that are | included in the PvD Option so as to be ignored by hosts that are | |||
| not 'PvD-aware'. | not PvD-aware. | |||
| Here is an example of a PvD option with example.org as the PvD ID | Figure 2 shows an example of a PvD Option with "example.org" as the | |||
| FQDN and including a RDNSS and prefix information options (it also | PvD ID FQDN and including both a Recursive DNS Server (RDNSS) option | |||
| have the sequence number 123, presence of additional information to | and a prefix information option. It has a Sequence Number of 123, | |||
| be fetched with a delay indicated as 5): | and indicates the presence of additional information that is expected | |||
| to be fetched with a delay factor of 1. | ||||
| 0 1 2 3 | 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 | 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:5| | | Type: 21 | Length: 12 |1|0|0| Reserved |Delay:1| | |||
| +---------------+-------------------------------+---------------+ | +---------------+-------------------------------+---------------+ | |||
| | Seq number: 123 | 7 | e | | | Seq number: 123 | 7 | e | | |||
| +---------------+-----------------------------------------------+ | +---------------+-----------------------------------------------+ | |||
| | x | a | m | p | | | x | a | m | p | | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| | l | e | 3 | o | | | l | e | 3 | o | | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| | r | g | 0 | 0 (padding) | | | r | g | 0 | 0 (padding) | | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| | 0 (padding) | 0 (padding) | 0 (padding) | 0 (padding) | | | 0 (padding) | 0 (padding) | 0 (padding) | 0 (padding) | | |||
| +---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
| | RDNSS option (RFC 6106) length: 5 ... | | RDNSS option (RFC 8106) length: 5 ... | |||
| ... ... | ... ... | |||
| ... | | ... | | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| | Prefix Information Option (RFC 4861) length: 4 ... | | Prefix Information Option (RFC 4861) length: 4 ... | |||
| ... | | ... | | |||
| ... | | ... | | |||
| +---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
| Figure 2 | Figure 2 | |||
| 3.2. Router Behavior | 3.2. Router Behavior | |||
| A router MAY send RAs containing one PvD option, but MUST NOT include | A router MAY send RAs containing one PvD Option, but MUST NOT include | |||
| more than one PvD option in each RA. In particular, the PvD option | more than one PvD Option in each RA. The PvD Option MUST NOT contain | |||
| MUST NOT contain further PvD options. | further PvD Options. | |||
| The PvD Option MAY contain zero, one, or more RA options which would | The PvD Option MAY contain zero, one, or more RA options which would | |||
| otherwise be valid as part of the same RA. Such options are | otherwise be valid as part of the same RA. Such options are | |||
| processed by PvD-aware hosts, while ignored by others. | processed by PvD-aware hosts, while ignored by other hosts as per | |||
| section 4.2 of [RFC4861]. | ||||
| In order to provide multiple different PvDs, a router MUST send | In order to provide multiple different PvDs, a router MUST send | |||
| multiple RAs. Different explicit PvDs MAY be advertised with RAs | multiple RAs. RAs sent from different link-local source addresses | |||
| using the same IPv6 source address; but different implicit PvDs, | establish distinct implicit PvDs, in the absence of a PvD Option. | |||
| advertised by different RAs, MUST use different link-local addresses | Explicit PvDs MAY share link-local source addresses with an Implicit | |||
| because these implicit PvDs are identified by the source addresses of | PvD and any number of other Explicit PvDs. | |||
| the RAs. | ||||
| As specified in [RFC4861], when the set of options causes the size of | In other words, different Explicit PvDs MAY be advertised with RAs | |||
| an advertisement to exceed the link MTU, multiple router | using the same link-local source address; but different Implicit | |||
| advertisements can be sent, each containing a subset of the options. | PvDs, advertised by different RAs, MUST use different link-local | |||
| In such cases, the PvD option header (i.e., all fields except the | addresses because these Implicit PvDs are identified by the source | |||
| 'Options' field) MUST be repeated in all the transmitted RAs. The | addresses of the RAs. If a link-local address on the router is | |||
| options within the 'Options' field, MAY be transmitted only once, | changed, then any new RA will be interpreted as a different Implicit | |||
| included in one of the transmitted PvD options. | 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 advertisements MUST 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' field, | ||||
| MAY be transmitted only once, included in one of the transmitted PvD | ||||
| Options. | ||||
| 3.3. Non-PvD-aware Host Behavior | 3.3. Non-PvD-aware Host Behavior | |||
| As the PvD Option has a new option code, non-PvD-aware hosts will | 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. This | simply ignore the PvD Option and all the options it contains (see | |||
| ensure the backward compatibility required in section 3.3 of | section 4.2 of [RFC4861]. This ensures the backward compatibility | |||
| [RFC7556]. This behavior allows for a mixed-mode network with a mix | required in Section 3.3 of [RFC7556]. This behavior allows for a | |||
| of PvD-aware and non-PvD-aware hosts coexist. | mixed-mode network where a mix of PvD-aware and non-PvD-aware hosts | |||
| coexist. | ||||
| 3.4. PvD-aware Host Behavior | 3.4. PvD-aware Host Behavior | |||
| Hosts MUST associate received RAs and included configuration | Hosts MUST associate received RAs and included configuration | |||
| information (e.g., Router Valid Lifetime, Prefix Information | information (e.g., Router Valid Lifetime, Prefix Information | |||
| [RFC4861], Recursive DNS Server [RFC8106], Routing Information | [RFC4861], Recursive DNS Server [RFC8106], Routing Information | |||
| [RFC4191] options) with the explicit PvD identified by the first PvD | [RFC4191] options) with the Explicit PvD identified by the first PvD | |||
| Option present in the received RA, if any, or with the implicit 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 | identified by the host interface and the source address of the | |||
| received RA otherwise. | 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, hosts MUST | In case multiple PvD Options are found in a given RA, hosts MUST | |||
| ignore all but the first PvD option. | ignore all but the first PvD Option. | |||
| If a host receives PvD options flags that it does not recognize | If a host receives PvD Options flags that it does not recognize | |||
| (currently in the Reserved field), it MUST ignore these flags. | (currently in the Reserved field), it MUST ignore these flags. | |||
| Similarly, hosts MUST associate all network configuration objects | Similarly, hosts MUST associate all network configuration objects | |||
| (e.g., default routers, addresses, more specific routes, DNS | (e.g., default routers, addresses, more specific routes, DNS | |||
| Recursive Resolvers) with the PvD associated with the RA which last | Recursive Resolvers) with the PvD associated with the RA that | |||
| updated the object. For example, addresses that are generated using | provisioned the object. For example, addresses that are generated | |||
| a received Prefix Information option (PIO) are associated with the | using a received Prefix Information option (PIO) are associated with | |||
| PvD of the last received RA which included the given PIO. | the PvD of the last received RA which included the given PIO. | |||
| PvD IDs MUST be compared in a case-insensitive manner (i.e., A=a), | ||||
| assuming ASCII with zero parity while non-alphabetic codes must match | ||||
| exactly (see also Section 3.1 of [RFC1035]). For example, | ||||
| "pvd.example.com." or "PvD.Example.coM." would refer to the same PvD. | ||||
| While resolving names, executing the default address selection | PvD IDs MUST be compared in a case-insensitive manner as defined by | |||
| algorithm [RFC6724] or executing the default router selection | [RFC4343]. For example, "pvd.example.com." or "PvD.Example.coM." | |||
| algorithm when forwarding packets ([RFC2461], [RFC4191] and | would refer to the same PvD. | |||
| [RFC8028]), hosts MAY consider only the configuration associated with | ||||
| an arbitrary set of PvDs. | ||||
| For example, a host MAY associate a given process with a specific | While performing PvD-specific operations such as resolving names, | |||
| PvD, or a specific set of PvDs, while associating another process | executing the default address selection algorithm [RFC6724] or | |||
| with another PvD. A PvD-aware application might also be able to | executing the default router selection algorithm when forwarding | |||
| select, on a per-connection basis, which PvDs should be used. In | packets ([RFC4861], [RFC4191] and [RFC8028]), hosts and applications | |||
| particular, constrained devices such as small battery operated | MAY consider only the configuration associated with any non-empty | |||
| devices (e.g. IoT), or devices with limited CPU or memory resources | subset of PvDs. For example, a host MAY associate a given process | |||
| may purposefully use a single PvD while ignoring some received RAs | with a specific PvD, or a specific set of PvDs, while associating | |||
| containing different PvD IDs. | 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., 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 | The way an application expresses its desire to use a given PvD, or a | |||
| set of PvDs, or the way this selection is enforced, is out of the | set of PvDs, or the way this selection is enforced, is out of the | |||
| scope of this document. Useful insights about these considerations | scope of this document. Useful insights about these considerations | |||
| can be found in [I-D.kline-mif-mpvd-api-reqs]. | can be found in [I-D.kline-mif-mpvd-api-reqs]. | |||
| 3.4.1. DHCPv6 configuration association | 3.4.1. DHCPv6 configuration association | |||
| When a host retrieves configuration elements using DHCPv6 (e.g., | When a host retrieves stateless configuration elements using DHCPv6 | |||
| addresses or DNS recursive resolvers), they MUST be associated with | (e.g., DNS recursive resolvers or DNS domain search lists [RFC3646]), | |||
| the explicit or implicit PvD of the RA received on the same | they MUST be associated with all the explicit and implicit PvDs | |||
| interface, sent from the same LLA, and with the O-flag or M-flag set | received on the same interface and contained in a RA with the O-flag | |||
| [RFC4861]. If no such PvD is found, or whenever multiple different | set [RFC4861]. | |||
| PvDs are found, the host behavior is unspecified. | ||||
| This process requires hosts to keep track of received RAs, associated | When a host retrieves stateful assignments using DHCPv6, such | |||
| PvD IDs, and routers LLA; it also assumes that the router either acts | assignments MUST be associated with the received PvD which was | |||
| as a DHCPv6 server or relay and uses the same LLA for DHCPv6 and RA | received with RAs with the M-flag set and including a matching PIO. | |||
| traffic (which may not be the case when the router uses VRRP to send | A PIO is considered to match a DHCPv6 assignment when the IPv6 prefix | |||
| its RA). | from the PIO includes the assignment from DHCPv6. For example, if a | |||
| PvD's associated PIO defines the prefix 2001:db8:cafe::/64, a DHCPv6 | ||||
| IA_NA message that assigns the address 2001:db8:cafe::1234:4567 would | ||||
| be considered to match. | ||||
| In cases where an address would be assigned by DHCPv6 and no matching | ||||
| PvD could be found, hosts MAY associate the assigned address with any | ||||
| implicit PvD received on the same interface or to multiple implicit | ||||
| PvDs received on the same interface. This is intended to resolve | ||||
| backward compatibility issues with rare deployments choosing to | ||||
| assign addresses with DHCPv6 while not sending any matching PIO. | ||||
| Implementations are suggested to flag or log such scenarios as errors | ||||
| to help detect misconfigurations. | ||||
| 3.4.2. DHCPv4 configuration association | 3.4.2. DHCPv4 configuration association | |||
| When a host retrieves configuration elements from DHCPv4, they MUST | Associating DHCPv4 [RFC2131] configuration elements with Explicit | |||
| be associated with the explicit PvD received on the same interface, | PvDs allows hosts to treat a set of IPv4 and IPv6 configurations as a | |||
| whose PVD Options L-flag is set and, in the case of a non point-to- | single PvD with shared properties. For example, consider a router | |||
| point link, using the same datalink address. If no such PvD is | that provides two different uplinks. One could be a broadband | |||
| found, or whenever multiple different PvDs are found, the | network that has data rate and streaming properties described in PvD | |||
| configuration elements coming from DHCPv4 MUST be associated with the | additional information and that provides both IPv4 and IPv6 network | |||
| implicit PvD identified by the interface on which the DHCPv4 | access. The other could be a cellular network that provides only | |||
| transaction happened. The case of multiple explicit PvD for an IPv4 | IPv6 network access, and uses NAT64 [RFC6146]. The broadband network | |||
| interface is undefined. | can be represented by an Explicit PvD that points to the additional | |||
| information, and also marks association with DHCPv4 information. The | ||||
| cellular network can be represented by a different Explicit PvD that | ||||
| is not associated with DHCPv4. | ||||
| When a PvD-aware host retrieves configuration elements from DHCPv4, | ||||
| the information is associated either with a single Explicit PvD on | ||||
| that interface, or else with all Implicit PvDs on the same interface. | ||||
| An Explicit PvD indicates its association with DHCPv4 information by | ||||
| setting the L-flag in the PvD RA Option. If there is exactly one | ||||
| Explicit PvD that sets this flag, hosts MUST associate the DHCPv4 | ||||
| information with that PvD. Multiple Explicit PvDs on the same | ||||
| interface marking this flag is a misconfiguration, and hosts SHOULD | ||||
| NOT associate the DHCPv4 information with any Explicit PvD in this | ||||
| case. | ||||
| If no single Explicit PvD claims association with DHCPv4, the | ||||
| configuration elements coming from DHCPv4 MUST be associated with all | ||||
| Implicit PvDs identified by the interface on which the DHCPv4 | ||||
| transaction happened. This maintains existing host behavior. | ||||
| 3.4.3. Connection Sharing by the Host | 3.4.3. Connection Sharing by the Host | |||
| The situation when a host shares connectivity from an upstream | The situation when a host shares connectivity from an upstream | |||
| interface (e.g. cellular) to a downstream interface (e.g. WiFi) is | interface (e.g., cellular) to a downstream interface (e.g., Wi-Fi) is | |||
| known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share | known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share | |||
| [RFC7278] or prefix delegation (e.g. using DHCPv6-PD [RFC8415]) may | [RFC7278] or prefix delegation (e.g., using DHCPv6-PD [RFC8415]) may | |||
| be used for that purpose. | be used for that purpose. | |||
| Whenever the RAs received from the upstream interface contain a PVD | Whenever the RAs received from the upstream interface contain a PVD | |||
| RA option, hosts that are sharing connectivity SHOULD include a PVD | RA option, hosts that are sharing connectivity SHOULD include a PVD | |||
| Option within the RAs sent downstream with: | option within the RAs sent downstream with: | |||
| The same PVD-ID FQDN. | ||||
| The same H-bit, Delay and Sequence Number values. | o The same PVD-ID FQDN | |||
| The L bit set whenever the host is sharing IPv4 connectivity | o The same H-flag, Delay and Sequence Number values | |||
| received from the same upstream interface. | o The L bit set whenever the host is sharing IPv4 connectivity | |||
| received from the same upstream interface | ||||
| The bits from the Reserved field set to 0. | o The bits from the Reserved field set to 0 | |||
| The values of the R-bit, Router Advertisement message header and | The values of the R-flag, Router Advertisement message header and | |||
| Options field depend on whether the connectivity should be shared | Options field depend on whether the connectivity should be shared | |||
| only with PvD-aware hosts or not (see Section 3.2). In particular, | only with PvD-aware hosts or not (see Section 3.2). In particular, | |||
| all options received within the upstream PvD option and included in | all options received within the upstream PvD Option and included in | |||
| the downstream RA SHOULD be included in the downstream PvD option. | the downstream RA SHOULD be included in the downstream PvD Option. | |||
| 3.4.4. Usage of DNS Servers | 3.4.4. Usage of DNS Servers | |||
| PvD-aware hosts can be provisioned with recursive DNS servers via RA | PvD-aware hosts can be provisioned with recursive DNS servers via RA | |||
| options passed within an explicit PvD, via RA options associated with | options passed within an Explicit PvD, via RA options associated with | |||
| an implicit PvD, via DHCPv6 or DHCPv4, or from some other | an Implicit PvD, via DHCPv6 or DHCPv4, or from some other | |||
| provisioning mechanism that creates an implicit PvD (such as a VPN). | provisioning mechanism that creates an Explicit PvD (such as a VPN). | |||
| In all of these cases, the DNS server addresses SHOULD be strongly | In all of these cases, the recursive DNS server addresses SHOULD be | |||
| associated with the corresponding PvD. Specificially, queries sent | associated with the corresponding PvD. Specifically, queries sent to | |||
| to a configured recursive DNS server SHOULD be sent from a local IP | a configured recursive DNS server SHOULD be sent from a local IP | |||
| address that belongs to the matching PvD. Answers received from the | address that was provisioned for the PvD via RA or DHCP. Answers | |||
| DNS server SHOULD only be used on the same PvD. | received from the DNS server SHOULD only be used on the same PvD. | |||
| PvD-aware applications will be able to select which PvD(s) to use for | ||||
| DNS resolution and connections, which allows them to effectively use | ||||
| multiple Explicit PvDs. In order to support non-PvD-aware | ||||
| applications, however, PvD-aware hosts SHOULD ensure that non-PvD- | ||||
| aware name resolution APIs like "getaddrinfo" only use resolvers from | ||||
| a single PvD for a given query. Handling DNS across PvDs is | ||||
| discussed in Section 5.2.1 of [RFC7556], and PvD APIs are discussed | ||||
| in Section 6 of [RFC7556]. | ||||
| Maintaining the correct usage of DNS within PvDs avoids various | Maintaining the correct usage of DNS within PvDs avoids various | |||
| practical errors, such as: | practical errors, such as: | |||
| A PvD associated with a VPN or otherwise private network may | o A PvD associated with a VPN or otherwise private network may | |||
| provide DNS answers that contain addresses inaccessible over | provide DNS answers that contain addresses inaccessible over | |||
| another PvD. | another PvD. This includes the DNS queries to retrieve PvD | |||
| additional information, which could otherwise send identifying | ||||
| information to the recursive DNS system (see Section 4.1). | ||||
| A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will | o A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will | |||
| synthesize IPv6 addresses in DNS answers that are not globally | synthesize IPv6 addresses in DNS answers that are not globally | |||
| routable, and cannot be used on other PvDs. Conversely, an IPv4 | routable, and would be invalid on other PvDs. Conversely, an IPv4 | |||
| address resolved via DNS on another PvD cannot be directly used on | address resolved via DNS on another PvD cannot be directly used on | |||
| a NAT64 network without the host synthesizing an IPv6 address. | a NAT64 network. | |||
| 4. Provisioning Domain Additional Information | 4. Provisioning Domain Additional Information | |||
| Additional information about the network characteristics can be | Additional information about the network characteristics can be | |||
| retrieved based on the PvD ID. This set of information is called PvD | retrieved based on the PvD ID. This set of information is called PvD | |||
| Additional Information, and is encoded as a JSON object [RFC7159]. | Additional Information, and is encoded as a JSON object [RFC8259]. | |||
| This JSON object is restricted to the I-JSON profile, as defined in | ||||
| [RFC7493]. | ||||
| The purpose of this additional set of information is to securely | The purpose of this JSON object is to provide additional information | |||
| provide additional information to applications about the connectivity | to applications on a client host about the connectivity that is | |||
| that is provided using a given interface and source address pair. It | provided using a given interface and source address. It typically | |||
| typically includes data that would be considered too large, or not | includes data that would be considered too large, or not critical | |||
| critical enough, to be provided within an RA option. The information | enough, to be provided within an RA option. The information | |||
| contained in this object MAY be used by the operating system, network | contained in this object MAY be used by the operating system, network | |||
| libraries, applications, or users, in order to decide which set of | libraries, applications, or users, in order to decide which set of | |||
| PvDs should be used for which connection, as described in | PvDs should be used for which connection, as described in | |||
| Section 3.4. | Section 3.4. | |||
| The additional information related to a PvD is specifically intended | ||||
| to be optional, and is targeted at optimizing or informing the | ||||
| behavior of user-facing hosts. This information can be extended to | ||||
| provide hints for host system behavior (such as captive portal or | ||||
| walled-garden PvD detection) or application behavior (describing | ||||
| application-specific services offered on a given PvD). This content | ||||
| may not be appropriate for light-weight Internet of Things (IoT) | ||||
| devices. IoT devices might need only a subset of the information, | ||||
| and would in some cases prefer a smaller representation like CBOR | ||||
| ([RFC7049]). Delivering a reduced version of the PvD Additional | ||||
| Information designed for such devices is not defined in this | ||||
| document. | ||||
| 4.1. Retrieving the PvD Additional Information | 4.1. Retrieving the PvD Additional Information | |||
| When the H-flag of the PvD Option is set, hosts MAY attempt to | When the H-flag of the PvD Option is set, hosts MAY attempt to | |||
| retrieve the PvD Additional Information associated with a given PvD | retrieve the PvD Additional Information associated with a given PvD | |||
| by performing an HTTP over TLS [RFC2818] GET query to https://<PvD- | by performing an HTTP over TLS [RFC2818] GET query to https://<PvD- | |||
| ID>/.well-known/pvd [RFC5785]. Inversely, hosts MUST NOT do so | ID>/.well-known/pvd. Inversely, hosts MUST NOT do so whenever the | |||
| whenever the H-flag is not set. | H-flag is not set. | |||
| Note that the DNS name resolution of the PvD ID, the PKI checks as | Recommendations for how to use TLS securely can be found in | |||
| well as the actual query MUST be performed using the considered PvD. | [RFC7525]. | |||
| In other words, the name resolution, PKI checks, source address | ||||
| selection, as well as the next-hop router selection MUST be performed | When a host retrieves the PvD Additional Information, it MUST verify | |||
| while using exclusively the set of configuration information attached | that the TLS server certificate is valid for the performed request; | |||
| with the PvD, as defined in Section 3.4. In some cases, it may | specifically, that a DNS-ID [RFC6125] on the certificate is equal to | |||
| therefore be necessary to wait for an address to be available for use | the PvD ID expressed as an FQDN. This validation indicates that the | |||
| (e.g., once the Duplicate Address Detection or DHCPv6 processes are | owner of the FQDN authorizes its use with the prefix advertised by | |||
| complete) before initiating the HTTP over TLS query. If the host has | the router. If this validation fails, hosts MUST close the | |||
| a temporary address per [RFC4941] in this PvD, then hosts SHOULD use | connection and treat the PvD as if it has no Additional Information. | |||
| a temporary address to fetch the PvD Additional Information and | ||||
| SHOULD deprecate the used temporary address and generate a new | HTTP requests and responses for PvD additional information use the | |||
| temporary address afterward. | "application/pvd+json" media type (see Section 8). Clients SHOULD | |||
| include this media type as an Accept header field in their GET | ||||
| requests, and servers MUST mark this media type as their Content-Type | ||||
| header field in responses. | ||||
| Note that the DNS name resolution of the PvD ID, any connections made | ||||
| for certficate validation (such as OCSP [RFC6960]), and the HTTP | ||||
| request itself MUST be performed using the considered PvD. In other | ||||
| words, the name resolution, PKI checks, source address selection, as | ||||
| well as the next-hop router selection MUST be performed while using | ||||
| exclusively the set of configuration information attached with the | ||||
| PvD, as defined in Section 3.4. In some cases, it may therefore be | ||||
| necessary to wait for an address to be available for use (e.g., once | ||||
| the Duplicate Address Detection or DHCPv6 processes are complete) | ||||
| before initiating the HTTP over TLS query. In order to address | ||||
| privacy concerns around linkability of the PvD HTTP connection with | ||||
| future user-initiated connections, if the host has a temporary | ||||
| address per [RFC4941] in this PvD, then it SHOULD use a temporary | ||||
| address to fetch the PvD Additional Information and MAY deprecate the | ||||
| used temporary address and generate a new temporary address | ||||
| afterward. | ||||
| If the HTTP status of the answer is greater than or equal to 400 the | If the HTTP status of the answer is greater than or equal to 400 the | |||
| host MUST abandon and consider that there is no additional PvD | host MUST close its connection and consider that there is no | |||
| information. If the HTTP status of the answer is between 300 and | additional PvD information. If the HTTP status of the answer is | |||
| 399, inclusive, it MUST follow the redirection(s). If the HTTP | between 300 and 399, inclusive, it MUST follow the redirection(s). | |||
| status of the answer is between 200 and 299, inclusive, the host MAY | If the HTTP status of the answer is between 200 and 299, inclusive, | |||
| get a file containing a single JSON object. When a JSON object could | the response is expected to be a single JSON object. | |||
| not be retrieved, an error message SHOULD be logged and/or displayed | ||||
| in a rate-limited fashion. | ||||
| After retrieval of the PvD Additional Information, hosts MUST keep | After retrieval of the PvD Additional Information, hosts MUST | |||
| track of the Sequence Number value received in subsequent RAs | remember the last Sequence Number value received in an RA including | |||
| including the same PvD ID. In case the new value is greater than the | the same PvD ID. Whenever a new RA for the same PvD is received with | |||
| value that was observed when the PvD Additional Information object | a different Sequence Number value, or whenever the expiry date for | |||
| was retrieved (using serial number arithmetic comparisons [RFC1982]), | the additional information is reached, hosts MUST deprecate the | |||
| or whenever the validity time included in the PVD Additional | additional information and stop using it. | |||
| Information JSON object is expired, hosts MUST either perform a new | ||||
| query and retrieve a new version of the object, or, failing that, | ||||
| deprecate the object and stop using the additional information | ||||
| provided in the JSON object. | ||||
| Hosts retrieving a new PvD Additional Information object MUST check | Hosts retrieving a new PvD Additional Information object MUST check | |||
| for the presence and validity of the mandatory fields specified in | for the presence and validity of the mandatory fields specified in | |||
| Section 4.3. A retrieved object including an expiration time that is | Section 4.3. A retrieved object including an expiration time that is | |||
| already past or missing a mandatory element MUST be ignored. | already past or missing a mandatory element MUST be ignored. | |||
| In order to avoid synchronized queries toward the server hosting the | In order to avoid synchronized queries toward the server hosting the | |||
| PvD Additional Information when an object expires, object updates are | PvD Additional Information when an object expires, object updates are | |||
| delayed by a randomized backoff time. | delayed by a randomized backoff time. | |||
| When a host performs an object update after it detected a change | o When a host performs a JSON object update after it detected a | |||
| in the PvD Option Sequence number, it MUST delay the query by a | change in the PvD Option Sequence Number, it MUST add a delay | |||
| random time between zero and 2**(Delay * 2) milliseconds, where | before sending the query. The target time for the delay is | |||
| 'Delay' corresponds to the 4 bits long unsigned integer in the | calculated as a random time between zero and 2**(10 + Delay) | |||
| last received PvD Option. | milliseconds, where 'Delay' corresponds to the 4-bit unsigned | |||
| integer in the last received PvD Option. | ||||
| When a host last retrieved an object at time A including a | o When a host last retrieved a JSON object at time A that includes a | |||
| validity time B, and is configured to keep the object up to date, | expiry time B using the "expires" key, and the host is configured | |||
| it MUST perform the update at a uniformly random time in the | to keep the PvD information up to date, it MUST add some | |||
| interval [(B-A)/2,B]. | randomness into its calculation of the time to fetch the update. | |||
| The target time for fetching the updated object is calculated as a | ||||
| uniformly random time in the interval [(B-A)/2,B]. | ||||
| In the example Figure 2, the delay field value is 5, this means that | In the example Figure 2, the delay field value is 1, this means that | |||
| host MUST delay the query by a random number between 0 and 2**(5 * 2) | the host calculates its delay by choosing a uniformly random time | |||
| milliseconds, i.e., between 0 and 1024 milliseconds. | 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 | Since the 'Delay' value is directly within the PvD Option rather than | |||
| the object itself, an operator may perform a push-based update by | the object itself, an operator may perform a push-based update by | |||
| incrementing the Sequence value while changing the Delay value | incrementing the Sequence Number value while changing the Delay value | |||
| depending on the criticality of the update and its PvD Additional | depending on the criticality of the update and its PvD Additional | |||
| Information servers capacity. | Information servers capacity. | |||
| In addition to adding a random delay when fetching Additional | ||||
| Information, hosts MUST enforce a minimum time between requesting | ||||
| Additional Information for a given PvD on the same network. This | ||||
| minimum time is RECOMMENDED to be 10 seconds, in order to avoid hosts | ||||
| causing a denial-of-service on the PvD server. Hosts also MUST limit | ||||
| the number of requests that are made to different PvD Additional | ||||
| Information servers on the same network within a short period of | ||||
| time. A RECOMMENDED value is to issue no more than five PvD | ||||
| Additional Information requests in total on a given network within 10 | ||||
| seconds. For more discussion, see Section 6. | ||||
| The PvD Additional Information object includes a set of IPv6 prefixes | The PvD Additional Information object includes a set of IPv6 prefixes | |||
| (under the key "prefixes") which MUST be checked against all the | (under the key "prefixes") which MUST be checked against all the | |||
| Prefix Information Options advertised in the RA. If any of the | Prefix Information Options advertised in the RA. If any of the | |||
| prefixes included in the PIO is not covered by at least one of the | prefixes included in any associated PIO is not covered by at least | |||
| listed prefixes, the PvD associated with the tested prefix MUST be | one of the listed prefixes, the associated PvD information MUST be | |||
| considered unsafe and MUST NOT be used. While this does not prevent | considered to be a misconfiguration, and MUST NOT be used by the | |||
| a malicious network provider, it does complicate some attack | host. See Section 4.4 for more discussion on handling such | |||
| scenarios, and may help detecting misconfiguration. | misconfigurations. | |||
| If the request for PvD Additional Information fails due to a TLS | ||||
| certificate validation error, an HTTP error, or because the retrieved | ||||
| file does not contain valid PvD JSON, hosts MUST close any connection | ||||
| used to fetch the PvD Additional Information, and MUST NOT request | ||||
| the information for that PvD ID again for the duration of the local | ||||
| network attachment. If a host detects 10 or more such failures to | ||||
| fetch PvD Additional Information, the local network is assumed to be | ||||
| misconfigured or under attack, and the host MUST NOT make any further | ||||
| requests for any PvD Additional Information, belonging to any PvD ID, | ||||
| for the duration of the local network attachment. For more | ||||
| discussion, see Section 6. | ||||
| 4.2. Operational Consideration to Providing the PvD Additional | 4.2. Operational Consideration to Providing the PvD Additional | |||
| Information | Information | |||
| Whenever the H-flag is set in the PvD Option, a valid PvD Additional | Whenever the H-flag is set in the PvD Option, a valid PvD Additional | |||
| Information object MUST be made available to all hosts receiving the | Information object MUST be made available to all hosts receiving the | |||
| RA by the network operator. In particular, when a captive portal is | RA by the network operator. In particular, when a captive portal is | |||
| present, hosts MUST still be allowed to perform DNS, PKI and HTTP | present, hosts MUST still be allowed to perform DNS, certficate | |||
| over TLS operations related to the retrieval of the object, even | validation, and HTTP over TLS operations related to the retrieval of | |||
| before logging into the captive portal. | the object, even before logging into the captive portal. | |||
| Routers MAY increment the PVD Option Sequence number in order to | Routers SHOULD increment the PVD Option Sequence Number by one | |||
| inform host that a new PvD Additional Information object is available | whenever a new PvD Additional Information object is available and | |||
| and should be retrieved. | should be retrieved by hosts. If the value exceeds what can be | |||
| stored in the Sequence Number field, it MUST wrap back to zero. | ||||
| The server providing the JSON files SHOULD also check whether the | The server providing the JSON files SHOULD also check whether the | |||
| client address is part of the prefixes listed into the additional | client address is contained by the prefixes listed in the additional | |||
| information and SHOULD return a 403 response code if there is no | information, and SHOULD return a 403 response code if there is no | |||
| match. | match. | |||
| 4.3. PvD Additional Information Format | 4.3. PvD Additional Information Format | |||
| The PvD Additional Information is a JSON object. | The PvD Additional Information is a JSON object. | |||
| The following table presents the mandatory keys which MUST be | The following table presents the mandatory keys which MUST be | |||
| included in the object: | included in the object: | |||
| +----------+-----------------+-------------+------------------------+ | +------------+-----------------+-----------+------------------------+ | |||
| | JSON key | Description | Type | Example | | | JSON key | Description | Type | Example | | |||
| +----------+-----------------+-------------+------------------------+ | +------------+-----------------+-----------+------------------------+ | |||
| | name | Human-readable | UTF-8 | "Awesome Wifi" | | | identifier | PvD ID FQDN | String | "pvd.example.com." | | |||
| | | service name | string | | | | | | | | | |||
| | | | [RFC3629] | | | | expires | Date after | [RFC3339] | "2020-05-23T06:00:00Z" | | |||
| | expires | Date after | [RFC3339] | "2017-07-23T06:00:00Z" | | | | which this | Date | | | |||
| | | which this | | | | | | object is no | | | | |||
| | | object is not | | | | | | longer valid | | | | |||
| | | valid | | | | | | | | | | |||
| | prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", | | | prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", | | |||
| | | prefixes valid | strings | "2001:db8:4::/48"] | | | | prefixes valid | strings | "2001:db8:4::/48"] | | |||
| | | for this PVD | | | | | | for this PvD | | | | |||
| +----------+-----------------+-------------+------------------------+ | +------------+-----------------+-----------+------------------------+ | |||
| A retrieved object which does not include a valid string associated | A retrieved object which does not include all three of these keys at | |||
| with the "name" key at the root of the object, or a valid date | the root of the JSON object MUST be ignored. All three keys need to | |||
| associated with the "expires" key, also at the root of the object, | be validated, otherwise the object MUST be ignored. The value stored | |||
| MUST be ignored. In such cases, an error message SHOULD be logged | for "identifier" MUST be matched against the PvD ID FQDN presented in | |||
| and/or displayed in a rate-limited fashion. If the PIO of the | the PvD RA option using the comparison mechanism described in | |||
| received RA is not covered by at least one of the "prefixes" key, the | Section 3.4. The value stored for "expires" MUST be a valid date in | |||
| retrieved object SHOULD be ignored. | the future. If the PIO of the received RA is not covered by at least | |||
| one of the "prefixes" key, the retrieved object SHOULD be ignored. | ||||
| The following table presents some optional keys which MAY be included | The following table presents some optional keys which MAY be included | |||
| in the object. | in the object. | |||
| +---------------+-----------------+---------+-----------------------+ | +------------+-----------------------+---------+--------------------+ | |||
| | JSON key | Description | Type | Example | | | JSON key | Description | Type | Example | | |||
| +---------------+-----------------+---------+-----------------------+ | +------------+-----------------------+---------+--------------------+ | |||
| | localizedName | Localized user- | UTF-8 | "Wifi Genial" | | | dnsZones | DNS zones searchable | Array | ["example.com", | | |||
| | | visible service | string | | | | | and accessible | of | "sub.example.com"] | | |||
| | | name, language | | | | | | | strings | | | |||
| | | can be selected | | | | | | | | | | |||
| | | based on the | | | | | noInternet | No Internet, set to | Boolean | true | | |||
| | | HTTP Accept- | | | | | | "true" when the PvD | | | | |||
| | | Language header | | | | | | is restricted. | | | | |||
| | | in the request. | | | | +------------+-----------------------+---------+--------------------+ | |||
| | dnsZones | DNS zones | array | ["example.com","sub.e | | ||||
| | | searchable and | of DNS | xample.org"] | | ||||
| | | accessible | zones | | | ||||
| | noInternet | No Internet, | boolean | true | | ||||
| | | set when the | | | | ||||
| | | PvD only | | | | ||||
| | | provides | | | | ||||
| | | restricted | | | | ||||
| | | access to a set | | | | ||||
| | | of services | | | | ||||
| +---------------+-----------------+---------+-----------------------+ | ||||
| It is worth noting that the JSON format allows for extensions. | It is worth noting that the JSON format allows for extensions. | |||
| Whenever an unknown key is encountered, it MUST be ignored along with | Whenever an unknown key is encountered, it MUST be ignored along with | |||
| its associated elements. | its associated elements. | |||
| 4.3.1. Private Extensions | Private-use or experimental keys MAY be used in the JSON dictionary. | |||
| In order to avoid such keys colliding with IANA registry keys, | ||||
| JSON keys starting with "x-" are reserved for private use and can be | implementers or vendors defining private-use or experimental keys | |||
| utilized to provide information that is specific to vendor, user or | MUST create sub-dictionaries. If a set of PvD Additional Information | |||
| enterprise. It is RECOMMENDED to use one of the patterns "x-FQDN- | keys are defined by an organization that has a Formal URN Namespace | |||
| KEY" or "x-PEN-KEY" where FQDN is a fully qualified domain name or | [URN], the URN namespace SHOULD be used as the top-level JSON key for | |||
| PEN is a private enterprise number [PEN] under control of the author | the sub-dictionary. For other private uses, the sub-dictionary key | |||
| of the extension to avoid collisions. | SHOULD follow the format of "vendor-*", where the "*" is replaced by | |||
| the implementer's or vendor's identifier. For example, keys specific | ||||
| to the FooBar organization could use "vendor-foobar". If a host | ||||
| receives a sub-dictionary with an unknown key, the host MUST ignore | ||||
| the contents of the sub-dictionary. | ||||
| 4.3.2. Example | 4.3.1. Example | |||
| Here are two examples based on the keys defined in this section. | The following two examples show how the JSON keys defined in this | |||
| document can be used: | ||||
| { | { | |||
| "name": "Foo Wireless", | "identifier": "cafe.example.com.", | |||
| "localizedName": "Foo-France Wifi", | "expires": "2020-05-23T06:00:00Z", | |||
| "expires": "2017-07-23T06:00:00Z", | "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | |||
| "prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"], | ||||
| } | } | |||
| { | { | |||
| "name": "Bar 4G", | "identifier": "company.foo.example.com.", | |||
| "localizedName": "Bar US 4G", | "expires": "2020-05-23T06:00:00Z", | |||
| "expires": "2017-07-23T06:00:00Z", | ||||
| "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | |||
| "vendor-foo": | ||||
| { | ||||
| "private-key": "private-value", | ||||
| }, | ||||
| } | } | |||
| 4.4. Detecting misconfiguration and misuse | 4.4. Detecting misconfiguration and misuse | |||
| When a host retrieves the PvD Additional Information, it MUST verify | Hosts MUST validate the TLS server certificate when retrieving PvD | |||
| that the TLS server certificate is valid for the performed request | Additional Information, as detailed in Section 4.1. | |||
| (e.g., that the Subject Name is equal to the PvD ID expressed as an | ||||
| FQDN). This authentication creates a secure binding between the | ||||
| information provided by the trusted Router Advertisement, and the | ||||
| HTTPS server. However, this does not mean the Advertising Router and | ||||
| the PvD server belong to the same entity. | ||||
| Hosts MUST verify that all prefixes in the RA PIO are covered by a | ||||
| prefix from the PvD Additional Information. An adversarial router | ||||
| willing to fake the use of a given explicit PvD, without any access | ||||
| to the actual PvD Additional Information, would need to perform NAT66 | ||||
| in order to circumvent this check. | ||||
| It is also RECOMMENDED that the HTTPS server checks the IPv6 source | Hosts MUST verify that all prefixes in all the RA PIOs are covered by | |||
| addresses of incoming connections (see Section 4.1). This check give | a prefix from the PvD Additional Information. An adversarial router | |||
| reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used | attempting to spoof the definition of an Explicit PvD, without the | |||
| and restricts the information to the valid network users. | ability to modify the PvD Additional Information, would need to | |||
| perform NAT66 in order to circumvent this check. Thus, this check | ||||
| cannot prevent all spoofing, but it can detect misconfiguration or | ||||
| mismatched routers that are not adding a NAT. | ||||
| Note that this check cannot be performed when the HTTPS query is | If NAT66 is being added in order to spoof PvD ownership, the HTTPS | |||
| performed over IPv4. Therefore, the PvD ID FQDN SHOULD NOT have a | server for additional information can detect this misconfiguration. | |||
| DNS A record whenever all hosts using the given PvD have IPv6 | The HTTPS server SHOULD validate the source addresses of incoming | |||
| connectivity. | connections (see Section 4.1). This check gives reasonable assurance | |||
| that neither NPTv6 [RFC6296] nor NAT66 were used and restricts the | ||||
| information to the valid network users. If the PvD does not | ||||
| provision IPv4 (it does not include the 'L' bit in the RA), the | ||||
| server cannot validate the source addresses of connections using | ||||
| IPv4. Thus, the PvD ID FQDN for such PvDs SHOULD NOT have a DNS A | ||||
| record. | ||||
| 5. Operational Considerations | 5. Operational Considerations | |||
| This section describes some use cases of PvD. For the sake of | This section describes some example use cases of PvDs. For the sake | |||
| simplicity, the RA messages will not be described in the usual ASCII | of simplicity, the RA messages will not be described in the usual | |||
| art but rather in an indented list. For example, a RA message | ASCII art but rather in an indented list. Values in the PvD Option | |||
| containing some options and a PvD option that also contains other | header that are not included in the example are assumed to be zero or | |||
| options will be described as: | false (such as the H-flag, Sequence Number, and Delay fields). | |||
| 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. | ||||
| o RA Header: router lifetime = 6000 | o RA Header: router lifetime = 6000 | |||
| o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 | o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 | |||
| o PvD Option header: length = 3 + 5 + 4 , PvD ID FQDN = | o PvD Option header: length = 3 + 5 + 4, PvD ID FQDN = example.org., | |||
| example.org., R-flag = 0 (actual length of the header with padding | R-flag = 0 (actual length of the header with padding 24 bytes = 3 | |||
| 24 bytes = 3 * 8 bytes) | * 8 bytes) | |||
| * Recursive DNS Server: length = 5, addresses= | * Recursive DNS Server: length = 5, addresses = | |||
| [2001:db8:cafe::53, 2001:db8:f00d::53] | [2001:db8:cafe::53, 2001:db8:f00d::53] | |||
| * Prefix Information Option: length = 4, prefix = | * Prefix Information Option: length = 4, prefix = | |||
| 2001:db8:f00d::/64 | 2001:db8:f00d::/64 | |||
| Note that a PvD-aware host will receive two different prefixes, | ||||
| 2001:db8:cafe::/64 and 2001: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 mixed | It is expected that for some years, networks will have a mixed | |||
| environment of PvD-aware hosts and non-PvD-aware hosts. If there is | environment of PvD-aware hosts and non-PvD-aware hosts. If there is | |||
| a need to give specific information to PvD-aware hosts only, then it | a need to give specific information to PvD-aware hosts only, then it | |||
| is recommended to send TWO RA messages: one for each class of hosts. | is RECOMMENDED to send two RA messages, one for each class of hosts. | |||
| For example, here is the RA for non-PvD-aware hosts: | This approach allows for two distinct sets of configuration | |||
| information to be sent in a way that will not disrupt non-PvD-aware | ||||
| hosts. It also lowers the risk that a single RA message will | ||||
| approach its MTU limit due to duplicated information. | ||||
| If two RA messages are sent for this reason, they MUST be sent from | ||||
| two different link-local source addresses (Section 3.2). For | ||||
| example, here is the RA sent for non-PvD-aware hosts: | ||||
| o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use | o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use | |||
| this router as a default router) | this router as a default router) | |||
| o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 | o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 | |||
| o Recursive DNS Server Option: length = 3, addresses= | o Recursive DNS Server Option: length = 3, addresses= | |||
| [2001:db8:cafe::53] | [2001:db8:cafe::53] | |||
| o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org., | o 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) | R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes) | |||
| * RA Header: router lifetime = 0 (PvD-aware hosts will not use | * RA Header: router lifetime = 0 (PvD-aware hosts will not use | |||
| this router as a default router), implicit length = 2 | this router as a default router), implicit length = 2 | |||
| And here is a RA example for PvD-aware hosts: | And here is the RA sent for PvD-aware hosts: | |||
| o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use | o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use | |||
| this router as a default router) | this router as a default router) | |||
| o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = | o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = | |||
| example.org., R-flag = 1 (actual length of the header 24 bytes = 3 | bar.example.org., R-flag = 1 (actual length of the header 24 bytes | |||
| * 8 bytes) | = 3 * 8 bytes) | |||
| * RA Header: router lifetime = 1600 (PvD-aware hosts will use | * RA Header: router lifetime = 1600 (PvD-aware hosts will use | |||
| this router as a default router), implicit length = 2 | this router as a default router), implicit length = 2 | |||
| * Prefix Information Option: length = 4, prefix = | * Prefix Information Option: length = 4, prefix = | |||
| 2001:db8:f00d::/64 | 2001:db8:f00d::/64 | |||
| * Recursive DNS Server Option: length = 3, addresses= | * Recursive DNS Server Option: length = 3, addresses = | |||
| [2001:db8:f00d::53] | [2001:db8:f00d::53] | |||
| In the above example, non-PvD-aware hosts will only use the first RA | In the above example, non-PvD-aware hosts will only use the first | |||
| sent from their default router and using the 2001:db8:cafe::/64 | listed RA sent by their default router and using the | |||
| prefix. PvD-aware hosts will autonomously configure addresses from | 2001:db8:cafe::/64 prefix. PvD-aware hosts will autonomously | |||
| both PIOs, but will only use the source address in 2001:db8:f00d::/64 | configure addresses from both PIOs, but will only use the source | |||
| to communicate past the first hop router since only the router | address in 2001:db8:f00d::/64 to communicate past the first hop | |||
| sending the second RA will be used as default router; similarly, they | router since only the router sending the second RA will be used as | |||
| will use the DNS server 2001:db8:f00d::53 when communicating with | default router; similarly, they will use the DNS server | |||
| this adress. | 2001:db8:f00d::53 when communicating from this address. | |||
| 5.3. Enabling Multi-homing 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 multi-home 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. | ||||
| o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use | ||||
| this router as a default router) | ||||
| o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 | ||||
| o Recursive DNS Server Option: length = 3, addresses= | ||||
| [2001:db8:cafe::53] | ||||
| o 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-aware hosts will ignore this RA; hence, the only PvD-aware hosts | ||||
| will be multi-homed. | ||||
| o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use | ||||
| this router as a default router) | ||||
| o 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 routers or via some other configuration mechanism. | ||||
| Another document could define ways for the router to generate its own | ||||
| PvD IDs to allow the above scenario in the absence of PvD ID | ||||
| 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. | ||||
| o RA Header: router lifetime = 6000 | ||||
| o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 | ||||
| o Recursive DNS Server Option: length = 3, addresses= | ||||
| [2001:db8:cafe::53] | ||||
| o 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 with padding 24 bytes = 3 * 8 bytes) | ||||
| A PvD-aware host will fetch https://cafe.example.com/.well-known/pvd | ||||
| to get the additonal 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/pvd | ||||
| accept = application/pvd+json | ||||
| The HTTP server will respond with the JSON additional information: | ||||
| :status = 200 | ||||
| content-type = application/pvd+json | ||||
| content-length = 116 | ||||
| { | ||||
| "identifier": "cafe.example.com.", | ||||
| "expires": "2020-05-23T06:00:00Z", | ||||
| "prefixes": ["2001:db8:cafe::/48"], | ||||
| } | ||||
| At this point, the host has the 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: | ||||
| o 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 with padding 24 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 the expiry time of the additional information has | ||||
| passed). | ||||
| 6. Security Considerations | 6. Security Considerations | |||
| Since the PvD ID RA option can contain an RA header and other RA | ||||
| options, any security considerations that apply for specific RA | ||||
| options continue to apply when used within a PvD ID option. | ||||
| Although some solutions such as IPsec or SeND [RFC3971] can be used | Although some solutions such as IPsec or SeND [RFC3971] can be used | |||
| in order to secure the IPv6 Neighbor Discovery Protocol, in practice | in order to secure the IPv6 Neighbor Discovery Protocol, in practice | |||
| actual deployments largely rely on link layer or physical layer | actual deployments largely rely on link layer or physical layer | |||
| security mechanisms (e.g. 802.1x [IEEE8021X]) in conjunction with RA | security mechanisms (e.g., 802.1x [IEEE8021X]) in conjunction with RA | |||
| Guard [RFC6105]. | Guard [RFC6105]. | |||
| If multiple RAs are sent for a single PvD to avoid fragmentation, | ||||
| dropping packets can lead to processing only part of a PvD ID option, | ||||
| which could lead to hosts receiving only part of the contained | ||||
| options. As discussed in Section 3.2, routers MUST include the PvD | ||||
| ID option in all fragments generated. | ||||
| This specification does not improve the Neighbor Discovery Protocol | This specification does not improve the Neighbor Discovery Protocol | |||
| security model, but extends the purely link-local trust relationship | security model, but simply validates that the owner of the PvD FQDN | |||
| between the host and the default routers with HTTP over TLS | authorizes its use with the prefix advertised by the router. In | |||
| communications which servers are authenticated as rightful owners of | combination with implicit trust in the local router (if present), | |||
| the FQDN received within the trusted PvD ID RA option. | this gives the host some level of assurance that the PvD is | |||
| authorized for use in this environment. However, when the local | ||||
| router cannot be trusted, no such guarantee is available. | ||||
| It must be noted that Section 4.4 of this document only provides | It must be noted that Section 4.4 of this document only provides | |||
| reasonable assurance against misconfiguration but does not prevent an | reasonable assurance against misconfiguration but does not prevent a | |||
| hostile network access provider to advertize wrong information that | hostile network access provider from advertising incorrect | |||
| could lead applications or hosts to select an hostile PvD. Users | information that could lead applications or hosts to select a hostile | |||
| should always apply caution when connecting to an unknown network. | PvD. However, a host that correctly implements the multiple PvD | |||
| architecture ([RFC7556]) using the mechanism described in this | ||||
| document will be less susceptible to some attacks than a host that | ||||
| does not by being able to check for the various misconfigurations or | ||||
| inconsistencies described in this document. | ||||
| Since expiration times provided in PvD Additional Information use | ||||
| absolute time, these values can be skewed for hosts without an | ||||
| accurate time base, or due to clock skew. Such time values MUST NOT | ||||
| be used for security-sensitive functionality or decisions. | ||||
| An attacker generating RAs on a local network can use the H-flag and | ||||
| the PvD ID to cause hosts on the network to make requests for PvD | ||||
| Additional Information from servers. This can become a denial-of- | ||||
| service attack, in which an attacker can amplify its attack by | ||||
| triggering TLS connections to arbitrary servers in response to | ||||
| sending UDP packets containing RA messages. To mitigate this attack, | ||||
| hosts MUST: | ||||
| o limit the rate at which they fetch a particular PvD's Additional | ||||
| Information; | ||||
| o limit the rate at which they fetch any PvD Additional Information | ||||
| on a given local network; | ||||
| o stop making requests for a PvD ID that does not respond with valid | ||||
| JSON; | ||||
| o stop making requests for all PvD IDs once a certain number of | ||||
| failures is reached on a particular network. | ||||
| Details are provided in Section 4.1. This attack can be targeted at | ||||
| generic web servers, in which case the host behavior of stopping | ||||
| requesting for any server that doesn't behave like a PvD Additional | ||||
| Information server is critical. Limiting requests for a specific PvD | ||||
| ID might not be sufficient if the attacker changes the PvD ID values | ||||
| quickly, so hosts also need to stop requesting if they detect | ||||
| consistent failure when on a network that is under attack. For cases | ||||
| in which an attacker is pointing hosts at a valid PvD Additional | ||||
| Information server (but one that is not actually associated with the | ||||
| local network), the server SHOULD reject any requests that do not | ||||
| originate from the expected IPv6 prefix as described in Section 4.2. | ||||
| 7. Privacy Considerations | 7. Privacy Considerations | |||
| Retrieval of the PvD Additional Information over HTTPS requires early | Retrieval of the PvD Additional Information over HTTPS requires early | |||
| communications between the connecting host and a server which may be | communications between the connecting host and a server which may be | |||
| located further than the first hop router. Although this server is | located further than the first hop router. Although this server is | |||
| likely to be located within the same administrative domain as the | likely to be located within the same administrative domain as the | |||
| default router, this property can't be ensured. Therefore, hosts | default router, this property can't be ensured. To minimize the | |||
| willing to retrieve the PvD Additional Information before using it | leakage of identity information while retrieving the PvD Additional | |||
| without leaking identity information, SHOULD make use of an IPv6 | Information, hosts SHOULD make use of an IPv6 temporary address and | |||
| Privacy Address and SHOULD NOT include any privacy sensitive data, | SHOULD NOT include any privacy-sensitive data, such as a User-Agent | |||
| such as User Agent header or HTTP cookie, while performing the HTTP | header field or an HTTP cookie. | |||
| over TLS query. | ||||
| From a privacy perspective, retrieving the PvD Additional Information | Hosts might not always fetch PvD Additional Information, depending on | |||
| is not different from establishing a first connection to a remote | whether or not they expect to use the information. However, if a | |||
| server, or even performing a single DNS lookup. For example, most | host whitelisted only certain PvD IDs for which to fetch Additional | |||
| operating systems already perform early queries to well known web | Information, an attacker could send various PvD IDs in RAs to detect | |||
| sites, such as http://captive.example.com/hotspot-detect.html, in | which PvD IDs are whitelisted by the client. To avoid this, hosts | |||
| order to detect the presence of a captive portal. | SHOULD either fetch Additional Information for all eligible PvD IDs | |||
| on a given local network, or fetch the information for none of them. | ||||
| From a user privacy perspective, retrieving the PvD Additional | ||||
| Information is not different from establishing a first connection to | ||||
| a remote server, or even performing a single DNS lookup. For | ||||
| example, most operating systems already perform early queries to | ||||
| static web sites, such as http://captive.example.com/hotspot- | ||||
| detect.html, in order to detect the presence of a captive portal. | ||||
| The DNS queries associated with the PvD Additional Information MUST | ||||
| use the DNS servers indicated by the associated PvD, as described in | ||||
| Section 4.1. This ensures the name of the PvD Additional Information | ||||
| server is not unintentionally sent on another network, thus leaking | ||||
| identifying information about the networks with which the client is | ||||
| associated. | ||||
| There may be some cases where hosts, for privacy reasons, should | There may be some cases where hosts, for privacy reasons, should | |||
| refrain from accessing servers that are located outside a certain | refrain from accessing servers that are located outside a certain | |||
| network boundary. In practice, this could be implemented as a | network boundary. In practice, this could be implemented as a | |||
| whitelist of 'trusted' FQDNs and/or IP prefixes that the host is | whitelist of 'trusted' FQDNs and/or IP prefixes that the host is | |||
| allowed to communicate with. In such scenarios, the host SHOULD | allowed to communicate with. In such scenarios, the host SHOULD | |||
| check that the provided PvD ID, as well as the IP address that it | check that the provided PvD ID, as well as the IP address that it | |||
| resolves into, are part of the allowed whitelist. | resolves into, are part of the allowed whitelist. | |||
| Network operators SHOULD restrict access to PvD Additional | ||||
| Information to only expose it to hosts that are connected to the | ||||
| local network, especially if the Additional Information would provide | ||||
| information about local network configuration to attackers. This can | ||||
| be implemented by whitelisting access from the addresses and prefixes | ||||
| that the router provides for the PvD, which will match the prefixes | ||||
| contained in the PvD Additional Information. This technique is | ||||
| described in Section 4.2. | ||||
| 8. IANA Considerations | 8. IANA Considerations | |||
| Upon publication of this document, IANA is asked to remove the | Upon publication of this document, IANA is asked to remove the | |||
| 'reclaimable' tag off the value 21 for the PvD option (from the IPv6 | 'reclaimable' tag off the value 21 for the PvD Option (from the IPv6 | |||
| Neighbor Discovery Option Formats registry). | Neighbor Discovery Option Formats registry). | |||
| IANA is asked to assign the value "pvd" from the Well-Known URIs | 8.1. New entry in the Well-Known URIs Registry | |||
| registry. | ||||
| 8.1. Additional Information PvD Keys Registry | IANA is asked to add a new entry in the Well-Known URIs registry | |||
| [RFC8615] with the following information: | ||||
| URI suffix: 'pvd' | ||||
| Change controller: IETF | ||||
| Specification document: this document | ||||
| Status: permanent | ||||
| Related information: N/A | ||||
| 8.2. Additional Information PvD Keys Registry | ||||
| IANA is asked to create and maintain a new registry called | IANA is asked to create and maintain a new registry called | |||
| "Additional Information PvD Keys", which will reserve JSON keys for | "Additional Information PvD Keys", which will reserve JSON keys for | |||
| use in PvD additional information. The initial contents of this | use in PvD additional information. The initial contents of this | |||
| registry are given in Section 4.3. | registry are given in Section 4.3, including 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 for Additional Information PvD Keys Registry will be | New assignments for Additional Information PvD Keys Registry will be | |||
| administered by IANA through Expert Review RFC8126 [RFC8126]. | administered by IANA through Expert Review [RFC8126]. Experts are | |||
| requested to ensure that defined keys do not overlap in names or | ||||
| semantics, and represent non-vendor-specific use cases. Vendor- | ||||
| specific keys SHOULD use sub-dictionaries, as described in | ||||
| Section 4.3. | ||||
| 8.2. PvD Option Flags Registry | IANA is asked to place this registry in a new page, entitled | |||
| "Provisioning Domains (PvDs)". | ||||
| 8.3. PvD Option Flags Registry | ||||
| IANA is also asked to create and maintain a new registry entitled | IANA is also asked to create and maintain a new registry entitled | |||
| "PvD Option Flags" reserving bit positions from 0 to 15 to be used in | "PvD Option Flags" reserving bit positions from 0 to 12 to be used in | |||
| the PvD option bitmask. Bit position 0, 1 and 2 are reserved by this | the PvD Option bitmask. Bit position 0, 1 and 2 are assigned by this | |||
| document (as specified in Figure 1). Future assignments require | document (as specified in Figure 1). Future assignments require | |||
| Standards Action RFC8126 [RFC8126], via a Standards Track RFC | Standards Action [RFC8126]. | |||
| document. | ||||
| 9. Acknowledgements | Since these flags apply to an IPv6 Router Advertisement Option, IANA | |||
| is asked to place this registry under the existing "Internet Control | ||||
| Message Protocol version 6 (ICMPv6) Parameters" page, as well as | ||||
| providing a link on the new "Provisioning Domains (PvDs)" page. | ||||
| 8.4. 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 to | ||||
| those specified for the "application/json" media type. | ||||
| Security considerations: See Section 6. | ||||
| Interoperability considerations: This document specifies the format | ||||
| of conforming messages and the interpretation thereof. | ||||
| Published specification: This document | ||||
| 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 and email address to contact for further information: See | ||||
| Authors' Addresses section | ||||
| Intended usage: COMMON | ||||
| Restrictions on usage: N/A | ||||
| Author: IETF | ||||
| Change controller: IETF | ||||
| 9. Acknowledgments | ||||
| Many thanks to M. Stenberg and S. Barth for their earlier work: | Many thanks to M. Stenberg and S. Barth for their earlier work: | |||
| [I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was | [I-D.stenberg-mif-mpvd-dns], as well as to Basile Bruneau who was | |||
| author of an early version of this document. | author of an early version of this document. | |||
| Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen | Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen | |||
| Cao, Tim Chow, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer, | Cao, Tim Chown, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer, | |||
| Bob Hinden, Tatuya Jinmei, Erik Kline, Ted Lemon, Jen Lenkova, | Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted | |||
| Veronika McKillop, Mark Townsley and James Woodyatt for useful and | Lemon, Paul Hoffman, Dave Thaler, Suresh Krishnan, Gorry Fairhurst, | |||
| interesting discussions. | Jen Lenkova, Veronika McKillop, Mark Townsley and James Woodyatt for | |||
| useful and interesting discussions and reviews. | ||||
| Finally, special thanks to Thierry Danis and Wenqin Shao for their | Finally, special thanks to Thierry Danis for his valuable inputs and | |||
| valuable inputs and implementation efforts ([github]), Tom Jones for | implementation efforts, Tom Jones for his integration effort into the | |||
| his integration effort into the NEAT project and Rigil Salim for his | NEAT project and Rigil Salim for his implementation work. | |||
| implementation work. | ||||
| 10. References | 10. References | |||
| 10.1. Normative references | 10.1. Normative References | |||
| [RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
| specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
| November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
| [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, | ||||
| DOI 10.17487/RFC1982, August 1996, | ||||
| <https://www.rfc-editor.org/info/rfc1982>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor | ||||
| Discovery for IP Version 6 (IPv6)", RFC 2461, | ||||
| DOI 10.17487/RFC2461, December 1998, | ||||
| <https://www.rfc-editor.org/info/rfc2461>. | ||||
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | |||
| DOI 10.17487/RFC2818, May 2000, | DOI 10.17487/RFC2818, May 2000, | |||
| <https://www.rfc-editor.org/info/rfc2818>. | <https://www.rfc-editor.org/info/rfc2818>. | |||
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: | |||
| 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November | Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, | |||
| 2003, <https://www.rfc-editor.org/info/rfc3629>. | <https://www.rfc-editor.org/info/rfc3339>. | |||
| [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and | ||||
| More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, | ||||
| November 2005, <https://www.rfc-editor.org/info/rfc4191>. | ||||
| [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case | ||||
| Insensitivity Clarification", RFC 4343, | ||||
| DOI 10.17487/RFC4343, January 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4343>. | ||||
| [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, | |||
| "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
| DOI 10.17487/RFC4861, September 2007, | DOI 10.17487/RFC4861, September 2007, | |||
| <https://www.rfc-editor.org/info/rfc4861>. | <https://www.rfc-editor.org/info/rfc4861>. | |||
| [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | |||
| Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March | Extensions for Stateless Address Autoconfiguration in | |||
| 2014, <https://www.rfc-editor.org/info/rfc7159>. | IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, | |||
| <https://www.rfc-editor.org/info/rfc4941>. | ||||
| [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, | ||||
| "Default Address Selection for Internet Protocol Version 6 | ||||
| (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, | ||||
| <https://www.rfc-editor.org/info/rfc6724>. | ||||
| [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation | ||||
| with IPv6 Neighbor Discovery", RFC 6980, | ||||
| DOI 10.17487/RFC6980, August 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6980>. | ||||
| [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, | ||||
| DOI 10.17487/RFC7493, March 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7493>. | ||||
| [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | ||||
| "Recommendations for Secure Use of Transport Layer | ||||
| Security (TLS) and Datagram Transport Layer Security | ||||
| (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | ||||
| 2015, <https://www.rfc-editor.org/info/rfc7525>. | ||||
| [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain | ||||
| Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7556>. | ||||
| [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by | ||||
| Hosts in a Multi-Prefix Network", RFC 8028, | ||||
| DOI 10.17487/RFC8028, November 2016, | ||||
| <https://www.rfc-editor.org/info/rfc8028>. | ||||
| [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
| 10.2. Informative references | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| [github] Cisco, "IPv6-mPvD github repository", | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
| <https://github.com/IPv6-mPvD>. | Interchange Format", STD 90, RFC 8259, | |||
| DOI 10.17487/RFC8259, December 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8259>. | ||||
| [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers | ||||
| (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, | ||||
| <https://www.rfc-editor.org/info/rfc8615>. | ||||
| 10.2. Informative References | ||||
| [I-D.kline-mif-mpvd-api-reqs] | [I-D.kline-mif-mpvd-api-reqs] | |||
| Kline, E., "Multiple Provisioning Domains API | Kline, E., "Multiple Provisioning Domains API | |||
| Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in | Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in | |||
| progress), November 2015. | progress), November 2015. | |||
| [I-D.stenberg-mif-mpvd-dns] | [I-D.stenberg-mif-mpvd-dns] | |||
| Stenberg, M. and S. Barth, "Multiple Provisioning Domains | Stenberg, M. and S. Barth, "Multiple Provisioning Domains | |||
| using Domain Name System", draft-stenberg-mif-mpvd-dns-00 | using Domain Name System", draft-stenberg-mif-mpvd-dns-00 | |||
| (work in progress), October 2015. | (work in progress), October 2015. | |||
| [IEEE8021X] | [IEEE8021X] | |||
| IEEE, "IEEE Standards for Local and Metropolitan Area | IEEE, "IEEE Standards for Local and Metropolitan Area | |||
| Networks: Port based Network Access Control, IEEE Std". | Networks, Port-based Network Access Control, IEEE Std". | |||
| [PEN] IANA, "Private Enterprise Numbers", | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
| <https://www.iana.org/assignments/enterprise-numbers>. | RFC 2131, DOI 10.17487/RFC2131, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2131>. | ||||
| [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: | [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic | |||
| Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, | Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, | |||
| <https://www.rfc-editor.org/info/rfc3339>. | DOI 10.17487/RFC3646, December 2003, | |||
| <https://www.rfc-editor.org/info/rfc3646>. | ||||
| [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | |||
| "SEcure Neighbor Discovery (SEND)", RFC 3971, | "SEcure Neighbor Discovery (SEND)", RFC 3971, | |||
| DOI 10.17487/RFC3971, March 2005, | DOI 10.17487/RFC3971, March 2005, | |||
| <https://www.rfc-editor.org/info/rfc3971>. | <https://www.rfc-editor.org/info/rfc3971>. | |||
| [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and | ||||
| More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, | ||||
| November 2005, <https://www.rfc-editor.org/info/rfc4191>. | ||||
| [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery | [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery | |||
| Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April | Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April | |||
| 2006, <https://www.rfc-editor.org/info/rfc4389>. | 2006, <https://www.rfc-editor.org/info/rfc4389>. | |||
| [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | ||||
| Extensions for Stateless Address Autoconfiguration in | ||||
| IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, | ||||
| <https://www.rfc-editor.org/info/rfc4941>. | ||||
| [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known | ||||
| Uniform Resource Identifiers (URIs)", RFC 5785, | ||||
| DOI 10.17487/RFC5785, April 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5785>. | ||||
| [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. | [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. | |||
| Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, | Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, | |||
| DOI 10.17487/RFC6105, February 2011, | DOI 10.17487/RFC6105, February 2011, | |||
| <https://www.rfc-editor.org/info/rfc6105>. | <https://www.rfc-editor.org/info/rfc6105>. | |||
| [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | ||||
| Verification of Domain-Based Application Service Identity | ||||
| within Internet Public Key Infrastructure Using X.509 | ||||
| (PKIX) Certificates in the Context of Transport Layer | ||||
| Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | ||||
| 2011, <https://www.rfc-editor.org/info/rfc6125>. | ||||
| [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful | [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful | |||
| NAT64: Network Address and Protocol Translation from IPv6 | NAT64: Network Address and Protocol Translation from IPv6 | |||
| Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, | Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, | |||
| April 2011, <https://www.rfc-editor.org/info/rfc6146>. | April 2011, <https://www.rfc-editor.org/info/rfc6146>. | |||
| [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van | [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van | |||
| Beijnum, "DNS64: DNS Extensions for Network Address | Beijnum, "DNS64: DNS Extensions for Network Address | |||
| Translation from IPv6 Clients to IPv4 Servers", RFC 6147, | Translation from IPv6 Clients to IPv4 Servers", RFC 6147, | |||
| DOI 10.17487/RFC6147, April 2011, | DOI 10.17487/RFC6147, April 2011, | |||
| <https://www.rfc-editor.org/info/rfc6147>. | <https://www.rfc-editor.org/info/rfc6147>. | |||
| [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix | [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix | |||
| Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, | Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, | |||
| <https://www.rfc-editor.org/info/rfc6296>. | <https://www.rfc-editor.org/info/rfc6296>. | |||
| [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, | [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., | |||
| "Default Address Selection for Internet Protocol Version 6 | Galperin, S., and C. Adams, "X.509 Internet Public Key | |||
| (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, | Infrastructure Online Certificate Status Protocol - OCSP", | |||
| <https://www.rfc-editor.org/info/rfc6724>. | RFC 6960, DOI 10.17487/RFC6960, June 2013, | |||
| <https://www.rfc-editor.org/info/rfc6960>. | ||||
| [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | ||||
| Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | ||||
| October 2013, <https://www.rfc-editor.org/info/rfc7049>. | ||||
| [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 | [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 | |||
| /64 Prefix from a Third Generation Partnership Project | /64 Prefix from a Third Generation Partnership Project | |||
| (3GPP) Mobile Interface to a LAN Link", RFC 7278, | (3GPP) Mobile Interface to a LAN Link", RFC 7278, | |||
| DOI 10.17487/RFC7278, June 2014, | DOI 10.17487/RFC7278, June 2014, | |||
| <https://www.rfc-editor.org/info/rfc7278>. | <https://www.rfc-editor.org/info/rfc7278>. | |||
| [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain | [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
| Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | |||
| <https://www.rfc-editor.org/info/rfc7556>. | DOI 10.17487/RFC7540, May 2015, | |||
| <https://www.rfc-editor.org/info/rfc7540>. | ||||
| [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by | ||||
| Hosts in a Multi-Prefix Network", RFC 8028, | ||||
| DOI 10.17487/RFC8028, November 2016, | ||||
| <https://www.rfc-editor.org/info/rfc8028>. | ||||
| [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, | [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, | |||
| "IPv6 Router Advertisement Options for DNS Configuration", | "IPv6 Router Advertisement Options for DNS Configuration", | |||
| RFC 8106, DOI 10.17487/RFC8106, March 2017, | RFC 8106, DOI 10.17487/RFC8106, March 2017, | |||
| <https://www.rfc-editor.org/info/rfc8106>. | <https://www.rfc-editor.org/info/rfc8106>. | |||
| [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | |||
| Richardson, M., Jiang, S., Lemon, T., and T. Winters, | Richardson, M., Jiang, S., Lemon, T., and T. Winters, | |||
| "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | |||
| RFC 8415, DOI 10.17487/RFC8415, November 2018, | RFC 8415, DOI 10.17487/RFC8415, November 2018, | |||
| <https://www.rfc-editor.org/info/rfc8415>. | <https://www.rfc-editor.org/info/rfc8415>. | |||
| Appendix A. Changelog | [URN] IANA, "Uniform Resource Names (URN) Namespaces", | |||
| <https://www.iana.org/assignments/urn-namespaces/ | ||||
| Note to RFC Editors: Remove this section before publication. | urn-namespaces.xhtml>. | |||
| A.1. Version 00 | ||||
| Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke | ||||
| and based on Basile's work. | ||||
| A.2. Version 01 | ||||
| Major rewrite intended to focus on the the retained solution based on | ||||
| corridors, online, and WG discussions. Edited by Pierre Pfister. | ||||
| The following list only includes major changes. | ||||
| PvD ID is an FQDN retrieved using a single RA option. This option | ||||
| contains a sequence number for push-based updates, a new H-flag, | ||||
| and a L-flag in order to link the PvD with the IPv4 DHCP server. | ||||
| A lifetime is included in the PvD ID option. | ||||
| Detailed Hosts and Routers specifications. | ||||
| Additional Information is retrieved using HTTP-over-TLS when the | ||||
| PvD ID Option H-flag is set. Retrieving the object is optional. | ||||
| The PvD Additional Information object includes a validity date. | ||||
| DNS-based approach is removed as well as the DNS-based encoding of | ||||
| the PvD Additional Information. | ||||
| Major cut in the list of proposed JSON keys. This document may be | ||||
| extended later if need be. | ||||
| Monetary discussion is moved to the appendix. | ||||
| Clarification about the 'prefixes' contained in the additional | ||||
| information. | ||||
| Clarification about the processing of DHCPv6. | ||||
| A.3. Version 02 | ||||
| The FQDN is now encoded with ASCII format (instead of DNS binary) | ||||
| in the RA option. | ||||
| The PvD ID option lifetime is removed from the object. | ||||
| Use well known URI "https://<PvD-ID>/.well-known/pvd" | ||||
| Reference RFC3339 for JSON timestamp format. | ||||
| The PvD ID Sequence field has been extended to 16 bits. | ||||
| Modified host behavior for DHCPv4 and DHCPv6. | ||||
| Removed IKEv2 section. | ||||
| Removed mention of RFC7710 Captive Portal option. A new I.D. | ||||
| will be proposed to address the captive portal use case. | ||||
| A.4. WG Document version 00 | ||||
| Document has been accepted as INTAREA working group document | ||||
| IANA considerations follow RFC8126 [RFC8126] | ||||
| PvD ID FQDN is encoded as per RFC 1035 [RFC1035] | ||||
| PvD ID FQDN is prepended by a one-byte length field | ||||
| Marcus Keane added as co-author | ||||
| dnsZones key is added back | ||||
| draft of a privacy consideration section and added that a | ||||
| temporary address should be used to retrieve the PvD additional | ||||
| information | ||||
| per Bob Hinden's request: the document is now aiming at standard | ||||
| track and security considerations have been moved to the main | ||||
| section | ||||
| A.5. WG Document version 01 | ||||
| Removing references to 'metered' and 'characteristics' keys. | ||||
| Those may be in scope of the PvD work, but this document will | ||||
| focus on essential parts only. | ||||
| Removing appendix section regarding link quality and billing | ||||
| information. | ||||
| The PvD RA Option may now contain other RA options such that PvD- | ||||
| aware hosts may receive configuration information otherwise | ||||
| invisible to non-PvD-aware hosts. | ||||
| Clarify that the additional PvD Additional Information is not | ||||
| intended to modify host's networking stack behavior, but rather | ||||
| provide information to the Application, used to select which PvDs | ||||
| must be used and provide configuration parameters to the transport | ||||
| layer. | ||||
| The RA option padding is used to increase the option size to the | ||||
| next 64 (was 32) bits boundary. | ||||
| Better detail the Security model and Privacy considerations. | ||||
| A.6. WG Document version 02 | ||||
| Use the IANA value of 21 in the text and update the IANA | ||||
| considerations section accordingly | ||||
| add the Delay field to avoid the thundering herd effect | ||||
| add Wenqin Shao as author | ||||
| keep the 1 PvD per RA model | ||||
| changed the intro (per Zhen Cao) "when choosing which PvD and | ||||
| transport should be used" => "when choosing which PvD should be | ||||
| used" | ||||
| rename A-flag in R-flag to avoid A-flag of PIO | ||||
| use the wording "PvD Option", removing the ID token as it is now a | ||||
| container with more then just an ID, removing 'RA' in the option | ||||
| name to be consistent with other IANA NDP option | ||||
| use "non-PvD-aware" rather than "PvD-ignorant" | ||||
| added more reference to RFC 7556 (notably for PvD being globally | ||||
| unique, introducing PvD-aware host vs. PvD-aware node) | ||||
| Section 3.4.3 renamed from "interconnection shared by node" to | ||||
| 'connection shared by node" | ||||
| Section 3.4 renamed into "PvD-aware Host Behavior" | ||||
| Added a section "Non-PvD-aware Host Behavior" | ||||
| A.7. WG Document version 04 | ||||
| Updated reference for DHCPv6-PD from RFC 3633 to RFC 8415. | ||||
| Enhanced IANA considerations to clarify review process and new | ||||
| registries. | ||||
| Added a section on considerations for handling DNS on a PvD-aware | ||||
| host. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Pierre Pfister | Pierre Pfister | |||
| Cisco | Cisco | |||
| 11 Rue Camille Desmoulins | 11 Rue Camille Desmoulins | |||
| Issy-les-Moulineaux 92130 | Issy-les-Moulineaux 92130 | |||
| France | France | |||
| Email: ppfister@cisco.com | Email: ppfister@cisco.com | |||
| Eric Vyncke (editor) | Eric Vyncke | |||
| Cisco | Cisco | |||
| De Kleetlaan, 6 | De Kleetlaan, 6 | |||
| Diegem 1831 | Diegem 1831 | |||
| Belgium | Belgium | |||
| Email: evyncke@cisco.com | Email: evyncke@cisco.com | |||
| Tommy Pauly | Tommy Pauly | |||
| Apple | Apple Inc. | |||
| One Apple Park Way | ||||
| Cupertino, California 95014 | ||||
| United States of America | ||||
| Email: tpauly@apple.com | Email: tpauly@apple.com | |||
| David Schinazi | David Schinazi | |||
| Google LLC | Google LLC | |||
| 1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
| Mountain View, California 94043 | Mountain View, California 94043 | |||
| USA | United States of America | |||
| Email: dschinazi.ietf@gmail.com | Email: dschinazi.ietf@gmail.com | |||
| Wenqin Shao | Wenqin Shao | |||
| Cisco | Cisco | |||
| 11 Rue Camille Desmoulins | 11 Rue Camille Desmoulins | |||
| Issy-les-Moulineaux 92130 | Issy-les-Moulineaux 92130 | |||
| France | France | |||
| Email: wenshao@cisco.com | Email: wenshao@cisco.com | |||
| End of changes. 151 change blocks. | ||||
| 668 lines changed or deleted | 980 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||