draft-ietf-intarea-provisioning-domains-03.txt   draft-ietf-intarea-provisioning-domains-04.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: April 22, 2019 T. Pauly Expires: September 9, 2019 T. Pauly
D. Schinazi
Apple Apple
D. Schinazi
Google LLC
W. Shao W. Shao
Telecom-ParisTech Cisco
October 19, 2018 March 8, 2019
Discovering Provisioning Domain Names and Data Discovering Provisioning Domain Names and Data
draft-ietf-intarea-provisioning-domains-03 draft-ietf-intarea-provisioning-domains-04
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 April 22, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Provisioning Domain Identification using Router 3. Provisioning Domain Identification using Router
Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. PvD ID Option for Router Advertisements . . . . . . . . . 4 3.1. PvD ID Option for Router Advertisements . . . . . . . . . 4
3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 3.2. Router Behavior . . . . . . . . . . . . . . . . . . . . . 7
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 3.4.4. Usage of DNS Servers . . . . . . . . . . . . . . . . 10
4.1. Retrieving the PvD Additional Information . . . . . . . . 10 4. Provisioning Domain Additional Information . . . . . . . . . 11
4.1. Retrieving the PvD Additional Information . . . . . . . . 11
4.2. Operational Consideration to Providing the PvD Additional 4.2. Operational Consideration to Providing the PvD Additional
Information . . . . . . . . . . . . . . . . . . . . . . . 12 Information . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. PvD Additional Information Format . . . . . . . . . . . . 12 4.3. PvD Additional Information Format . . . . . . . . . . . . 13
4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 14 4.3.1. Private Extensions . . . . . . . . . . . . . . . . . 14
4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Detecting misconfiguration and misuse . . . . . . . . . . 14 4.4. Detecting misconfiguration and misuse . . . . . . . . . . 15
5. Operational Considerations . . . . . . . . . . . . . . . . . 15 5. Operational Considerations . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. Additional Information PvD Keys Registry . . . . . . . . 18
8.2. PvD Option Flags Registry . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative references . . . . . . . . . . . . . . . . . . 18 10.1. Normative references . . . . . . . . . . . . . . . . . . 19
10.2. Informative references . . . . . . . . . . . . . . . . . 19 10.2. Informative references . . . . . . . . . . . . . . . . . 20
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 22
A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 21 A.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 22
A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 23
A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 22 A.4. WG Document version 00 . . . . . . . . . . . . . . . . . 23
A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 23 A.5. WG Document version 01 . . . . . . . . . . . . . . . . . 24
A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 23 A.6. WG Document version 02 . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 A.7. WG Document version 04 . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
It has become very common in modern networks for hosts to access the 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 8, line 4 skipping to change at page 8, line 4
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.
As specified in [RFC4861], when the set of options causes the size of As specified in [RFC4861], when the set of options causes the size of
an advertisement to exceed the link MTU, multiple router an advertisement to exceed the link MTU, multiple router
advertisements can be sent, each containing a subset of the options. advertisements can be sent, each containing a subset of the options.
In such cases, the PvD option header (i.e., all fields except the In such cases, the PvD option header (i.e., all fields except the
'Options' field) MUST be repeated in all the transmitted RAs. But 'Options' field) MUST be repeated in all the transmitted RAs. The
the options within the 'Options' field, MAY be transmitted only once, options within the 'Options' field, MAY be transmitted only once,
included in one of the transmitted PvD options. 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.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
information (e.g., Router Valid Lifetime, Prefix Information information (e.g., Router Valid Lifetime, Prefix Information
[RFC4861], Recursive DNS Server [RFC8106], Routing Information [RFC4861], Recursive DNS Server [RFC8106], Routing Information
[RFC4191] options) with the explicit PvD identified by the first PvD [RFC4191] options) with the explicit PvD identified by the first PvD
Option present in the received RA, if any, or with the implicit PvD Option present in the received RA, if any, or with the implicit PvD
identified by the host interface and the source address of the identified by the host interface and the source address of the
received RA otherwise. received RA otherwise.
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
(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 which last
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 (i.e., A=a), PvD IDs MUST be compared in a case-insensitive manner (i.e., A=a),
assuming ASCII with zero parity while non-alphabetic codes must match assuming ASCII with zero parity while non-alphabetic codes must match
exactly (see also Section 3.1 of [RFC1035]). For example, exactly (see also Section 3.1 of [RFC1035]). For example,
skipping to change at page 9, line 45 skipping to change at page 9, line 48
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 host shares connectivity from an upstream The situation when a host shares connectivity from an upstream
interface (e.g. cellular) to a downstream interface (e.g. WiFi) is interface (e.g. cellular) to a downstream interface (e.g. WiFi) is
known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share known as 'tethering'. Techniques such as ND-proxy [RFC4389], 64share
[RFC7278] or prefix delegation (e.g. using DHCPv6-PD [RFC3633]) may [RFC7278] or prefix delegation (e.g. using DHCPv6-PD [RFC8415]) may
be used for that purpose. be used for that purpose.
Whenever the RAs received from the upstream interface contain a PVD Whenever the RAs received from the upstream interface contain a PVD
RA option, hosts that are sharing connectivity SHOULD include a PVD RA option, hosts that are sharing connectivity SHOULD include a PVD
Option within the RAs sent downstream with: Option within the RAs sent downstream with:
The same PVD-ID FQDN. The same PVD-ID FQDN.
The same H-bit, Delay and Sequence Number values. The same H-bit, Delay and Sequence Number values.
The L bit set whenever the host is sharing IPv4 connectivity The L bit set whenever the host is sharing IPv4 connectivity
received from the same upstream interface. received from the same upstream interface.
The bits from the Reserved field set to 0. The bits from the Reserved field set to 0.
The values of the R-bit, Router Advertisement message header and The values of the R-bit, Router Advertisement message header and
Options field depend on whether the connectivity should be shared Options field depend on whether the connectivity should be shared
only with PvD aware hosts or not (see Section 3.2). In particular, only with PvD-aware hosts or not (see Section 3.2). In particular,
all options received within the upstream PvD option and included in all options received within the upstream PvD option and included in
the downstream RA SHOULD be included in the downstream PvD option. the downstream RA SHOULD be included in the downstream PvD option.
3.4.4. Usage of DNS Servers
PvD-aware hosts can be provisioned with recursive DNS servers via RA
options passed within an explicit PvD, via RA options associated with
an implicit PvD, via DHCPv6 or DHCPv4, or from some other
provisioning mechanism that creates an implicit PvD (such as a VPN).
In all of these cases, the DNS server addresses SHOULD be strongly
associated with the corresponding PvD. Specificially, queries sent
to a configured recursive DNS server SHOULD be sent from a local IP
address that belongs to the matching PvD. Answers received from the
DNS server SHOULD only be used on the same PvD.
Maintaining the correct usage of DNS within PvDs avoids various
practical errors, such as:
A PvD associated with a VPN or otherwise private network may
provide DNS answers that contain addresses inaccessible over
another PvD.
A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will
synthesize IPv6 addresses in DNS answers that are not globally
routable, and cannot be used on other PvDs. Conversely, an IPv4
address resolved via DNS on another PvD cannot be directly used on
a NAT64 network without the host synthesizing an IPv6 address.
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
typically includes data that would be considered too large, or not typically includes data that would be considered too large, or not
skipping to change at page 14, line 42 skipping to change at page 15, line 26
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
} }
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. But this does not mean the Advertising Router and the HTTPS server. However, this does not mean the Advertising Router and
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 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 IPv6 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
skipping to change at page 15, line 27 skipping to change at page 16, line 9
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
o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
o PvD Option header: length = 3+ 5 +4 , PvD ID FQDN = example.org., o PvD Option header: length = 3 + 5 + 4 , PvD ID FQDN =
R-flag = 0 (actual length of the header with padding 24 bytes = 3 example.org., R-flag = 0 (actual length of the header with padding
* 8 bytes) 24 bytes = 3 * 8 bytes)
* Recursive DNS Server: length = 5, addresses= * Recursive DNS Server: length = 5, addresses=
[2001:db8:cafe::53, 2001:db8:f00d::53] [2001:db8:cafe::53, 2001:db8:f00d::53]
* Prefix Information Option: length = 4, prefix = * Prefix Information Option: length = 4, prefix =
2001:db8:f00d::/64 2001:db8:f00d::/64
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
skipping to change at page 15, line 51 skipping to change at page 16, line 33
For example, here is the RA for non-PvD-aware hosts: For example, here is the RA for non-PvD-aware hosts:
o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use o RA Header: router lifetime = 6000 (non-PvD-aware hosts will use
this router as a default router) this router as a default router)
o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64 o Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
o Recursive DNS Server Option: length = 3, addresses= o Recursive DNS Server Option: length = 3, addresses=
[2001:db8:cafe::53] [2001:db8:cafe::53]
o PvD Option header: length = 3+ 2, PvD ID FQDN = foo.example.org., o PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org.,
R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes) R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes)
* RA Header: router lifetime = 0 (PvD-aware hosts will not use * RA Header: router lifetime = 0 (PvD-aware hosts will not use
this router as a default router), implicit length = 2 this router as a default router), implicit length = 2
And here is a RA example for PvD-aware hosts: And here is a RA example for PvD-aware hosts:
o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use o RA Header: router lifetime = 0 (non-PvD-aware hosts will not use
this router as a default router) this router as a default router)
o PvD Option header: length = 3+ 2 + 4 + 3, PvD ID FQDN = o PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN =
example.org., R-flag = 1 (actual length of the header 24 bytes = 3 example.org., R-flag = 1 (actual length of the header 24 bytes = 3
* 8 bytes) * 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=
skipping to change at page 17, line 44 skipping to change at page 18, line 25
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 IANA is asked to assign the value "pvd" from the Well-Known URIs
registry. registry.
IANA is asked to create and maintain a new registry entitled 8.1. Additional Information PvD Keys Registry
"Additional Information PvD Keys" containing ASCII strings. The
initial content of this registry are given in Section 4.3; future
assignments are to be made through Expert Review [BCP36].
Finally, IANA is asked to create and maintain a new registry entitled IANA is asked to create and maintain a new registry called
"PvD option Flags" reserving bit positions from 0 to 15 to be used in "Additional Information PvD Keys", which will reserve JSON keys for
use in PvD additional information. The initial contents of this
registry are given in Section 4.3.
New assignments for Additional Information PvD Keys Registry will be
administered by IANA through Expert Review RFC8126 [RFC8126].
8.2. PvD Option Flags Registry
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
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 a document (as specified in Figure 1). Future assignments require
Standard Track RFC document. Standards Action RFC8126 [RFC8126], via a Standards Track RFC
document.
9. Acknowledgements 9. Acknowledgements
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 Abrahamson, Ray Bellis, Zhen Cao, Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen
Tim Chow, Lorenzo Colitti, Ian Farrer, Bob Hinden, Tatuya Jinmei, Cao, Tim Chow, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer,
Erik Kline, Ted Lemon, Jen Lenkova, Veronika McKillop, Mark Townsley Bob Hinden, Tatuya Jinmei, Erik Kline, Ted Lemon, Jen Lenkova,
and James Woodyatt for useful and interesting discussions. Veronika McKillop, Mark Townsley and James Woodyatt for useful and
interesting discussions.
Finally, special thanks to Thierry Danis and Wenqin Shao for their Finally, special thanks to Thierry Danis and Wenqin Shao for their
valuable inputs and implementation efforts ([github]), Tom Jones for valuable inputs and implementation efforts ([github]), Tom Jones for
his integration effort into the NEAT project and Rigil Salim for his his integration effort into the NEAT project and Rigil Salim for his
implementation work. implementation work.
10. References 10. References
10.1. Normative references 10.1. Normative references
skipping to change at page 19, line 45 skipping to change at page 20, line 36
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 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
skipping to change at page 20, line 33 skipping to change at page 21, line 15
[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>.
[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
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<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, [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
Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
<https://www.rfc-editor.org/info/rfc6731>.
[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 [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,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
Appendix A. Changelog Appendix A. Changelog
Note to RFC Editors: Remove this section before publication. Note to RFC Editors: Remove this section before publication.
A.1. Version 00 A.1. Version 00
Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke Initial version of the draft. Edited by Basile Bruneau + Eric Vyncke
and based on Basile's work. and based on Basile's work.
A.2. Version 01 A.2. Version 01
skipping to change at page 24, line 14 skipping to change at page 25, line 14
added more reference to RFC 7556 (notably for PvD being globally added more reference to RFC 7556 (notably for PvD being globally
unique, introducing PvD-aware host vs. PvD-aware node) unique, introducing PvD-aware host vs. PvD-aware node)
Section 3.4.3 renamed from "interconnection shared by node" to Section 3.4.3 renamed from "interconnection shared by node" to
'connection shared by node" 'connection shared by node"
Section 3.4 renamed into "PvD-aware Host Behavior" Section 3.4 renamed into "PvD-aware Host Behavior"
Added a section "Non-PvD-aware Host Behavior" Added a section "Non-PvD-aware Host Behavior"
A.7. WG Document version 04
Updated reference for DHCPv6-PD from RFC 3633 to RFC 8415.
Enhanced IANA considerations to clarify review process and new
registries.
Added a section on considerations for handling DNS on a PvD-aware
host.
Authors' Addresses Authors' Addresses
Pierre Pfister Pierre Pfister
Cisco Cisco
11 Rue Camille Desmoulins 11 Rue Camille Desmoulins
Issy-les-Moulineaux 92130 Issy-les-Moulineaux 92130
France France
Email: ppfister@cisco.com Email: ppfister@cisco.com
skipping to change at page 24, line 36 skipping to change at page 26, line 4
De Kleetlaan, 6 De Kleetlaan, 6
Diegem 1831 Diegem 1831
Belgium Belgium
Email: evyncke@cisco.com Email: evyncke@cisco.com
Tommy Pauly Tommy Pauly
Apple Apple
Email: tpauly@apple.com Email: tpauly@apple.com
David Schinazi David Schinazi
Apple Google LLC
1600 Amphitheatre Parkway
Mountain View, California 94043
USA
Email: dschinazi@apple.com Email: dschinazi.ietf@gmail.com
Wenqin Shao Wenqin Shao
Telecom-ParisTech Cisco
11 Rue Camille Desmoulins
Issy-les-Moulineaux 92130
France France
Email: wenqin.shao@telecom-paristech.fr Email: wenshao@cisco.com
 End of changes. 37 change blocks. 
63 lines changed or deleted 127 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/