draft-ietf-intarea-provisioning-domains-02.txt   draft-ietf-intarea-provisioning-domains-03.txt 
intarea P. Pfister intarea P. Pfister
Internet-Draft E. Vyncke, Ed. Internet-Draft E. Vyncke, Ed.
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: December 6, 2018 T. Pauly Expires: April 22, 2019 T. Pauly
D. Schinazi D. Schinazi
Apple Apple
W. Shao W. Shao
Telecom-ParisTech Telecom-ParisTech
June 4, 2018 October 19, 2018
Discovering Provisioning Domain Names and Data Discovering Provisioning Domain Names and Data
draft-ietf-intarea-provisioning-domains-02 draft-ietf-intarea-provisioning-domains-03
Abstract Abstract
An increasing number of hosts access the Internet via multiple An increasing number of hosts access the Internet via multiple
interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix
configurations context. configurations context.
This document describes a way for hosts to identify such contexts, This document describes a way for hosts to identify such contexts,
called Provisioning Domains (PvDs), where Fully Qualified Domain called Provisioning Domains (PvDs), where Fully Qualified Domain
Names (FQDNs) act as PvD identifiers. Those identifiers are Names (FQDNs) act as PvD identifiers. Those identifiers are
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 6, 2018. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 39 skipping to change at page 2, line 39
3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 8 3.3. Non-PvD-aware Host Behavior . . . . . . . . . . . . . . . 8
3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 8 3.4. PvD-aware Host Behavior . . . . . . . . . . . . . . . . . 8
3.4.1. DHCPv6 configuration association . . . . . . . . . . 9 3.4.1. DHCPv6 configuration association . . . . . . . . . . 9
3.4.2. DHCPv4 configuration association . . . . . . . . . . 9 3.4.2. DHCPv4 configuration association . . . . . . . . . . 9
3.4.3. Connection Sharing by the Host . . . . . . . . . . . 9 3.4.3. Connection Sharing by the Host . . . . . . . . . . . 9
4. Provisioning Domain Additional Information . . . . . . . . . 10 4. Provisioning Domain Additional Information . . . . . . . . . 10
4.1. Retrieving the PvD Additional Information . . . . . . . . 10 4.1. Retrieving the PvD Additional Information . . . . . . . . 10
4.2. Operational Consideration to Providing the PvD Additional 4.2. Operational Consideration to Providing the PvD Additional
Information . . . . . . . . . . . . . . . . . . . . . . . 12 Information . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. PvD Additional Information Format . . . . . . . . . . . . 12 4.3. PvD Additional Information Format . . . . . . . . . . . . 12
4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 13 4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 14
4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Detecting misconfiguration and misuse . . . . . . . . . . 14 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 14
5. Operational Considerations . . . . . . . . . . . . . . . . . 14 5. Operational Considerations . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative references . . . . . . . . . . . . . . . . . . 18 10.1. Normative references . . . . . . . . . . . . . . . . . . 18
10.2. Informative references . . . . . . . . . . . . . . . . . 19 10.2. Informative references . . . . . . . . . . . . . . . . . 19
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 21
A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 20 A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 21
A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 21 A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 22
A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 22 A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 22
A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 22 A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 23
A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 23 A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
It has become very common in modern networks for hosts to access the It has become very common in modern networks for hosts to access the
internet through different network interfaces, tunnels, or next-hop internet through different network interfaces, tunnels, or next-hop
routers. To describe the set of network configurations associated routers. To describe the set of network configurations associated
with each access method, the concept of Provisioning Domain (PvD) was with each access method, the concept of Provisioning Domain (PvD) was
defined in [RFC7556]. defined in [RFC7556].
This document specifies a way to identify PvDs with Fully Qualified This document specifies a way to identify PvDs with Fully Qualified
skipping to change at page 7, line 48 skipping to change at page 7, line 48
otherwise be valid as part of the same RA. Such options are otherwise be valid as part of the same RA. Such options are
processed by PvD-aware hosts, while ignored by others. processed by PvD-aware hosts, while ignored by others.
In order to provide multiple different PvDs, a router MUST send In order to provide multiple different PvDs, a router MUST send
multiple RAs. Different explicit PvDs MAY be advertised with RAs multiple RAs. Different explicit PvDs MAY be advertised with RAs
using the same IPv6 source address; but different implicit PvDs, using the same IPv6 source address; but different implicit PvDs,
advertised by different RAs, MUST use different link-local addresses advertised by different RAs, MUST use different link-local addresses
because these implicit PvDs are identified by the source addresses of because these implicit PvDs are identified by the source addresses of
the RAs. the RAs.
Whenever an RA, for a single PvD, would need to be sent via multiple As specified in [RFC4861], when the set of options causes the size of
packets, the PvD option header (i.e., all fields except the 'Options' an advertisement to exceed the link MTU, multiple router
field) MUST be repeated in all the transmitted RAs. But the options advertisements can be sent, each containing a subset of the options.
within the 'Options' field, MAY be transmitted only once, included in In such cases, the PvD option header (i.e., all fields except the
one of the transmitted PvD options. 'Options' field) MUST be repeated in all the transmitted RAs. But
the options within the 'Options' field, MAY be transmitted only once,
included in one of the transmitted PvD options.
3.3. Non-PvD-aware Host Behavior 3.3. Non-PvD-aware Host Behavior
As the PvD Option has a new option code, non-PvD-aware hosts will As the PvD Option has a new option code, non-PvD-aware hosts will
simply ignore the PvD Option and all the options it contains. This simply ignore the PvD Option and all the options it contains. This
ensure the backward compatibility required in section 3.3 of ensure the backward compatibility required in section 3.3 of
[RFC7556]. This behavior allows for a mixed-mode network with a mix [RFC7556]. This behavior allows for a mixed-mode network with a mix
of PvD-aware and non-PvD-aware hosts coexist. of PvD-aware and non-PvD-aware hosts coexist.
3.4. PvD-aware Host Behavior 3.4. PvD-aware Host Behavior
skipping to change at page 9, line 41 skipping to change at page 9, line 42
whose PVD Options L-flag is set and, in the case of a non point-to- whose PVD Options L-flag is set and, in the case of a non point-to-
point link, using the same datalink address. If no such PvD is point link, using the same datalink address. If no such PvD is
found, or whenever multiple different PvDs are found, the found, or whenever multiple different PvDs are found, the
configuration elements coming from DHCPv4 MUST be associated with the configuration elements coming from DHCPv4 MUST be associated with the
implicit PvD identified by the interface on which the DHCPv4 implicit PvD identified by the interface on which the DHCPv4
transaction happened. The case of multiple explicit PvD for an IPv4 transaction happened. The case of multiple explicit PvD for an IPv4
interface is undefined. interface is undefined.
3.4.3. Connection Sharing by the Host 3.4.3. Connection Sharing by the Host
The situation when a node receives an RA on one interface (e.g. The situation when a host shares connectivity from an upstream
cellular) and shares this connectivity by also acting as a router by interface (e.g. cellular) to a downstream interface (e.g. WiFi) is
transmitting RA on another interface (e.g. WiFi) is known as known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share
'tethering'. It can be done as ND proxy. The exact behavior is out [RFC7278] or prefix delegation (e.g. using DHCPv6-PD [RFC3633]) may
of scope of this document but it is expected that the one or several be used for that purpose.
PvD associated to the shared interface (e.g. cellular) will also be
advertised to the clients on the other interface (e.g. WiFi). Whenever the RAs received from the upstream interface contain a PVD
RA option, hosts that are sharing connectivity SHOULD include a PVD
Option within the RAs sent downstream with:
The same PVD-ID FQDN.
The same H-bit, Delay and Sequence Number values.
The L bit set whenever the host is sharing IPv4 connectivity
received from the same upstream interface.
The bits from the Reserved field set to 0.
The values of the R-bit, Router Advertisement message header and
Options field depend on whether the connectivity should be shared
only with PvD aware hosts or not (see Section 3.2). In particular,
all options received within the upstream PvD option and included in
the downstream RA SHOULD be included in the downstream PvD option.
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 [RFC7159].
The purpose of this additional set of information is to securely The purpose of this additional set of information is to securely
provide additional information to applications about the connectivity provide additional information to applications about the connectivity
that is provided using a given interface and source address pair. It that is provided using a given interface and source address pair. It
skipping to change at page 14, line 35 skipping to change at page 15, line 5
information provided by the trusted Router Advertisement, and the information provided by the trusted Router Advertisement, and the
HTTPS server. But this does not mean the Advertising Router and the HTTPS server. But this does not mean the Advertising Router and the
PvD server belong to the same entity. 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 the RA PIO are covered by a
prefix from the PvD Additional Information. An adversarial router prefix from the PvD Additional Information. An adversarial router
willing to fake the use of a given explicit PvD, without any access willing to fake the use of a given explicit PvD, without any access
to the actual PvD Additional Information, would need to perform NAT66 to the actual PvD Additional Information, would need to perform NAT66
in order to circumvent this check. in order to circumvent this check.
It is also RECOMMENDED that the HTTPS server checks the source It is also RECOMMENDED that the HTTPS server checks the IPv6 source
addresses of incoming connections (see Section 4.1). This check give addresses of incoming connections (see Section 4.1). This check give
reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used reasonable assurance that neither NPTv6 [RFC6296] nor NAT66 were used
and restricts the information to the valid network users. and restricts the information to the valid network users.
Note that this check cannot be performed when the HTTPS query is
performed over IPv4. Therefore, the PvD ID FQDN SHOULD NOT have a
DNS A record whenever all hosts using the given PvD have IPv6
connectivity.
5. Operational Considerations 5. Operational Considerations
This section describes some use cases of PvD. For the sake of This section describes some use cases of PvD. For the sake of
simplicity, the RA messages will not be described in the usual ASCII simplicity, the RA messages will not be described in the usual ASCII
art but rather in an indented list. For example, a RA message art but rather in an indented list. For example, a RA message
containing some options and a PvD option that also contains other containing some options and a PvD option that also contains other
options will be described as: options will be described as:
o RA Header: router lifetime = 6000 o RA Header: router lifetime = 6000
skipping to change at page 19, line 31 skipping to change at page 19, line 45
IEEE, "IEEE Standards for Local and Metropolitan Area IEEE, "IEEE Standards for Local and Metropolitan Area
Networks: Port based Network Access Control, IEEE Std". Networks: Port based Network Access Control, IEEE Std".
[PEN] IANA, "Private Enterprise Numbers", [PEN] IANA, "Private Enterprise Numbers",
<https://www.iana.org/assignments/enterprise-numbers>. <https://www.iana.org/assignments/enterprise-numbers>.
[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>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<https://www.rfc-editor.org/info/rfc3633>.
[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
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>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
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 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
skipping to change at page 20, line 24 skipping to change at page 20, line 47
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
<https://www.rfc-editor.org/info/rfc6731>. <https://www.rfc-editor.org/info/rfc6731>.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278,
DOI 10.17487/RFC7278, June 2014,
<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 [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, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
 End of changes. 18 change blocks. 
28 lines changed or deleted 67 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/