| < draft-ietf-intarea-provisioning-domains-10.txt | draft-ietf-intarea-provisioning-domains-11.txt > | |||
|---|---|---|---|---|
| Network Working Group P. Pfister | Network Working Group P. Pfister | |||
| Internet-Draft E. Vyncke | Internet-Draft E. Vyncke | |||
| Intended status: Standards Track Cisco | Intended status: Standards Track Cisco | |||
| Expires: July 9, 2020 T. Pauly | Expires: August 3, 2020 T. Pauly | |||
| Apple Inc. | Apple Inc. | |||
| D. Schinazi | D. Schinazi | |||
| Google LLC | Google LLC | |||
| W. Shao | W. Shao | |||
| Cisco | Cisco | |||
| January 06, 2020 | January 31, 2020 | |||
| Discovering Provisioning Domain Names and Data | Discovering Provisioning Domain Names and Data | |||
| draft-ietf-intarea-provisioning-domains-10 | draft-ietf-intarea-provisioning-domains-11 | |||
| Abstract | Abstract | |||
| Provisioning Domains (PvDs) are defined as consistent sets of network | Provisioning Domains (PvDs) are defined as consistent sets of network | |||
| configuration information. This allows hosts to manage connections | configuration information. This allows hosts to manage connections | |||
| to multiple networks and interfaces simultaneously, such as when a | to multiple networks and interfaces simultaneously, such as when a | |||
| home router provides connectivity through both a broadband and | home router provides connectivity through both a broadband and | |||
| cellular network provider. | cellular network provider. | |||
| This document defines a mechanism for explicitly identifying PvDs | This document defines a mechanism for explicitly identifying PvDs | |||
| skipping to change at page 1, line 47 ¶ | skipping to change at page 1, line 47 ¶ | |||
| 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 July 9, 2020. | This Internet-Draft will expire on August 3, 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2020 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 | |||
| skipping to change at page 2, line 38 ¶ | skipping to change at page 2, line 38 ¶ | |||
| 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 | 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 9 | 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 9 | |||
| 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 9 | 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 9 | |||
| 3.4.1. DHCPv6 configuration association . . . . . . . . . . 10 | 3.4.1. DHCPv6 configuration association . . . . . . . . . . 10 | |||
| 3.4.2. DHCPv4 configuration association . . . . . . . . . . 11 | 3.4.2. DHCPv4 configuration association . . . . . . . . . . 11 | |||
| 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 11 | 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 11 | |||
| 3.4.4. Usage of DNS Servers . . . . . . . . . . . . . . . . 12 | 3.4.4. Usage of DNS Servers . . . . . . . . . . . . . . . . 12 | |||
| 4. Provisioning Domain Additional Information . . . . . . . . . 13 | 4. Provisioning Domain Additional Information . . . . . . . . . 13 | |||
| 4.1. Retrieving the PvD Additional Information . . . . . . . . 13 | 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 . . . . . . . . . . . . . . . . . . . . . . . 15 | Information . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 4.3. PvD Additional Information Format . . . . . . . . . . . . 15 | 4.3. PvD Additional Information Format . . . . . . . . . . . . 16 | |||
| 4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 17 | 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 18 | |||
| 5. Operational Considerations . . . . . . . . . . . . . . . . . 18 | 5. Operational Considerations . . . . . . . . . . . . . . . . . 19 | |||
| 5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 18 | 5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 19 | |||
| 5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts . . . 18 | 5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts . . . 19 | |||
| 5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 20 | 5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 21 | |||
| 5.4. Providing Additional Information to PvD-Aware Hosts . . . 21 | 5.4. Providing Additional Information to PvD-Aware Hosts . . . 22 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
| 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 | 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 8.1. New entry in the Well-Known URIs Registry . . . . . . . . 23 | 8.1. New entry in the Well-Known URIs Registry . . . . . . . . 26 | |||
| 8.2. Additional Information PvD Keys Registry . . . . . . . . 24 | 8.2. Additional Information PvD Keys Registry . . . . . . . . 26 | |||
| 8.3. PvD Option Flags Registry . . . . . . . . . . . . . . . . 24 | 8.3. PvD Option Flags Registry . . . . . . . . . . . . . . . . 26 | |||
| 8.4. PvD JSON Media Type Registration . . . . . . . . . . . . 24 | 8.4. PvD JSON Media Type Registration . . . . . . . . . . . . 27 | |||
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 27 | 10.2. Informative References . . . . . . . . . . . . . . . . . 30 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 1. Introduction | 1. Introduction | |||
| Provisioning Domains (PvDs) are defined in [RFC7556] as consistent | Provisioning Domains (PvDs) are defined in [RFC7556] as consistent | |||
| sets of network configuration information. This information includes | sets of network configuration information. This information includes | |||
| properties that are traditionally associated with a single networking | properties that are traditionally associated with a single networking | |||
| interface, such as source addresses, DNS configuration, proxy | interface, such as source addresses, DNS configuration, proxy | |||
| configuration, and gateway addresses. | configuration, and gateway addresses. | |||
| Clients that are aware of PvDs can take advantage of multiple network | Clients that are aware of PvDs can take advantage of multiple network | |||
| skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 15 ¶ | |||
| hosts to have a specialized view of the network configuration. | 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) can 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 equivalent services. | ultimately provide equivalent services. | |||
| This document also introduces a mechanism for hosts to retrieve | This document also introduces a mechanism for hosts to retrieve | |||
| optional additional information related to a specific PvD by means of | optional additional information related to a specific PvD by means of | |||
| an HTTP over TLS query using an URI derived from the PvD ID. The | an HTTP over TLS query using a URI derived from the PvD ID. The | |||
| retrieved JSON object contains additional information that would | retrieved JSON object contains additional information that would | |||
| typically be considered too large to be directly included in the | typically be considered too large to be directly included in the | |||
| Router Advertisement, but might be considered useful to the | Router Advertisement, but might be considered useful to the | |||
| applications, or even sometimes users, when choosing which PvD should | applications, or even sometimes users, when choosing which PvD should | |||
| be used. | be used. | |||
| For example, if Alice has both a cellular network provider and a | For example, if Alice has both a cellular network provider and a | |||
| broadband provider in her home, her PvD-aware devices and | broadband provider in her home, her PvD-aware devices and | |||
| applications would be aware of both available uplinks. These | applications would be aware of both available uplinks. These | |||
| applications could fail-over between these networks, or run | applications could fail-over between these networks, or run | |||
| skipping to change at page 6, line 41 ¶ | skipping to change at page 6, line 41 ¶ | |||
| included within the PvD Option. | included within the PvD Option. | |||
| H-flag: (1 bit) 'HTTP' flag stating whether some PvD Additional | H-flag: (1 bit) 'HTTP' flag stating whether some PvD Additional | |||
| Information is made available through HTTP over TLS, as described | Information is made available through HTTP over TLS, as described | |||
| in Section 4. | in Section 4. | |||
| L-flag: (1 bit) 'Legacy' flag stating whether the PvD is associated | L-flag: (1 bit) 'Legacy' flag stating whether the PvD is associated | |||
| with IPv4 information assigned 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 the PvD | R-flag: (1 bit) 'Router Advertisement' flag stating whether the PvD | |||
| Option is followed (right after padding to the next 64 bits | Option header is followed (right after padding to the next 64 bits | |||
| boundary) by a Router Advertisement message header (see section | boundary) by a Router Advertisement message header (see section | |||
| 4.2 of [RFC4861]). The usage of the inner message header is | 4.2 of [RFC4861]). The usage of the inner message header is | |||
| described in Section 3.4. | described in Section 3.4. | |||
| Reserved: (13 bits) Reserved for later use. It MUST be set to zero | Reserved: (13 bits) Reserved for later use. It MUST be set to zero | |||
| by the sender and ignored by the receiver. | by the sender and ignored by the receiver. | |||
| Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from | Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from | |||
| hosts by a randomized backoff (see Section 4.1). | 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 name 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 octet boundary | Padding: Zero or more padding octets to the next 8 octet boundary | |||
| (see Section 4.6 of [RFC4861]). It MUST be set to zero by the | (see Section 4.6 of [RFC4861]). It MUST be set to zero by the | |||
| sender, and ignored by the receiver. | sender, and ignored by the receiver. | |||
| RA message header: (16 octets) When the R-flag is set, a full Router | RA message header: (16 octets) When the R-flag is set, a full Router | |||
| skipping to change at page 7, line 35 ¶ | skipping to change at page 7, line 37 ¶ | |||
| 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 so 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. | |||
| Figure 2 shows an example of a PvD Option with "example.org" as the | Figure 2 shows an example of a PvD Option with "example.org" as the | |||
| PvD ID FQDN and including both a Recursive DNS Server (RDNSS) option | PvD ID FQDN and including both a Recursive DNS Server (RDNSS) option | |||
| and a prefix information option. It has a Sequence Number of 123, | and a prefix information option. It has a Sequence Number of 123, | |||
| and indicates the presence of additional information that is expected | and indicates the presence of additional information that is expected | |||
| to be fetched with a delay factor of 5. | 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) | | |||
| skipping to change at page 8, line 43 ¶ | skipping to change at page 8, line 43 ¶ | |||
| 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. The PvD Option MUST NOT contain | more than one PvD Option in each RA. The PvD Option 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 other hosts as per | processed by PvD-aware hosts, while ignored by other hosts as per | |||
| section 4.2 of [RFC4861]. | 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. If more than one different Implicit PvD is advertised, | multiple RAs. RAs sent from different link-local source addresses | |||
| the RAs MUST be sent from different link-local source addresses. | establish distinct implicit PvDs, in the absence of a PvD Option. | |||
| Explicit PvDs MAY share link-local source addresses with an Implicit | Explicit PvDs MAY share link-local source addresses with an Implicit | |||
| PvD and any number of other Explicit PvDs. | PvD and any number of other Explicit PvDs. | |||
| In other words, different Explicit PvDs MAY be advertised with RAs | In other words, different Explicit PvDs MAY be advertised with RAs | |||
| using the same link-local source address; but different Implicit | using the same link-local source address; but different Implicit | |||
| PvDs, advertised by different RAs, MUST use different link-local | PvDs, advertised by different RAs, MUST use different link-local | |||
| addresses because these Implicit PvDs are identified by the source | addresses because these Implicit PvDs are identified by the source | |||
| addresses of the RAs. If a link-local address on the router is | addresses of the RAs. If a link-local address on the router is | |||
| changed, then any new RA will be interpreted as a different Implicit | changed, then any new RA will be interpreted as a different Implicit | |||
| PvD by PvD-aware hosts. | PvD by PvD-aware hosts. | |||
| skipping to change at page 9, line 34 ¶ | skipping to change at page 9, line 34 ¶ | |||
| 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. If an RA message header is present both | received RA otherwise. If an RA message header is present both | |||
| within the PvD Option and outside it, as indicated by the R-flag, the | within the PvD Option and outside it, the header within the PvD | |||
| header within the PvD Option takes precedence. | 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 as defined by | PvD IDs MUST be compared in a case-insensitive manner as defined by | |||
| [RFC4343]. For example, "pvd.example.com." or "PvD.Example.coM." | [RFC4343]. For example, "pvd.example.com." or "PvD.Example.coM." | |||
| would refer to the same PvD. | would refer to the same PvD. | |||
| While resolving names, executing the default address selection | While performing PvD-specific operations such as resolving names, | |||
| algorithm [RFC6724] or executing the default router selection | executing the default address selection algorithm [RFC6724] or | |||
| algorithm when forwarding packets ([RFC4861], [RFC4191] and | executing the default router selection algorithm when forwarding | |||
| [RFC8028]), hosts and applications MAY consider only the | packets ([RFC4861], [RFC4191] and [RFC8028]), hosts and applications | |||
| configuration associated with any non-empty subset of PvDs. | MAY consider only the configuration associated with any non-empty | |||
| subset of PvDs. For example, a host MAY associate a given process | ||||
| For example, a host MAY associate a given process with a specific | with a specific PvD, or a specific set of PvDs, while associating | |||
| PvD, or a specific set of PvDs, while associating another process | another process with another PvD. A PvD-aware application might also | |||
| with another PvD. A PvD-aware application might also be able to | be able to select, on a per-connection basis, which PvDs should be | |||
| select, on a per-connection basis, which PvDs should be used. In | used. In particular, constrained devices such as small battery | |||
| particular, constrained devices such as small battery operated | operated devices (e.g., IoT), or devices with limited CPU or memory | |||
| devices (e.g., IoT), or devices with limited CPU or memory resources | resources may purposefully use a single PvD while ignoring some | |||
| may purposefully use a single PvD while ignoring some received RAs | received RAs containing different PvD IDs. | |||
| 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 stateless configuration elements using DHCPv6 | When a host retrieves stateless configuration elements using DHCPv6 | |||
| (e.g., DNS recursive resolvers or DNS domain search lists [RFC3646]), | (e.g., DNS recursive resolvers or DNS domain search lists [RFC3646]), | |||
| skipping to change at page 10, line 48 ¶ | skipping to change at page 10, line 47 ¶ | |||
| assignments MUST be associated with the received PvD which was | assignments MUST be associated with the received PvD which was | |||
| received with RAs with the M-flag set and including a matching PIO. | received with RAs with the M-flag set and including a matching PIO. | |||
| A PIO is considered to match a DHCPv6 assignment when the IPv6 prefix | A PIO is considered to match a DHCPv6 assignment when the IPv6 prefix | |||
| from the PIO includes the assignment from DHCPv6. For example, if a | 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 | 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 | IA_NA message that assigns the address 2001:db8:cafe::1234:4567 would | |||
| be considered to match. | be considered to match. | |||
| In cases where an address would be assigned by DHCPv6 and no matching | 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 | PvD could be found, hosts MAY associate the assigned address with any | |||
| implicit PvD received on the same interface or to multiple of | implicit PvD received on the same interface or to multiple implicit | |||
| implicit PvD received on the same interface. This is intended to | PvDs received on the same interface. This is intended to resolve | |||
| resolve backward compatibility issues with rare deployments choosing | backward compatibility issues with rare deployments choosing to | |||
| to assign addresses with DHCPv6 while not sending any matching PIO. | 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 | |||
| Associating DHCPv4 [RFC2131] configuration elements with Explicit | Associating DHCPv4 [RFC2131] configuration elements with Explicit | |||
| PvDs allows hosts to treat a set of IPv4 and IPv6 configurations as a | PvDs allows hosts to treat a set of IPv4 and IPv6 configurations as a | |||
| single PvD with shared properties. For example, consider a router | single PvD with shared properties. For example, consider a router | |||
| that provides two different uplinks. One could be a broadband | that provides two different uplinks. One could be a broadband | |||
| network that has data rate and streaming properties described in PvD | network that has data rate and streaming properties described in PvD | |||
| additional information and that provides both IPv4 and IPv6 network | additional information and that provides both IPv4 and IPv6 network | |||
| access. The other could be a cellular network that provides only | access. The other could be a cellular network that provides only | |||
| skipping to change at page 12, line 20 ¶ | skipping to change at page 12, line 20 ¶ | |||
| 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 recursive DNS server addresses SHOULD be | In all of these cases, the recursive DNS server addresses SHOULD be | |||
| associated with the corresponding PvD. Specifically, queries sent to | associated with the corresponding PvD. Specifically, queries sent 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 was provisioned by the PvD via RA or DHCP. Answers | address that was provisioned for the PvD via RA or DHCP. Answers | |||
| received from the 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 | PvD-aware applications will be able to select which PvD(s) to use for | |||
| DNS resolution and connections, which allows them to effectively use | DNS resolution and connections, which allows them to effectively use | |||
| multiple Explicit PvDs. In order to support non-PvD-aware | multiple Explicit PvDs. In order to support non-PvD-aware | |||
| applications, however, PvD-aware hosts SHOULD ensure that non-PvD- | applications, however, PvD-aware hosts SHOULD ensure that non-PvD- | |||
| aware name resolution APIs like "getaddrinfo" only use resolvers from | aware name resolution APIs like "getaddrinfo" only use resolvers from | |||
| a single PvD for each query. Handling DNS across PvDs is discussed | a single PvD for a given query. Handling DNS across PvDs is | |||
| in Section 5.2.1 of [RFC7556], and PvD APIs are discussed in | discussed in Section 5.2.1 of [RFC7556], and PvD APIs are discussed | |||
| Section 6 of [RFC7556]. | 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: | |||
| o 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. This includes the DNS queries to retrieve PvD | another PvD. This includes the DNS queries to retrieve PvD | |||
| additional information, which could otherwise send identifying | additional information, which could otherwise send identifying | |||
| information to the recursive DNS system (see Section 4.1). | information to the recursive DNS system (see Section 4.1). | |||
| skipping to change at page 13, line 10 ¶ | skipping to change at page 13, line 10 ¶ | |||
| synthesize IPv6 addresses in DNS answers that are not globally | synthesize IPv6 addresses in DNS answers that are not globally | |||
| routable, and would be invalid 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. | 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 [RFC8259]. | Additional Information, and is encoded as a JSON object [RFC8259]. | |||
| This JSON object is restricted to the restricted profile of I-JSON, | This JSON object is restricted to the I-JSON profile, as defined in | |||
| as defined in [RFC7493]. | [RFC7493]. | |||
| The purpose of this JSON object is to provide additional information | The purpose of this JSON object is to provide additional information | |||
| to applications on a client host about the connectivity that is | to applications on a client host about the connectivity that is | |||
| provided using a given interface and source address. It typically | provided using a given interface and source address. It typically | |||
| includes data that would be considered too large, or not critical | includes data that would be considered too large, or not 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. | |||
| skipping to change at page 13, line 44 ¶ | skipping to change at page 13, line 44 ¶ | |||
| document. | 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. Inversely, hosts MUST NOT do so whenever the | ID>/.well-known/pvd. Inversely, hosts MUST NOT do so whenever the | |||
| H-flag is not set. | H-flag is not set. | |||
| Recommendations for how to use TLS securely can be found in | ||||
| [RFC7525]. | ||||
| When a host retrieves the PvD Additional Information, it MUST verify | ||||
| that the TLS server certificate is valid for the performed request; | ||||
| specifically, that a DNS-ID [RFC6125] on the certificate is equal to | ||||
| the PvD ID expressed as an FQDN. This validation indicates that the | ||||
| owner of the FQDN authorizes its use with the prefix advertised by | ||||
| the router. If this validation fails, hosts MUST close the | ||||
| connection and treat the PvD as if it has no Additional Information. | ||||
| HTTP requests and responses for PvD additional information use the | HTTP requests and responses for PvD additional information use the | |||
| "application/pvd+json" media type (see Section 8). Clients SHOULD | "application/pvd+json" media type (see Section 8). Clients SHOULD | |||
| include this media type as an Accept header in their GET requests, | include this media type as an Accept header field in their GET | |||
| and servers MUST mark this media type as their Content-Type header in | requests, and servers MUST mark this media type as their Content-Type | |||
| responses. | header field in responses. | |||
| Note that the DNS name resolution of the PvD ID, the PKI (Public Key | Note that the DNS name resolution of the PvD ID, any connections made | |||
| Infrastructure) checks as well as the actual query MUST be performed | for certficate validation (such as OCSP [RFC6960]), and the HTTP | |||
| using the considered PvD. In other words, the name resolution, PKI | request itself MUST be performed using the considered PvD. In other | |||
| checks, source address selection, as well as the next-hop router | words, the name resolution, PKI checks, source address selection, as | |||
| selection MUST be performed while using exclusively the set of | well as the next-hop router selection MUST be performed while using | |||
| configuration information attached with the PvD, as defined in | exclusively the set of configuration information attached with the | |||
| Section 3.4. In some cases, it may therefore be necessary to wait | PvD, as defined in Section 3.4. In some cases, it may therefore be | |||
| for an address to be available for use (e.g., once the Duplicate | necessary to wait for an address to be available for use (e.g., once | |||
| Address Detection or DHCPv6 processes are complete) before initiating | the Duplicate Address Detection or DHCPv6 processes are complete) | |||
| the HTTP over TLS query. In order to address privacy concerns around | before initiating the HTTP over TLS query. In order to address | |||
| linkability of the PvD HTTP connection with future user-initiated | privacy concerns around linkability of the PvD HTTP connection with | |||
| connections, if the host has a temporary address per [RFC4941] in | future user-initiated connections, if the host has a temporary | |||
| this PvD, then it SHOULD use a temporary address to fetch the PvD | address per [RFC4941] in this PvD, then it SHOULD use a temporary | |||
| Additional Information and MAY deprecate the used temporary address | address to fetch the PvD Additional Information and MAY deprecate the | |||
| and generate a new temporary address afterward. | 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. | the response is expected to be a single JSON object. | |||
| After retrieval of the PvD Additional Information, hosts MUST | After retrieval of the PvD Additional Information, hosts MUST | |||
| remember the last Sequence Number value received in the RA including | remember the last Sequence Number value received in an RA including | |||
| the same PvD ID. Whenever a new RA for the same PvD is received with | the same PvD ID. Whenever a new RA for the same PvD is received with | |||
| a different Sequence Number value, or whenever the expiry date for | a different Sequence Number value, or whenever the expiry date for | |||
| the additional information is reached, hosts MUST deprecate the | the additional information is reached, hosts MUST deprecate the | |||
| additional information and stop using it until a new JSON object is | additional information and stop using it. | |||
| retrieved. | ||||
| 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. | |||
| o When a host performs a JSON object update after it detected a | o When a host performs a JSON object update after it detected a | |||
| change in the PvD Option Sequence Number, it MUST add a delay | change in the PvD Option Sequence Number, it MUST add a delay | |||
| before sending the query. The target time for the delay is | before sending the query. The target time for the delay is | |||
| calculated as a random time between zero and 2**(Delay * 2) | calculated as a random time between zero and 2**(10 + Delay) | |||
| milliseconds, where 'Delay' corresponds to the 4-bit unsigned | milliseconds, where 'Delay' corresponds to the 4-bit unsigned | |||
| integer in the last received PvD Option. | integer in the last received PvD Option. | |||
| o When a host last retrieved a JSON object at time A that includes a | o When a host last retrieved a JSON object at time A that includes a | |||
| expiry time B using the "expires" key, and the host is configured | expiry time B using the "expires" key, and the host is configured | |||
| to keep the PvD information up to date, it MUST add some | to keep the PvD information up to date, it MUST add some | |||
| randomness into its calculation of the time to fetch the update. | randomness into its calculation of the time to fetch the update. | |||
| The target time for fetching the updated object is calculated as a | The target time for fetching the updated object is calculated as a | |||
| uniformly random time in the interval [(B-A)/2,B]. | 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 | |||
| the host calculates its delay by choosing a random number between 0 | the host calculates its delay by choosing a uniformly random time | |||
| and 2**(5 * 2) 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 any associated PIO is not covered by at least | prefixes included in any associated PIO is not covered by at least | |||
| one of the listed prefixes, the associated PvD information MUST be | one of the listed prefixes, the associated PvD information MUST be | |||
| considered to be a misconfiguration, and MUST NOT be used by the | considered to be a misconfiguration, and MUST NOT be used by the | |||
| host. See Section 4.4 for more discussion on handling such | host. See Section 4.4 for more discussion on handling such | |||
| misconfigurations. | 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 SHOULD increment the PVD Option Sequence Number by one | Routers SHOULD increment the PVD Option Sequence Number by one | |||
| whenever a new PvD Additional Information object is available and | whenever a new PvD Additional Information object is available and | |||
| should be retrieved by hosts. If the value exceeds what can be | should be retrieved by hosts. If the value exceeds what can be | |||
| stored in the Sequence Number field, it SHOULD wrap back to zero. | 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 | | |||
| +------------+-----------------+-----------+------------------------+ | +------------+-----------------+-----------+------------------------+ | |||
| | identifier | PvD ID FQDN | String | "pvd.example.com." | | | identifier | PvD ID FQDN | String | "pvd.example.com." | | |||
| | | | | | | | | | | | | |||
| | expires | Date after | [RFC3339] | "2017-07-23T06:00:00Z" | | | expires | Date after | [RFC3339] | "2020-05-23T06:00:00Z" | | |||
| | | which this | Date | | | | | which this | Date | | | |||
| | | object is no | | | | | | object is no | | | | |||
| | | longer valid | | | | | | longer 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 all three of these keys at | A retrieved object which does not include all three of these keys at | |||
| skipping to change at page 16, line 32 ¶ | skipping to change at page 17, line 32 ¶ | |||
| be validated, otherwise the object MUST be ignored. The value stored | be validated, otherwise the object MUST be ignored. The value stored | |||
| for "identifier" MUST be matched against the PvD ID FQDN presented in | for "identifier" MUST be matched against the PvD ID FQDN presented in | |||
| the PvD RA option using the comparison mechanism described in | the PvD RA option using the comparison mechanism described in | |||
| Section 3.4. The value stored for "expires" MUST be a valid date in | Section 3.4. The value stored for "expires" MUST be a valid date in | |||
| the future. If the PIO of the received RA is not covered by at least | 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. | 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 | | |||
| +------------+----------------------+----------+--------------------+ | +------------+-----------------------+---------+--------------------+ | |||
| | dnsZones | DNS zones searchable | Array of | ["example.com", | | | dnsZones | DNS zones searchable | Array | ["example.com", | | |||
| | | and accessible | strings | | | | | and accessible | of | "sub.example.com"] | | |||
| | | | | | | | | | strings | | | |||
| | | | | "sub.example.com"] | | | | | | | | |||
| | | | | | | | noInternet | No Internet, set to | Boolean | true | | |||
| | noInternet | No Internet, set | Boolean | true | | | | "true" when the PvD | | | | |||
| | | when the PvD is | | | | | | is restricted. | | | | |||
| | | restricted. | | | | +------------+-----------------------+---------+--------------------+ | |||
| +------------+----------------------+----------+--------------------+ | ||||
| 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. | |||
| Private-use or experimental keys MAY be used in the JSON dictionary. | Private-use or experimental keys MAY be used in the JSON dictionary. | |||
| In order to avoid such keys colliding with IANA registry keys, | In order to avoid such keys colliding with IANA registry keys, | |||
| implementers or vendors defining private-use or experimental keys | implementers or vendors defining private-use or experimental keys | |||
| MUST create sub-dictionaries, where the sub-dictionary is added into | MUST create sub-dictionaries. If a set of PvD Additional Information | |||
| the top-level JSON dictionary with a key of the format "vendor-*" | keys are defined by an organization that has a Formal URN Namespace | |||
| where the "*" is replaced by the implementer's or vendor's | [URN], the URN namespace SHOULD be used as the top-level JSON key for | |||
| identifier. For example, keys specific to the FooBar organization | the sub-dictionary. For other private uses, the sub-dictionary key | |||
| could use "vendor-foobar". Upon receiving such a sub-dictionary, | SHOULD follow the format of "vendor-*", where the "*" is replaced by | |||
| host MUST ignore this sub-dictionary if it is unknown. When the | the implementer's or vendor's identifier. For example, keys specific | |||
| vendor or implementer is part of an IANA URN namespace [URN], the URN | to the FooBar organization could use "vendor-foobar". If a host | |||
| namespace SHOULD be used rather than the "vendor-*" format. | receives a sub-dictionary with an unknown key, the host MUST ignore | |||
| the contents of the sub-dictionary. | ||||
| 4.3.1. Example | 4.3.1. Example | |||
| The following two examples show how the JSON keys defined in this | The following two examples show how the JSON keys defined in this | |||
| document can be used: | document can be used: | |||
| { | { | |||
| "identifier": "cafe.example.com", | "identifier": "cafe.example.com.", | |||
| "expires": "2017-07-23T06:00:00Z", | "expires": "2020-05-23T06:00:00Z", | |||
| "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | |||
| } | } | |||
| { | { | |||
| "identifier": "company.foo.example.com", | "identifier": "company.foo.example.com.", | |||
| "expires": "2017-07-23T06:00:00Z", | "expires": "2020-05-23T06:00:00Z", | |||
| "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | |||
| "vendor-foo": | "vendor-foo": | |||
| { | { | |||
| "private-key": "private-value", | "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 Alternative 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 all the RA PIOs are covered by | Hosts MUST verify that all prefixes in all the RA PIOs are covered by | |||
| a prefix from the PvD Additional Information. An adversarial router | a prefix from the PvD Additional Information. An adversarial router | |||
| attempting to spoof the definition of an Explicit PvD, without the | attempting to spoof the definition of an Explicit PvD, without the | |||
| ability to modify the PvD Additional Information, would need to | ability to modify the PvD Additional Information, would need to | |||
| perform NAT66 in order to circumvent this check. Thus, this check | perform NAT66 in order to circumvent this check. Thus, this check | |||
| cannot prevent all spoofing, but it can detect misconfiguration or | cannot prevent all spoofing, but it can detect misconfiguration or | |||
| mismatched routers that are not adding a NAT. | mismatched routers that are not adding a NAT. | |||
| If NAT66 is being added in order to spoof PvD ownership, the HTTPS | If NAT66 is being added in order to spoof PvD ownership, the HTTPS | |||
| skipping to change at page 18, line 20 ¶ | skipping to change at page 19, line 15 ¶ | |||
| information to the valid network users. If the PvD does not | information to the valid network users. If the PvD does not | |||
| provision IPv4 (it does not include the 'L' bit in the RA), the | provision IPv4 (it does not include the 'L' bit in the RA), the | |||
| server cannot validate the source addresses of connections using | server cannot validate the source addresses of connections using | |||
| IPv4. Thus, the PvD ID FQDN for such PvDs SHOULD NOT have a DNS A | IPv4. Thus, the PvD ID FQDN for such PvDs SHOULD NOT have a DNS A | |||
| record. | record. | |||
| 5. Operational Considerations | 5. Operational Considerations | |||
| This section describes some example use cases of PvDs. For the sake | This section describes some example use cases of PvDs. For the sake | |||
| of simplicity, the RA messages will not be described in the usual | of simplicity, the RA messages will not be described in the usual | |||
| ASCII art but rather in an indented list. | ASCII art but rather in an indented list. Values in the PvD Option | |||
| header that are not included in the example are assumed to be zero or | ||||
| false (such as the H-flag, Sequence Number, and Delay fields). | ||||
| 5.1. Exposing Extra RA Options to PvD-Aware Hosts | 5.1. Exposing Extra RA Options to PvD-Aware Hosts | |||
| In this example, there is one RA message sent by the router. This | In this example, there is one RA message sent by the router. This | |||
| message contains some options applicable to all hosts on the network, | message contains some options applicable to all hosts on the network, | |||
| and also a PvD Option that also contains other options only visible | and also a PvD Option that also contains other options only visible | |||
| to PvD-aware hosts. | to PvD-aware hosts. | |||
| o RA Header: router lifetime = 6000 | o RA Header: router lifetime = 6000 | |||
| skipping to change at page 19, line 46 ¶ | skipping to change at page 20, line 44 ¶ | |||
| * 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 address. | 2001:db8:f00d::53 when communicating from this address. | |||
| 5.3. Enabling Multi-homing for PvD-Aware Hosts | 5.3. Enabling Multi-homing for PvD-Aware Hosts | |||
| In this example, the goal is to have one prefix from one RA be usable | 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 | 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 | usable only by PvD-aware hosts. This allows PvD-aware hosts to be | |||
| able to effectively multi-home on the network. | able to effectively multi-home on the network. | |||
| The first RA is usable by all hosts. The only difference for PvD- | The first RA is usable by all hosts. The only difference for PvD- | |||
| aware hosts is that they can explicitly identify the PvD ID | aware hosts is that they can explicitly identify the PvD ID | |||
| skipping to change at page 21, line 28 ¶ | skipping to change at page 22, line 24 ¶ | |||
| 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, PvD ID FQDN = cafe.example.com., | 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 | Sequence Number = 7, R-flag = 0, H-flag = 1 (actual length of the | |||
| header with padding 24 bytes = 3 * 8 bytes) | header with padding 24 bytes = 3 * 8 bytes) | |||
| A PvD-aware host will fetch https://cafe.example.com/.well-known/pvd | A PvD-aware host will fetch https://cafe.example.com/.well-known/pvd | |||
| to get the additonal information. The following example shows a GET | to get the additonal information. The following example shows a GET | |||
| request that the host sends: | request that the host sends, in HTTP/2 syntax [RFC7540]: | |||
| :method = GET | :method = GET | |||
| :scheme = https | :scheme = https | |||
| :authority = cafe.example.com | :authority = cafe.example.com | |||
| :path = /.well-known/pvd | :path = /.well-known/pvd | |||
| accept = application/pvd+json | accept = application/pvd+json | |||
| The HTTP server will respond with the JSON additional information: | The HTTP server will respond with the JSON additional information: | |||
| :status = 200 | :status = 200 | |||
| content-type = application/pvd+json | content-type = application/pvd+json | |||
| content-length = 116 | content-length = 116 | |||
| { | { | |||
| "identifier": "cafe.example.com", | "identifier": "cafe.example.com.", | |||
| "expires": "2017-07-23T06:00:00Z", | "expires": "2020-05-23T06:00:00Z", | |||
| "prefixes": ["2001:db8:cafe::/48"], | "prefixes": ["2001:db8:cafe::/48"], | |||
| } | } | |||
| At this point, the host has the additional information, and knows the | At this point, the host has the additional information, and knows the | |||
| expiry time. When either the expiry time passes, or a new Sequence | 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 | Number is provided in an RA, the host will re-fetch the additional | |||
| information. | information. | |||
| For example, if the router sends a new RA with the Sequence Number | For example, if the router sends a new RA with the Sequence Number | |||
| set to 8, the host will re-fetch the additional information: | set to 8, the host will re-fetch the additional information: | |||
| skipping to change at page 22, line 19 ¶ | skipping to change at page 23, line 16 ¶ | |||
| cafe.example.com., Sequence Number = 8, R-flag = 0, H-flag = 1 | cafe.example.com., Sequence Number = 8, R-flag = 0, H-flag = 1 | |||
| (actual length of the header with padding 24 bytes = 3 * 8 bytes) | (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 | However, if the router sends a new RA, but the Sequence Number has | |||
| not changed, the host would not re-fetch the additional information | not changed, the host would not re-fetch the additional information | |||
| (until and unless the expiry time of the additional information has | (until and unless the expiry time of the additional information has | |||
| passed). | 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 advertise wrong information that | hostile network access provider from advertising incorrect | |||
| could lead applications or hosts to select a hostile PvD. | information that could lead applications or hosts to select a hostile | |||
| 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. | ||||
| Users cannot be assumed to be able to meaningfully differentiate | Since expiration times provided in PvD Additional Information use | |||
| between "safe" and "unsafe" networks. This is a known attack surface | absolute time, these values can be skewed for hosts without an | |||
| that is present whether or not PvDs are in use, and hence cannot be | accurate time base, or due to clock skew. Such time values MUST NOT | |||
| addressed by this document. However, a host that correctly | be used for security-sensitive functionality or decisions. | |||
| implements the multiple PvD architecture ([RFC7556]) using the | ||||
| mechanism described in this document will be less susceptible to such | An attacker generating RAs on a local network can use the H-flag and | |||
| attacks than a host that does not by being able to check for the | the PvD ID to cause hosts on the network to make requests for PvD | |||
| various misconfigurations described in this document. | 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. | ||||
| Hosts might not always fetch PvD Additional Information, depending on | ||||
| whether or not they expect to use the information. However, if a | ||||
| host whitelisted only certain PvD IDs for which to fetch Additional | ||||
| Information, an attacker could send various PvD IDs in RAs to detect | ||||
| which PvD IDs are whitelisted by the client. To avoid this, hosts | ||||
| 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 | From a user privacy perspective, retrieving the PvD Additional | |||
| Information is not different from establishing a first connection to | Information is not different from establishing a first connection to | |||
| a remote server, or even performing a single DNS lookup. For | a remote server, or even performing a single DNS lookup. For | |||
| example, most operating systems already perform early queries to well | example, most operating systems already perform early queries to | |||
| known web sites, such as http://captive.example.com/hotspot- | static web sites, such as http://captive.example.com/hotspot- | |||
| detect.html, in order to detect the presence of a captive portal. | detect.html, in order to detect the presence of a captive portal. | |||
| The DNS queries associated with the PvD Additional Information MUST | The DNS queries associated with the PvD Additional Information MUST | |||
| use the DNS servers indicated by the associated PvD, as described in | use the DNS servers indicated by the associated PvD, as described in | |||
| Section 4.1. This ensures the name of the PvD Additional Information | Section 4.1. This ensures the name of the PvD Additional Information | |||
| server is not unintentionally sent on another network, thus leaking | server is not unintentionally sent on another network, thus leaking | |||
| identifying information about the networks with which the client is | identifying information about the networks with which the client is | |||
| associated. | associated. | |||
| There may be some cases where hosts, for privacy reasons, should | There may be some cases where hosts, for privacy reasons, should | |||
| skipping to change at page 23, line 37 ¶ | skipping to change at page 25, line 41 ¶ | |||
| 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 | Network operators SHOULD restrict access to PvD Additional | |||
| Information to only expose it to hosts that are connected to the | Information to only expose it to hosts that are connected to the | |||
| local network, especially if the Additional Information would provide | local network, especially if the Additional Information would provide | |||
| information about local network configuration to attackers. This can | information about local network configuration to attackers. This can | |||
| be implemented by whitelisting access from the addresses and prefixes | be implemented by whitelisting access from the addresses and prefixes | |||
| that the router provides for the PvD, which will match the prefixes | that the router provides for the PvD, which will match the prefixes | |||
| contained in the PvD Additional Information. | 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). | |||
| 8.1. New entry in the Well-Known URIs Registry | 8.1. New entry in the Well-Known URIs Registry | |||
| IANA is asked to add a new entry in the Well-Known URIs registry | IANA is asked to add a new entry in the Well-Known URIs registry | |||
| skipping to change at page 24, line 26 ¶ | skipping to change at page 26, line 34 ¶ | |||
| 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, including both the table of | registry are given in Section 4.3, including both the table of | |||
| mandatory keys and the table of optional keys. | mandatory keys and the table of optional keys. | |||
| The status of a key as mandatory or optional is intentionally not | The status of a key as mandatory or optional is intentionally not | |||
| denoted in the table to allow for flexibility in future use cases. | denoted in the table to allow for flexibility in future use cases. | |||
| Any new assignments of keys will be considered as optional for the | Any new assignments of keys will be considered as optional for the | |||
| purpose of the mechanism described in this document. | 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]. | 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. | ||||
| IANA is asked to place this registry in a new page, entitled | IANA is asked to place this registry in a new page, entitled | |||
| "Provisioning Domains (PvDs)". | "Provisioning Domains (PvDs)". | |||
| 8.3. PvD Option Flags Registry | 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 assigned 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], via a Standards Track RFC document. | Standards Action [RFC8126]. | |||
| Since these flags apply to an IPv6 Router Advertisement Option, IANA | Since these flags apply to an IPv6 Router Advertisement Option, IANA | |||
| is asked to place this registry under the existing "Internet Control | is asked to place this registry under the existing "Internet Control | |||
| Message Protocol version 6 (ICMPv6) Parameters" page, as well as | Message Protocol version 6 (ICMPv6) Parameters" page, as well as | |||
| providing a link on the new "Provisioning Domains (PvDs)" page. | providing a link on the new "Provisioning Domains (PvDs)" page. | |||
| 8.4. PvD JSON Media Type Registration | 8.4. PvD JSON Media Type Registration | |||
| This document registers the media type for PvD JSON text, | This document registers the media type for PvD JSON text, | |||
| "application/pvd+json". | "application/pvd+json". | |||
| Type Name: application | Type Name: application | |||
| Subtype Name: pvd+json | Subtype Name: pvd+json | |||
| Required parameters: None | ||||
| Optional parameters: None | Required parameters: N/A | |||
| Optional parameters: N/A | ||||
| Encoding considerations: Encoding considerations are identical to | Encoding considerations: Encoding considerations are identical to | |||
| those specified for the "application/json" media type. | those specified for the "application/json" media type. | |||
| Security considerations: See Section 6. | Security considerations: See Section 6. | |||
| Interoperability considerations: This document specifies format of | Interoperability considerations: This document specifies the format | |||
| conforming messages and the interpretation thereof. | of conforming messages and the interpretation thereof. | |||
| Published specification: This document | Published specification: This document | |||
| Applications that use this media type: This media type is intended to | Applications that use this media type: This media type is intended to | |||
| be used by network advertising additional Provisioning Domain | be used by networks advertising additional Provisioning Domain | |||
| information, and clients looking up such information. | information, and clients looking up such information. | |||
| Additional information: None | Fragment identifier considerations: N/A | |||
| Additional information: N/A | ||||
| Person and email address to contact for further information: See | Person and email address to contact for further information: See | |||
| Authors' Addresses section | Authors' Addresses section | |||
| Intended usage: COMMON | Intended usage: COMMON | |||
| Restrictions on usage: None | Restrictions on usage: N/A | |||
| Author: IETF | Author: IETF | |||
| Change controller: IETF | Change controller: IETF | |||
| 9. Acknowledgments | 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. | |||
| skipping to change at page 26, line 18 ¶ | skipping to change at page 28, line 35 ¶ | |||
| [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>. | |||
| [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>. | |||
| [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | |||
| RFC 2131, DOI 10.17487/RFC2131, March 1997, | DOI 10.17487/RFC2818, May 2000, | |||
| <https://www.rfc-editor.org/info/rfc2131>. | <https://www.rfc-editor.org/info/rfc2818>. | |||
| [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: | [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: | |||
| Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, | Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, | |||
| <https://www.rfc-editor.org/info/rfc3339>. | <https://www.rfc-editor.org/info/rfc3339>. | |||
| [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic | ||||
| Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, | ||||
| DOI 10.17487/RFC3646, December 2003, | ||||
| <https://www.rfc-editor.org/info/rfc3646>. | ||||
| [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and | [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and | |||
| More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, | More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, | |||
| November 2005, <https://www.rfc-editor.org/info/rfc4191>. | November 2005, <https://www.rfc-editor.org/info/rfc4191>. | |||
| [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case | [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case | |||
| Insensitivity Clarification", RFC 4343, | Insensitivity Clarification", RFC 4343, | |||
| DOI 10.17487/RFC4343, January 2006, | DOI 10.17487/RFC4343, January 2006, | |||
| <https://www.rfc-editor.org/info/rfc4343>. | <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, | |||
| skipping to change at page 27, line 19 ¶ | skipping to change at page 29, line 29 ¶ | |||
| [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation | [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation | |||
| with IPv6 Neighbor Discovery", RFC 6980, | with IPv6 Neighbor Discovery", RFC 6980, | |||
| DOI 10.17487/RFC6980, August 2013, | DOI 10.17487/RFC6980, August 2013, | |||
| <https://www.rfc-editor.org/info/rfc6980>. | <https://www.rfc-editor.org/info/rfc6980>. | |||
| [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, | [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, | |||
| DOI 10.17487/RFC7493, March 2015, | DOI 10.17487/RFC7493, March 2015, | |||
| <https://www.rfc-editor.org/info/rfc7493>. | <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 | [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by | |||
| Hosts in a Multi-Prefix Network", RFC 8028, | Hosts in a Multi-Prefix Network", RFC 8028, | |||
| DOI 10.17487/RFC8028, November 2016, | DOI 10.17487/RFC8028, November 2016, | |||
| <https://www.rfc-editor.org/info/rfc8028>. | <https://www.rfc-editor.org/info/rfc8028>. | |||
| [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, | ||||
| "IPv6 Router Advertisement Options for DNS Configuration", | ||||
| RFC 8106, DOI 10.17487/RFC8106, March 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8106>. | ||||
| [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>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
| skipping to change at page 28, line 11 ¶ | skipping to change at page 30, line 27 ¶ | |||
| 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 Standards for Local and Metropolitan Area Networks, | IEEE, "IEEE Standards for Local and Metropolitan Area | |||
| Port-based Network Access Control, IEEE Std", n.d.. | Networks, Port-based Network Access Control, IEEE Std". | |||
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | |||
| DOI 10.17487/RFC2818, May 2000, | RFC 2131, DOI 10.17487/RFC2131, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2818>. | <https://www.rfc-editor.org/info/rfc2131>. | |||
| [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic | ||||
| Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, | ||||
| 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>. | |||
| [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>. | |||
| [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>. | |||
| [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., | ||||
| Galperin, S., and C. Adams, "X.509 Internet Public Key | ||||
| Infrastructure Online Certificate Status Protocol - OCSP", | ||||
| RFC 6960, DOI 10.17487/RFC6960, June 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6960>. | ||||
| [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object | |||
| Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, | |||
| October 2013, <https://www.rfc-editor.org/info/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>. | ||||
| [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, | ||||
| "IPv6 Router Advertisement Options for DNS Configuration", | ||||
| RFC 8106, DOI 10.17487/RFC8106, March 2017, | ||||
| <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>. | |||
| [URN] "URN Namespaces", n.d.. | [URN] IANA, "Uniform Resource Names (URN) Namespaces", | |||
| <https://www.iana.org/assignments/urn-namespaces/ | ||||
| urn-namespaces.xhtml>. | ||||
| 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 | |||
| End of changes. 73 change blocks. | ||||
| 205 lines changed or deleted | 327 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/ | ||||