draft-ietf-homenet-naming-architecture-dhc-options-11.txt   draft-ietf-homenet-naming-architecture-dhc-options-12.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 15, 2021 Akamai Expires: October 30, 2021 Akamai
T. Mrugalski T. Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
C. Griffiths April 28, 2021
W. Cloetens
Deutsche Telekom
April 13, 2021
DHCPv6 Options for Home Network Naming Authority DHCPv6 Options for Home Network Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-11 draft-ietf-homenet-naming-architecture-dhc-options-12
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 37
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 15, 2021. This Internet-Draft will expire on October 30, 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 25 skipping to change at page 2, line 21
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 . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations" . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 7 skipping to change at page 3, line 7
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader is expected to be familiar with The reader is expected to be familiar with
[I-D.ietf-homenet-front-end-naming-delegation] and its terminology [I-D.ietf-homenet-front-end-naming-delegation] and its terminology
section. section.
2. Introduction 2. Introduction
[I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet [I-D.ietf-homenet-front-end-naming-delegation] specifies how an
Naming Authority (HNA) outsources the Public Homenet Zone to an entity designated as the Homenet Naming Authority (HNA) outsources a
Outsourcing Infrastructure. Public Homenet Zone to an Outsourcing DNS Infrastructure (DOI).
This document shows how an ISP can provision automatically the HNA This document shows how an ISP can provision automatically the HNA
with a DNS Outsourcing Infrastructure (DOI). Most likely the DOI with a specific DOI. Most likely the DOI will be - at least partly
will be - at least partly be - managed or provided by its ISP, but be - managed or provided by its ISP, but other cases may envision the
other cases may envision the ISP storing some configuration so the ISP storing some configuration so the homenet becomes resilient to
homenet becomes resilient to HNA replacement. HNA replacement.
The ISP delegates the home network an IP prefix it owns as well as The ISP delegates the home network an IP prefix it owns as well as
the associated reverse zone. the associated reverse zone. The ISP is well aware of the owner of
The ISP is well aware of the owner of that prefix, and as such that prefix, and as such becomes a natural candidate for hosting the
becomes a natural candidate for hosting the Homenet Reverse Zone - Homenet Reverse Zone - that is the Reverse Distribution Master (RDM)
that is the Reverse Distribution Master (RDM) and potentially the and potentially the Reverse Public Authoritative Servers.
Reverse Public Authoritative Servers.
In addition, the ISP often identifies the home network with a name. In addition, the ISP often identifies the home network with a name.
In most cases, the name is used by the ISP for its internal network In most cases, the name is used by the ISP for its internal network
management operations and is not a name the home network owner has management operations and is not a name the home network owner has
registered to. The ISP may thus leverage such infrastructure and registered to. The ISP may thus leverage such infrastructure and
provide the homenet a specific domain name designated as per provide the homenet a specific domain name designated as per
[I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered
Domain. Similarly to the reverse zone, the ISP is well aware of who Domain. Similarly to the reverse zone, the ISP is well aware of who
owns that domain name and may become a natural candidate for hosting owns that domain name and may become a natural candidate for hosting
the Homenet Zone - that is the Distribution Master (DM) and the the Homenet Zone - that is the Distribution Master (DM) and the
Public Authoritative Servers. Public Authoritative Servers.
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
More specifically, the ISP provides the Registered Homenet Domain, 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 one used to provide the IP prefix.
3. Protocol Overview 3. Protocol Overview
skipping to change at page 6, line 23 skipping to change at page 6, line 23
4.2.1. Supported Transport 4.2.1. Supported Transport
The Supported Transport filed of the DHCPv6 option indicates the The Supported Transport filed of the DHCPv6 option indicates the
supported transport protocol. Each bit represents a specific supported transport protocol. Each bit represents a specific
transport mechanism. The bit sets to 1 indicates the associated transport mechanism. The bit sets to 1 indicates the associated
transport protocol is supported. The corresponding bits are assigned transport protocol is supported. The corresponding bits are assigned
as described in Figure 3. as described in Figure 3.
Bit | Transport Protocol | Reference Bit | Transport Protocol | Reference
----+--------------------+----------- ----+--------------------+-----------
0 | DNS | This-RFC 0 | DNS over TLS | This-RFC
1 | DNS over TLS | This-RFC 1-15| unallocated |
2 | DNS over HTTPS | This-RFC
3 | DNS over QUIC | This-RFC
4-15| unallocated | This-RFC
Figure 3: Supported Transport Figure 3: Supported Transport
o DNS: indicates the support of DNS over port 53 as described in
[RFC1035].
o DNS over TLS: indicates the support of DNS over TLS as described o DNS over TLS: indicates the support of DNS over TLS as described
in [RFC7858]. in [RFC7858].
o DNS over HTTPS: indicates the support of DNS over HTTPS as
described in [RFC8484].
o DNS over QUIC: indicates the support of DNS over QUIC as defined
in [I-D.ietf-dprive-dnsoquic].
4.3. Reverse Distribution Master Server Option 4.3. Reverse Distribution Master Server Option
The Reverse Distribution Master Server Option The Reverse Distribution Master Server Option
(OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as (OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as
well as the transport protocol for the transaction between the HNA well as the transport protocol for the transaction between the HNA
and the DM. and the DM.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 28 skipping to change at page 8, line 14
Value Description Client ORO Singleton Option Value Description Client ORO Singleton Option
TBD1 OPTION_REGISTERED_DOMAIN Yes Yes TBD1 OPTION_REGISTERED_DOMAIN Yes Yes
TBD2 OPTION_DIST_MASTER Yes Yes TBD2 OPTION_DIST_MASTER Yes Yes
TBD3 OPTION_REVERSE_DIST_MASTER Yes Yes TBD3 OPTION_REVERSE_DIST_MASTER Yes Yes
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 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 The security considerations in [RFC2131] and [RFC8415] are to be
considered. considered. The use of DHCPv6 options provides a similar level of
The use of DHCPv6 options provides a similar level of trust as the trust as the one used to provide the IP prefix. The link between the
one used to provide the IP prefix. The link between the HNA and the HNA and the DHCPv6 server may benefit from additional security for
DHCPv6 server may benefit from additional security for example by example by using [I-D.ietf-dhc-sedhcpv6].
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, Bernie Volz and Ted Lemon
comments on the design of the DHCPv6 options. We would also like to for their comments on the design of the DHCPv6 options. We would
thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti
remarks on the architecture design. The designed solution has been for their remarks on the architecture design. The designed solution
largely been inspired by Mark Andrews's document has been 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.
9. References 9. Contributors
9.1. Normative References The co-authors would like to thank Chris Griffiths and Wouter
Cloetens that provided a significant contribution in the early
versions of the document.
[I-D.ietf-dprive-dnsoquic] 10. References
Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-ietf- 10.1. Normative References
dprive-dnsoquic-01 (work in progress), October 2020.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/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", [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>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
skipping to change at page 10, line 11 skipping to change at page 9, line 42
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 10.2. Informative References
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
9.2. Informative References
[I-D.andrews-dnsop-pd-reverse] [I-D.andrews-dnsop-pd-reverse]
Andrews, M., "Automated Delegation of IP6.ARPA reverse Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", draft-andrews-dnsop-pd- zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013. reverse-02 (work in progress), November 2013.
[I-D.ietf-dhc-sedhcpv6] [I-D.ietf-dhc-sedhcpv6]
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017. in progress), February 2017.
[I-D.ietf-homenet-front-end-naming-delegation] [I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Richardson, M., Hunter, R., Migault, D., Weber, R., Richardson, M., Hunter, R.,
Griffiths, C., and W. Cloetens, "Simple Provisioning of Griffiths, C., and W. Cloetens, "Simple Provisioning of
Public Names for Residential Networks", draft-ietf- Public Names for Residential Networks", draft-ietf-
homenet-front-end-naming-delegation-12 (work in progress), homenet-front-end-naming-delegation-13 (work in progress),
November 2020. March 2021.
[I-D.sury-dnsext-cname-dname] [I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury- Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010. dnsext-cname-dname-00 (work in progress), April 2010.
Appendix A. Scenarios and impact on the End User Appendix A. Scenarios and impact on the End User
This section details various scenarios and discuss their impact on This section details various scenarios and discuss their impact on
the end user. This section is not normative and limits the the end user. This section is not normative and limits the
description of a limited scope of scenarios that are assumed to be description of a limited scope of scenarios that are assumed to be
skipping to change at page 11, line 36 skipping to change at page 11, line 36
The main advantage of this scenario is that the naming architecture The main advantage of this scenario is that the naming architecture
is configured automatically and transparently for the end user. The is configured automatically and transparently for the end user. The
drawbacks are that the end user uses a Registered Homenet Domain drawbacks are that the end user uses a Registered Homenet Domain
managed by the ISP and that it relies on the ISP naming managed by the ISP and that it relies on the ISP naming
infrastructure. infrastructure.
B.1. Third Party Registered Homenet Domain B.1. Third Party Registered Homenet Domain
This section considers the case when the end user wants its home This section considers the case when the end user wants its home
network to use example.com not managed by her ISP (foo) as a network to use example.com not managed by her ISP (foo) as a
Registered Homenet Domain. This section still consider the ISP
manages the home network and still provides example.foo as a
Registered Homenet Domain. Registered Homenet Domain.
This section still consider the ISP manages the home network and
still provides example.foo as a Registered Homenet Domain.
When the end user buys the domain name example.com, it may request to When the end user buys the domain name example.com, it may request to
redirect the name example.com to example.foo using static redirection redirect the name example.com to example.foo using static redirection
with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname]. [I-D.sury-dnsext-cname-dname].
This configuration is performed once when the domain name example.com This configuration is performed once when the domain name example.com
is registered. The only information the end user needs to know is is registered. The only information the end user needs to know is
the domain name assigned by the ISP. Once this configuration is done the domain name assigned by the ISP. Once this configuration is done
no additional configuration is needed anymore. More specifically, no additional configuration is needed anymore. More specifically,
the HNA may be changed, the zone can be updated as in Appendix B the HNA may be changed, the zone can be updated as in Appendix B
without any additional configuration from the end user. without any additional configuration from the end user.
The main advantage of this scenario is that the end user benefits The main advantage of this scenario is that the end user benefits
from the Zero Configuration of the Base Scenario Appendix B. Then, from the Zero Configuration of the Base Scenario Appendix B. Then,
the end user is able to register for its home network an unlimited the end user is able to register for its home network an unlimited
number of domain names provided by an unlimited number of different number of domain names provided by an unlimited number of different
third party providers. third party providers. The drawback of this scenario may be that the
The drawback of this scenario may be that the end user still rely on end user still rely on the ISP naming infrastructure. Note that the
the ISP naming infrastructure. Note that the only case this may be only case this may be inconvenient is when the DNS Servers provided
inconvenient is when the DNS Servers provided by the ISPs results in by the ISPs results in high latency.
high latency.
B.2. Third Party DNS Infrastructure B.2. Third Party DNS Infrastructure
This scenario considers that the end user uses example.com as a This scenario considers that the end user uses example.com as a
Registered Homenet Domain, and does not want to rely on the Registered Homenet Domain, and does not want to rely on the
authoritative servers provided by the ISP. authoritative servers provided by the ISP.
In this section we limit the outsourcing to the DM and Public In this section we limit the outsourcing to the DM and Public
Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) to a third party. The Reverse Public
Authoritative Server(s) and the RDM remain managed by the ISP as the Authoritative Server(s) and the RDM remain managed by the ISP as the
skipping to change at page 14, line 16 skipping to change at line 585
EMail: ralf.weber@akamai.com EMail: ralf.weber@akamai.com
Tomek Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City 94063 Redwood City 94063
US US
EMail: tomasz.mrugalski@gmail.com EMail: tomasz.mrugalski@gmail.com
Chris Griffiths
EMail: cgriffiths@gmail.com
Wouter Cloetens
Deutsche Telekom
EMail: wouter.cloetens@external.telekom.de
 End of changes. 27 change blocks. 
79 lines changed or deleted 53 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/