draft-ietf-homenet-naming-architecture-dhc-options-10.txt   draft-ietf-homenet-naming-architecture-dhc-options-11.txt 
Homenet D. Migault Homenet D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track R. Weber Intended status: Standards Track R. Weber
Expires: October 3, 2021 Akamai Expires: October 15, 2021 Akamai
T. Mrugalski T. Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
C. Griffiths C. Griffiths
W. Cloetens W. Cloetens
Deutsche Telekom Deutsche Telekom
April 01, 2021 April 13, 2021
DHCPv6 Options for Home Network Naming Authority DHCPv6 Options for Home Network Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-10 draft-ietf-homenet-naming-architecture-dhc-options-11
Abstract Abstract
This document defines DHCPv6 options so an agnostic Homenet Naming This document defines DHCPv6 options so an agnostic Homenet Naming
Authority (HNA) can automatically proceed to the appropriate Authority (HNA) can automatically proceed to the appropriate
configuration and outsource the authoritative naming service for the configuration and outsource the authoritative naming service for the
home network. In most cases, the outsourcing mechanism is home network. In most cases, the outsourcing mechanism is
transparent for the end user. transparent for the end user.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 October 3, 2021. This Internet-Draft will expire on October 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 18 skipping to change at page 2, line 18
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4
4.1. Registered Homenet Domain Option . . . . . . . . . . . . 5 4.1. Registered Homenet Domain Option . . . . . . . . . . . . 4
4.2. Distribution Master Option . . . . . . . . . . . . . . . 5 4.2. Distribution Master Option . . . . . . . . . . . . . . . 5
4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6 4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6
4.3. Reverse Distribution Master Server Option . . . . . . . . 6 4.3. Reverse Distribution Master Server Option . . . . . . . . 6
5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7
5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7
5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations" . . . . . . . . . . . . . . . . . . 8 7. Security Considerations" . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Scenarios and impact on the End User . . . . . . . . 11 Appendix A. Scenarios and impact on the End User . . . . . . . . 11
Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 11 Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 11
B.1. Third Party Registered Homenet Domain . . . . . . . . . . 11 B.1. Third Party Registered Homenet Domain . . . . . . . . . . 11
B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 12 B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 12
B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12 B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Terminology 1. Terminology
skipping to change at page 3, line 44 skipping to change at page 3, line 44
This document describes DHCPv6 options that enables the ISP to This document describes DHCPv6 options that enables the ISP to
provide the necessary parameters to the HNA, to proceed. provide the necessary parameters to the HNA, to proceed.
More specifically, the ISP provides the Registered Homenet Domain, More specifically, the ISP provides the Registered Homenet Domain,
necessary information on the DM and the RDM so the HNA can manage and necessary information on the DM and the RDM so the HNA can manage and
upload the Public Homenet Zone and the Reverse Public Homenet Zone as upload the Public Homenet Zone and the Reverse Public Homenet Zone as
described in [I-D.ietf-homenet-front-end-naming-delegation]. described in [I-D.ietf-homenet-front-end-naming-delegation].
The use of DHCPv6 options makes the configuration completely The use of DHCPv6 options makes the configuration completely
transparent to the end user and provides a similar level of trust as transparent to the end user and provides a similar level of trust as
the one used to provide the IP prefix. The link between the HNA and the one used to provide the IP prefix.
the DHCPv6 server may benefit from additional security for example by
using [I-D.ietf-dhc-sedhcpv6].
3. Protocol Overview 3. Protocol Overview
This section illustrates how a HNA receives the necessary information This section illustrates how a HNA receives the necessary information
via DHCPv6 options to outsource its authoritative naming service to via DHCPv6 options to outsource its authoritative naming service to
the DOI. For the sake of simplicity, and similarly to the DOI. For the sake of simplicity, and similarly to
[I-D.ietf-homenet-front-end-naming-delegation], this section assumes [I-D.ietf-homenet-front-end-naming-delegation], this section assumes
that the HNA and the home network DHCPv6 client are collocated on the that the HNA and the home network DHCPv6 client are collocated on the
CPE. Note also that this is not mandatory and specific CPE. Note also that this is not mandatory and specific
communications between the HNA and the DHCPv6 client only are needed. communications between the HNA and the DHCPv6 client only are needed.
In addition, this section assumes the responsible entity for the In addition, this section assumes the responsible entity for the
DHCPv6 server is able to configure the DM and RDM. In our case, this DHCPv6 server is able to configure the DM and RDM. In our case, this
means a Registered Homenet Domain can be associated to the DHCP means a Registered Homenet Domain can be associated to the DHCP
client. client.
This scenario has been chosen as it is believed to be the most This scenario has been chosen as it is believed to be the most
skipping to change at page 8, line 34 skipping to change at page 8, line 34
IANA is requested to maintain a new number space of Supported IANA is requested to maintain a new number space of Supported
Transport parameter in the Distributed Master Option Transport parameter in the Distributed Master Option
(OPTION_DIST_MASTER) or the Reverse Distribution Master Server Option (OPTION_DIST_MASTER) or the Reverse Distribution Master Server Option
(OPTION_REVERSE_DIST_MASTER). The different parameters are defined (OPTION_REVERSE_DIST_MASTER). The different parameters are defined
in Figure 3 in Section 4.2.1. Future code points 4 - 8 are assigned in Figure 3 in Section 4.2.1. Future code points 4 - 8 are assigned
under the IETF Review, other code points are assigned under under the IETF Review, other code points are assigned under
Specification Required as per [RFC8126]. Specification Required as per [RFC8126].
7. Security Considerations" 7. Security Considerations"
The security considerations in [RFC2131] and [RFC8415] are to be
considered.
The use of DHCPv6 options provides a similar level of trust as the
one used to provide the IP prefix. The link between the HNA and the
DHCPv6 server may benefit from additional security for example by
using [I-D.ietf-dhc-sedhcpv6].
8. Acknowledgments 8. Acknowledgments
We would like to thank Marcin Siodelski and Bernie Volz for their We would like to thank Marcin Siodelski and Bernie Volz for their
comments on the design of the DHCPv6 options. We would also like to comments on the design of the DHCPv6 options. We would also like to
thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their
remarks on the architecture design. The designed solution has been remarks on the architecture design. The designed solution has been
largely been inspired by Mark Andrews's document largely been inspired by Mark Andrews's document
[I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We
also thank Ray Hunter for its reviews, its comments and for also thank Ray Hunter for its reviews, its comments and for
suggesting an appropriated terminology. suggesting an appropriated terminology.
skipping to change at page 9, line 18 skipping to change at page 9, line 27
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>. <https://www.rfc-editor.org/info/rfc6672>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
 End of changes. 10 change blocks. 
11 lines changed or deleted 19 lines changed or added

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