draft-ietf-intarea-provisioning-domains-06.txt   draft-ietf-intarea-provisioning-domains-07.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: February 13, 2020 T. Pauly Expires: April 2, 2020 T. Pauly
Apple Inc. Apple Inc.
D. Schinazi D. Schinazi
Google LLC Google LLC
W. Shao W. Shao
Cisco Cisco
August 12, 2019 September 30, 2019
Discovering Provisioning Domain Names and Data Discovering Provisioning Domain Names and Data
draft-ietf-intarea-provisioning-domains-06 draft-ietf-intarea-provisioning-domains-07
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 February 13, 2020. This Internet-Draft will expire on April 2, 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 3, line 7 skipping to change at page 3, line 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. Additional Information PvD Keys Registry . . . . . . . . 22 8.1. Additional Information PvD Keys Registry . . . . . . . . 22
8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 22 8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 22
8.3. PvD JSON Media Type Registration . . . . . . . . . . . . 22 8.3. PvD JSON Media Type Registration . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 9, line 51 skipping to change at page 9, line 51
updated the object. For example, addresses that are generated using updated the object. For example, addresses that are generated using
a received Prefix Information option (PIO) are associated with the a received Prefix Information option (PIO) are associated with the
PvD of the last received RA which included the given PIO. 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 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 ([RFC2461], [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 an arbitrary set 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
skipping to change at page 12, line 45 skipping to change at page 12, line 45
o A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will o A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will
synthesize IPv6 addresses in DNS answers that are not globally synthesize IPv6 addresses in DNS answers that are not globally
routable, and 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 [RFC7159]. 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 restricted profile of I-JSON,
as defined in [RFC7493]. as defined in [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
skipping to change at page 13, line 29 skipping to change at page 13, line 29
and would in some cases prefer a smaller representation like CBOR and would in some cases prefer a smaller representation like CBOR
([RFC7049]). Delivering a reduced version of the PvD Additional ([RFC7049]). Delivering a reduced version of the PvD Additional
Information designed for such devices is not defined in this Information designed for such devices is not defined in this
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 [RFC5785]. Inversely, hosts MUST NOT do so ID>/.well-known/pvd [RFC8615]. Inversely, hosts MUST NOT do so
whenever the H-flag is not set. whenever the H-flag is not set.
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 in their GET requests,
and servers MUST mark this media type as their Content-Type header in and servers MUST mark this media type as their Content-Type header in
responses. 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, the PKI (Public Key
Infrastructure) checks as well as the actual query MUST be performed Infrastructure) checks as well as the actual query MUST be performed
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 | "sub.example.com"] | | | and accessible | strings | |
| | | | |
| | | | "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 23, line 44 skipping to change at page 23, line 44
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>.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
DOI 10.17487/RFC2461, December 1998,
<https://www.rfc-editor.org/info/rfc2461>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[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>.
[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>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[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>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
10.2. Informative References 10.2. Informative References
[I-D.kline-mif-mpvd-api-reqs] [I-D.kline-mif-mpvd-api-reqs]
Kline, E., "Multiple Provisioning Domains API Kline, E., "Multiple Provisioning Domains API
Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in Requirements", draft-kline-mif-mpvd-api-reqs-00 (work in
progress), November 2015. progress), November 2015.
[I-D.stenberg-mif-mpvd-dns] [I-D.stenberg-mif-mpvd-dns]
Stenberg, M. and S. Barth, "Multiple Provisioning Domains Stenberg, M. and S. Barth, "Multiple Provisioning Domains
using Domain Name System", draft-stenberg-mif-mpvd-dns-00 using Domain Name System", draft-stenberg-mif-mpvd-dns-00
skipping to change at page 25, line 9 skipping to change at page 25, line 5
[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", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<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>.
[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 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
skipping to change at page 25, line 31 skipping to change at page 25, line 31
[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 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011, DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>. <https://www.rfc-editor.org/info/rfc6105>.
[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>.
skipping to change at page 27, line 45 skipping to change at page 27, line 42
United States of America United States of America
Email: dschinazi.ietf@gmail.com Email: dschinazi.ietf@gmail.com
Wenqin Shao Wenqin Shao
Cisco Cisco
11 Rue Camille Desmoulins 11 Rue Camille Desmoulins
Issy-les-Moulineaux 92130 Issy-les-Moulineaux 92130
France France
Email: wenshao@apple.com Email: wenshao@cisco.com
 End of changes. 15 change blocks. 
27 lines changed or deleted 24 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/