draft-ietf-intarea-provisioning-domains-07.txt   draft-ietf-intarea-provisioning-domains-08.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: April 2, 2020 T. Pauly Expires: April 10, 2020 T. Pauly
Apple Inc. Apple Inc.
D. Schinazi D. Schinazi
Google LLC Google LLC
W. Shao W. Shao
Cisco Cisco
September 30, 2019 October 08, 2019
Discovering Provisioning Domain Names and Data Discovering Provisioning Domain Names and Data
draft-ietf-intarea-provisioning-domains-07 draft-ietf-intarea-provisioning-domains-08
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 April 2, 2020. This Internet-Draft will expire on April 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 45 skipping to change at page 2, line 45
4. Provisioning Domain Additional Information . . . . . . . . . 12 4. Provisioning Domain Additional Information . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. PvD Additional Information Format . . . . . . . . . . . . 15 4.3. PvD Additional Information Format . . . . . . . . . . . . 15
4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Detecting misconfiguration and misuse . . . . . . . . . . 17 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 17
5. Operational Considerations . . . . . . . . . . . . . . . . . 18 5. Operational Considerations . . . . . . . . . . . . . . . . . 18
5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 18 5.1. Exposing Extra RA Options to PvD-Aware Hosts . . . . . . 18
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 . . . 18
5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 19 5.3. Enabling Multi-homing for PvD-Aware Hosts . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Additional Information PvD Keys Registry . . . . . . . . 22 8.1. New entry in the Well-Known URIs Registry . . . . . . . . 22
8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 22 8.2. Additional Information PvD Keys Registry . . . . . . . . 22
8.3. PvD JSON Media Type Registration . . . . . . . . . . . . 22 8.3. PvD Option Flags Registry . . . . . . . . . . . . . . . . 22
8.4. PvD JSON Media Type Registration . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 5, line 28 skipping to change at page 5, line 28
operator in order to avoid naming collisions. The same PvD ID MAY be operator in order to avoid naming collisions. The same PvD ID MAY be
used in several access networks when they ultimately provide used in several access networks when they ultimately provide
identical services (e.g., in all home networks subscribed to the same identical services (e.g., in all home networks subscribed to the same
service); else, the PvD ID MUST be different to follow Section 2.4 of service); else, the PvD ID MUST be different to follow Section 2.4 of
[RFC7556]. [RFC7556].
3.1. PvD ID Option for Router Advertisements 3.1. PvD ID Option for Router Advertisements
This document introduces a Router Advertisement (RA) option called This document introduces a Router Advertisement (RA) option called
PvD Option. It is used to convey the FQDN identifying a given PvD PvD Option. It is used to convey the FQDN identifying a given PvD
(see Figure 1, bind the PvD ID with configuration information (see Figure 1), bind the PvD ID with configuration information
received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over
TLS to retrieve the PvD Additional Information JSON object (see TLS to retrieve the PvD Additional Information JSON object (see
Section 4), as well as contain any other RA options which would Section 4), as well as contain any other RA options which would
otherwise be valid in the RA. otherwise be valid in the RA.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |H|L|R| Reserved | Delay | | Type | Length |H|L|R| Reserved | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 45 skipping to change at page 6, line 45
in Section 4. in Section 4.
L-flag: (1 bit) 'Legacy' flag stating whether the router is also L-flag: (1 bit) 'Legacy' flag stating whether the router is also
providing IPv4 information using DHCPv4 (see Section 3.4.2). providing IPv4 information 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 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]). 4.2 of [RFC4861]).
Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from
hosts by a randomized backoff (see Section 4.1).
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
hosts by a randomized backoff (see Section 4.1).
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.
PvD ID FQDN: The FQDN used as PvD ID encoded in DNS format, as PvD ID FQDN: The FQDN used as PvD ID encoded in DNS format, as
described in Section 3.1 of [RFC1035]. Domain names compression described in Section 3.1 of [RFC1035]. Domain names 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.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
Advertisement message header as specified in [RFC4861]. The Advertisement message header as specified in [RFC4861]. The
sender MUST set the 'Type' to 134, the value for "Router sender MUST set the 'Type' to 134, the value for "Router
Advertisement", and set the 'Code' to 0. Receivers MUST ignore Advertisement", and set the 'Code' to 0. Receivers MUST ignore
both of these fields. The 'Checksum' MUST be set to 0 by the both of these fields. The 'Checksum' MUST be set to 0 by the
sender; non-zero checksums MUST be ignored by the receiver. All sender; non-zero checksums MUST be ignored by the receiver. All
other fields are to be set and parsed as specified in [RFC4861] or other fields are to be set and parsed as specified in [RFC4861] or
any updating documents. any updating documents.
Options: Zero or more RA options that would otherwise be valid as Options: Zero or more RA options that would otherwise be valid as
part of the Router Advertisement main body, but are instead part of the Router Advertisement main body, but are instead
included in the PvD Option such as to be ignored by hosts that are included in the PvD Option so as to be ignored by hosts that are
not PvD-aware. not PvD-aware.
Here is an example of a PvD Option with "example.org" as the PvD ID Here is an example of a PvD Option with "example.org" as the PvD ID
FQDN and including both an RDNSS option and a prefix information FQDN and including both an RDNSS option and a prefix information
option. It has a Sequence Number of 123, and indicates the presence option. It has a Sequence Number of 123, and indicates the presence
of additional information that is expected to be fetched with a delay of additional information that is expected to be fetched with a delay
factor of 5. factor of 5.
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
skipping to change at page 10, line 6 skipping to change at page 10, line 6
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 resolving names, executing the default address selection
algorithm [RFC6724] or executing the default router selection algorithm [RFC6724] or executing the default router selection
algorithm when forwarding packets ([RFC4861], [RFC4191] and algorithm when forwarding packets ([RFC4861], [RFC4191] and
[RFC8028]), hosts and applications MAY consider only the [RFC8028]), hosts and applications MAY consider only the
configuration associated with an arbitrary set of PvDs. configuration associated with any non-empty subset of PvDs.
For example, a host MAY associate a given process with a specific For example, a host MAY associate a given process with a specific
PvD, or a specific set of PvDs, while associating another process PvD, or a specific set of PvDs, while associating another process
with another PvD. A PvD-aware application might also be able to with another PvD. A PvD-aware application might also be able to
select, on a per-connection basis, which PvDs should be used. In select, on a per-connection basis, which PvDs should be used. In
particular, constrained devices such as small battery operated particular, constrained devices such as small battery operated
devices (e.g. IoT), or devices with limited CPU or memory resources devices (e.g. IoT), or devices with limited CPU or memory resources
may purposefully use a single PvD while ignoring some received RAs may purposefully use a single PvD while ignoring some received RAs
containing different PvD IDs. containing different PvD IDs.
skipping to change at page 15, line 8 skipping to change at page 15, line 8
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 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.
The PvD Additional Information object includes a set of IPv6 prefixes The PvD Additional Information object includes a set of IPv6 prefixes
(under the key "prefixes") which MUST be checked against all the (under the key "prefixes") which MUST be checked against all the
Prefix Information Options advertised in the RA. If any of the Prefix Information Options advertised in the RA. If any of the
prefixes included in the PIO is not covered by at least one of the prefixes included in any associated PIO is not covered by at least
listed prefixes, the associated PvD information MUST be considered to one of the listed prefixes, the associated PvD information MUST be
be a misconfiguration, and MUST NOT be used by the host. See considered to be a misconfiguration, and MUST NOT be used by the
Section 4.4 for more discussion on handling such misconfigurations. host. See Section 4.4 for more discussion on handling such
misconfigurations.
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, PKI and HTTP
over TLS operations related to the retrieval of the object, even over TLS operations related to the retrieval of the object, even
before logging into the captive portal. before logging into the captive portal.
skipping to change at page 16, line 36 skipping to change at page 16, line 36
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 of | ["example.com", |
| | and accessible | strings | | | | and accessible | strings | "sub.example.com"] |
| | | | |
| | | | "sub.example.com"] |
| | | | | | | | | |
| noInternet | No Internet, set | Boolean | true | | noInternet | No Internet, set | Boolean | true |
| | when the PvD is | | | | | when the PvD 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.
skipping to change at page 17, line 27 skipping to change at page 17, line 27
{ {
"identifier": "cafe.example.com", "identifier": "cafe.example.com",
"expires": "2017-07-23T06:00:00Z", "expires": "2017-07-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
} }
{ {
"identifier": "company.foo.example.com", "identifier": "company.foo.example.com",
"expires": "2017-07-23T06:00:00Z", "expires": "2017-07-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"vendor-foo": { "private-key": "private-value" }, "vendor-foo":
{
"private-key": "private-value",
},
} }
4.4. Detecting misconfiguration and misuse 4.4. Detecting misconfiguration and misuse
When a host retrieves the PvD Additional Information, it MUST verify When a host retrieves the PvD Additional Information, it MUST verify
that the TLS server certificate is valid for the performed request that the TLS server certificate is valid for the performed request
(e.g., that the Subject Name is equal to the PvD ID expressed as an (e.g., that the Subject Name is equal to the PvD ID expressed as an
FQDN). This authentication creates a secure binding between the FQDN). This authentication creates a secure binding between the
information provided by the trusted Router Advertisement, and the information provided by the trusted Router Advertisement, and the
HTTPS server. However, this does not mean the Advertising Router and HTTPS server. However, this does not mean the Advertising Router and
the PvD server belong to the same entity. the PvD server belong to the same entity.
Hosts MUST verify that all prefixes in the RA PIO are covered by a Hosts MUST verify that all prefixes in all the RA PIOs are covered by
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
server for additional information can detect this misconfiguration. server for additional information can detect this misconfiguration.
The HTTPS server SHOULD validate the source addresses of incoming The HTTPS server SHOULD validate the source addresses of incoming
connections (see Section 4.1). This check gives reasonable assurance connections (see Section 4.1). This check gives reasonable assurance
skipping to change at page 18, line 48 skipping to change at page 19, line 4
Note that a PvD-aware host will receive two different prefixes, Note that a PvD-aware host will receive two different prefixes,
2001:db8:cafe::/64 and 2001:db8:f00d::/64, both associated with the 2001:db8:cafe::/64 and 2001:db8:f00d::/64, both associated with the
same PvD (identified by "example.org."). A non-PvD-aware host will same PvD (identified by "example.org."). A non-PvD-aware host will
only receive one prefix, 2001:db8:cafe::/64. only receive one prefix, 2001:db8:cafe::/64.
5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts 5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts
It is expected that for some years, networks will have a mixed It is expected that for some years, networks will have a mixed
environment of PvD-aware hosts and non-PvD-aware hosts. If there is environment of PvD-aware hosts and non-PvD-aware hosts. If there is
a need to give specific information to PvD-aware hosts only, then it a need to give specific information to PvD-aware hosts only, then it
is recommended to send two RA messages (one for each class of hosts). is RECOMMENDED to send two RA messages, one for each class of hosts.
For example, here is the RA sent for non-PvD-aware hosts: If two RA messages are sent for this reason, they MUST be sent from
two different link-local source addresses (Section 3.2). For
example, here is the RA sent for non-PvD-aware hosts:
o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use
this router as a default router) this router as a default router)
o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
o Recursive DNS Server Option: length = 3, addresses= o Recursive DNS Server Option: length = 3, addresses=
[2001:db8:cafe::53] [2001:db8:cafe::53]
o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org., o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org.,
skipping to change at page 20, line 22 skipping to change at page 20, line 29
o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
o Recursive DNS Server Option: length = 3, addresses= o Recursive DNS Server Option: length = 3, addresses=
[2001:db8:cafe::53] [2001:db8:cafe::53]
o PvD Option header: length = 3, PvD ID FQDN = foo.example.org., o PvD Option header: length = 3, PvD ID FQDN = foo.example.org.,
R-flag = 0 (actual length of the header 24 bytes = 3 * 8 bytes) R-flag = 0 (actual length of the header 24 bytes = 3 * 8 bytes)
The second RA contains a prefix usable only by PvD-aware hosts. Non- The second RA contains a prefix usable only by PvD-aware hosts. Non-
PvD-aware hosts will ignore this RA. PvD-aware hosts will ignore this RA; hence, the only PvD-aware hosts
will be multi-homed.
o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use
this router as a default router) this router as a default router)
o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN =
bar.example.org., R-flag = 1 (actual length of the header 24 bytes bar.example.org., R-flag = 1 (actual length of the header 24 bytes
= 3 * 8 bytes) = 3 * 8 bytes)
* RA Header: router lifetime = 1600 (PvD-aware hosts will use * RA Header: router lifetime = 1600 (PvD-aware hosts will use
this router as a default router), implicit length = 2 this router as a default router), implicit length = 2
* Prefix Information Option: length = 4, prefix = * Prefix Information Option: length = 4, prefix =
2001:db8:f00d::/64 2001:db8:f00d::/64
* Recursive DNS Server Option: length = 3, addresses = * Recursive DNS Server Option: length = 3, addresses =
[2001:db8:f00d::53] [2001:db8:f00d::53]
Note: the above examples assume that the router has received its PvD
IDs from upstream routers or via some other configuration mechanism.
Another document could define ways for the router to generate its own
PvD IDs to allow the above scenario in the absence of PvD ID
provisioning.
6. Security Considerations 6. Security Considerations
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].
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 extends the purely link-local trust relationship
skipping to change at page 21, line 14 skipping to change at page 21, line 28
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 an
hostile network access provider to advertise wrong information that hostile network access provider to advertise wrong information that
could lead applications or hosts to select a hostile PvD. could lead applications or hosts to select a hostile PvD.
Users cannot be assumed to be able to meaningfully differentiate Users cannot be assumed to be able to meaningfully differentiate
between "safe" and "unsafe" networks. This is a known attack surface between "safe" and "unsafe" networks. This is a known attack surface
that is present whether or not PvDs are in use, and hence cannot be that is present whether or not PvDs are in use, and hence cannot be
addressed by this document. However, a host that correctly addressed by this document. However, a host that correctly
implements the MPvD architecture ([RFC7556]) using the mechanism implements the multiple PvD architecture ([RFC7556]) using the
described in this document will be less susceptible to such attacks mechanism described in this document will be less susceptible to such
than a host that does not by being able to check for the various attacks than a host that does not by being able to check for the
misconfigurations described in this document. various misconfigurations described in this document.
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. Therefore, hosts
willing to retrieve the PvD Additional Information before using it willing to retrieve the PvD Additional Information before using it
without leaking identity information, SHOULD make use of an IPv6 without leaking identity information, SHOULD make use of an IPv6
skipping to change at page 22, line 5 skipping to change at page 22, line 19
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.
8. IANA Considerations 8. IANA Considerations
Upon publication of this document, IANA is asked to remove the Upon publication of this document, IANA is asked to remove the
'reclaimable' tag off the value 21 for the PvD Option (from the IPv6 'reclaimable' tag off the value 21 for the PvD Option (from the IPv6
Neighbor Discovery Option Formats registry). Neighbor Discovery Option Formats registry).
IANA is asked to assign the value "pvd" from the Well-Known URIs 8.1. New entry in the Well-Known URIs Registry
registry.
8.1. Additional Information PvD Keys Registry IANA is asked to add a new entry in the well-known-uris registry with
the following information:
URI suffix: 'pvd'
Change controller: IETF
Specification document: this document
Status: permanent
Related information: N/A
8.2. Additional Information PvD Keys Registry
IANA is asked to create and maintain a new registry called IANA is asked to create and maintain a new registry called
"Additional Information PvD Keys", which will reserve JSON keys for "Additional Information PvD Keys", which will reserve JSON keys for
use in PvD additional information. The initial contents of this use in PvD additional information. The initial contents of this
registry are given in Section 4.3. registry are given in Section 4.3.
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].
8.2. 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 15 to be used in
the PvD Option bitmask. Bit position 0, 1 and 2 are reserved by this the PvD Option bitmask. Bit position 0, 1 and 2 are reserved 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], via a Standards Track RFC document.
8.3. 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 Required parameters: None
skipping to change at page 23, line 20 skipping to change at page 23, line 47
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
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.
Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen
Cao, Tim Chown, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer, Cao, Tim Chown, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer,
Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted
Lemon, Paul Hoffman, Dave Thaler, Suresh Krishnan, Gorry Fairhurst, Lemon, Paul Hoffman, Dave Thaler, Suresh Krishnan, Gorry Fairhurst,
Jen Lenkova, Veronika McKillop, Mark Townsley and James Woodyatt for Jen Lenkova, Veronika McKillop, Mark Townsley and James Woodyatt for
useful and interesting discussions and reviews. useful and interesting discussions and reviews.
Finally, special thanks to Thierry Danis and Wenqin Shao for their Finally, special thanks to Thierry Danis for his valuable inputs and
valuable inputs and implementation efforts, Tom Jones for his implementation efforts, Tom Jones for his integration effort into the
integration effort into the NEAT project and Rigil Salim for his NEAT project and Rigil Salim for his implementation work.
implementation work.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003, DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>. <https://www.rfc-editor.org/info/rfc3646>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case [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,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[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>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>. <https://www.rfc-editor.org/info/rfc8615>.
10.2. Informative References 10.2. Informative References
skipping to change at page 24, line 44 skipping to change at page 26, line 14
[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 Standards for Local and Metropolitan Area Networks,
Port-based Network Access Control, IEEE Std", n.d.. Port-based Network Access Control, IEEE Std", n.d..
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <https://www.rfc-editor.org/info/rfc4389>. 2006, <https://www.rfc-editor.org/info/rfc4389>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[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>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>. <https://www.rfc-editor.org/info/rfc6296>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[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 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>. <https://www.rfc-editor.org/info/rfc7556>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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] "URN Namespaces", n.d..
Authors' Addresses Authors' Addresses
Pierre Pfister Pierre Pfister
Cisco Cisco
11 Rue Camille Desmoulins 11 Rue Camille Desmoulins
Issy-les-Moulineaux 92130 Issy-les-Moulineaux 92130
France France
Email: ppfister@cisco.com Email: ppfister@cisco.com
Eric Vyncke Eric Vyncke
Cisco Cisco
 End of changes. 38 change blocks. 
88 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/