draft-ietf-homenet-front-end-naming-delegation-03.txt   draft-ietf-homenet-front-end-naming-delegation-04.txt 
HOMENET D. Migault (Ed) HOMENET D. Migault (Ed)
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track R. Weber Intended status: Standards Track R. Weber
Expires: January 3, 2016 Nominum Expires: March 26, 2016 Nominum
R. Hunter R. Hunter
Globis Consulting BV Globis Consulting BV
C. Griffiths C. Griffiths
W. Cloetens W. Cloetens
SoftAtHome SoftAtHome
July 2, 2015 September 23, 2015
Outsourcing Home Network Authoritative Naming Service Outsourcing Home Network Authoritative Naming Service
draft-ietf-homenet-front-end-naming-delegation-03.txt draft-ietf-homenet-front-end-naming-delegation-04.txt
Abstract Abstract
RFC7368 'IPv6 Home Networking Architecture Principles' section 3.7 RFC7368 'IPv6 Home Networking Architecture Principles' section 3.7
describes architecture principles related to naming and service describes architecture principles related to naming and service
discovery in residential home networks. discovery in residential home networks.
Customer Edge Routers and other Customer Premises Equipment (CPEs) Customer Edge Routers and other Customer Premises Equipment (CPEs)
are designed to provide IP connectivity to home networks. Most CPEs are designed to provide IP connectivity to home networks. Most CPEs
assign IP addresses to the nodes of the home network which makes them assign IP addresses to the nodes of the home network which makes them
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 3, 2016. This Internet-Draft will expire on March 26, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Scope of the Document . . . . . . . . . . . . . . . . . . 4
4. Architecture Description . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Architecture Overview . . . . . . . . . . . . . . . . . . 6 4. Architecture Description . . . . . . . . . . . . . . . . . . 7
4.2. Example: Homenet Zone . . . . . . . . . . . . . . . . . . 8 4.1. Architecture Overview . . . . . . . . . . . . . . . . . . 7
4.3. Example: CPE necessary parameters for outsourcing . . . . 10 4.2. Example: Homenet Zone . . . . . . . . . . . . . . . . . . 9
5. Synchronization between CPE and the Synchronization Server . 11 4.3. Example: CPE necessary parameters for outsourcing . . . . 11
5.1. Synchronization with a Hidden Primary . . . . . . . . . . 11 5. Synchronization between CPE and the Synchronization Server . 12
5.2. Securing Synchronization . . . . . . . . . . . . . . . . 12 5.1. Synchronization with a Hidden Primary . . . . . . . . . . 12
5.3. CPE Security Policies . . . . . . . . . . . . . . . . . . 13 5.2. Securing Synchronization . . . . . . . . . . . . . . . . 13
6. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 14 5.3. CPE Security Policies . . . . . . . . . . . . . . . . . . 15
6.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 14 6. DNSSEC compliant Homenet Architecture . . . . . . . . . . . . 15
6.2. Secure Delegation . . . . . . . . . . . . . . . . . . . . 16 6.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Secure Delegation . . . . . . . . . . . . . . . . . . . . 17
7. Handling Different Views . . . . . . . . . . . . . . . . . . 16 7. Handling Different Views . . . . . . . . . . . . . . . . . . 18
7.1. Misleading Reasons for Local Scope DNS Zone . . . . . . . 17 7.1. Misleading Reasons for Local Scope DNS Zone . . . . . . . 18
7.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Guidance and Recommendations . . . . . . . . . . . . . . 18 7.3. Guidance and Recommendations . . . . . . . . . . . . . . 19
8. Homenet Reverse Zone . . . . . . . . . . . . . . . . . . . . 19 8. Homenet Reverse Zone . . . . . . . . . . . . . . . . . . . . 20
9. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Renumbering . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 19 9.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 21
9.2. Synchronization Server . . . . . . . . . . . . . . . . . 21 9.2. Synchronization Server . . . . . . . . . . . . . . . . . 22
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11.1. Names are less secure than IP addresses . . . . . . . . 22 11.1. Names are less secure than IP addresses . . . . . . . . 23
11.2. Names are less volatile than IP addresses . . . . . . . 23 11.2. Names are less volatile than IP addresses . . . . . . . 24
11.3. DNS Reflection Attacks . . . . . . . . . . . . . . . . . 23 11.3. DNS Reflection Attacks . . . . . . . . . . . . . . . . . 24
11.3.1. Reflection Attack involving the Hidden Primary . . . 23 11.3.1. Reflection Attack involving the Hidden Primary . . . 24
11.3.2. Reflection Attacks involving the Synchronization 11.3.2. Reflection Attacks involving the Synchronization
Server . . . . . . . . . . . . . . . . . . . . . . . 25 Server . . . . . . . . . . . . . . . . . . . . . . . 26
11.3.3. Reflection Attacks involving the Public 11.3.3. Reflection Attacks involving the Public
Authoritative Servers . . . . . . . . . . . . . . . 25 Authoritative Servers . . . . . . . . . . . . . . . 27
11.4. Flooding Attack . . . . . . . . . . . . . . . . . . . . 26 11.4. Flooding Attack . . . . . . . . . . . . . . . . . . . . 27
11.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . 26 11.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . 27
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 27 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
14.2. Informational References . . . . . . . . . . . . . . . . 29 14.2. Informational References . . . . . . . . . . . . . . . . 31
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 30 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
IPv6 provides global end to end IP reachability. End users prefer to IPv6 provides global end to end IP reachability. End users prefer to
skipping to change at page 4, line 35 skipping to change at page 4, line 36
performed either by the CPE or by the Outsourcing Infrastructure. performed either by the CPE or by the Outsourcing Infrastructure.
Section 6 discusses these two alternatives. Section 7 discusses the Section 6 discusses these two alternatives. Section 7 discusses the
consequences of publishing multiple representations of the same zone consequences of publishing multiple representations of the same zone
also commonly designated as views. This section provides guidance to also commonly designated as views. This section provides guidance to
limit the risks associated with multiple views. Section 8 discusses limit the risks associated with multiple views. Section 8 discusses
management of the reverse zone. Section 9 discusses how renumbering management of the reverse zone. Section 9 discusses how renumbering
should be handled. Finally, Section 10 and Section 11 respectively should be handled. Finally, Section 10 and Section 11 respectively
discuss privacy and security considerations when outsourcing the discuss privacy and security considerations when outsourcing the
Homenet Zone. Homenet Zone.
2.1. Scope of the Document
The scope of the document is to describe an architecture that
outsources the authoritative naming service of the home network and
more specifically the interactions between the home network and the
Outsourcing Infrastructure. Considerations or descriptions on inner
communications or organization of the home network are provided for
completeness and for clarifying the interface between the home
network and the Outsourcing Infrastructure
For sake of simplicity, this document designates by "CPE" that
connects the home network with the Outsourcing Infrastructure - and
so performs most of the operations for outsourcing the home network
naming architecture. On the other hand, CPE are usually associated
to home router. These two functions - e.g routing and naming - are
not correlated and could be split in multiple devices. More
specifically, this document does not consider the home network has a
single CPE nor a single ISP.
In fact this document considers the CPE as a set of functionalities
that can be collocated on a single device or split between multiple
devices. The split of these functions between different devices as
well as their potential associated communications is considered as
implementation dependent and out of scope of the architecture. The
only limitation this architecture considers is that the Hidden
Primary be located in a single place as long as the distributed
Primary architecture has not been defined. As a result, if there are
multiple candidates for hosting the Hidden Primary, the home network
should select a single device.
3. Terminology 3. Terminology
- Customer Premises Equipment: (CPE) is the router providing - Customer Premises Equipment: (CPE) is a router providing
connectivity to the home network. It might be configured and connectivity to the home network. It might be configured and
managed by the end user. In this document, the CPE might also managed by the end user. In this document, the CPE might also
host services such as DHCPv6. This device might be provided by host services such as DHCPv6. This device might be provided by
the ISP. the ISP. A home network may have multiple CPE, and each of
them may be connected to an Internet Service Provider. In this
document, the CPE represents the set of functions involved in
the naming architecture. These functions may be collocated on
a single device, or distributed between multiple devices. How
these functions communicate is out of the scope of this
document and is left for implementation. See Section 2.1 for
more details.
- Registered Homenet Domain: is the Domain Name associated to the - Registered Homenet Domain: is the Domain Name associated to the
home network. home network.
- Homenet Zone: is the DNS zone associated with the home network. - Homenet Zone: is the DNS zone associated with the home network.
It is designated by its Registered Homenet Domain. This zone It is designated by its Registered Homenet Domain. This zone
is built by the CPE and contains the bindings between names and is built by the CPE and contains the bindings between names and
IP addresses of the nodes in the home network. The CPE IP addresses of the nodes in the home network. The CPE
synchronizes the Homenet Zone with the Synchronization Server synchronizes the Homenet Zone with the Synchronization Server
via a hidden primary / secondary architecture. The Outsourcing via a hidden primary / secondary architecture. The Outsourcing
skipping to change at page 11, line 50 skipping to change at page 12, line 50
instead of the use of DNS UPDATE. This section details the primary / instead of the use of DNS UPDATE. This section details the primary /
secondary mechanism. secondary mechanism.
5.1. Synchronization with a Hidden Primary 5.1. Synchronization with a Hidden Primary
Uploading and dynamically updating the zone file on the Uploading and dynamically updating the zone file on the
Synchronization Server can be seen as zone provisioning between the Synchronization Server can be seen as zone provisioning between the
CPE (Hidden Primary) and the Synchronization Server (Secondary CPE (Hidden Primary) and the Synchronization Server (Secondary
Server). This can be handled either in band or out of band. Server). This can be handled either in band or out of band.
Note that there is no standard way to distribute a DNS primary
between multiple devices. As a result, if multiple CPEs are
candidate for hosting the Hidden Primary, some specific mechanisms
should be designed so the home network only selects a single CPE for
the Hidden Primary. Selection mechanisms based on HNCP are good
candidates [XXX].
The Synchronization Server is configured as a secondary for the The Synchronization Server is configured as a secondary for the
Homenet Domain Name. This secondary configuration has been Homenet Domain Name. This secondary configuration has been
previously agreed between the end user and the provider of the previously agreed between the end user and the provider of the
Synchronization Server. In order to set the primary / secondary Synchronization Server. In order to set the primary / secondary
architecture, the CPE acts as a Hidden Primary Server, which is a architecture, the CPE acts as a Hidden Primary Server, which is a
regular authoritative DNS Server listening on the WAN interface. regular authoritative DNS Server listening on the WAN interface.
The Hidden Primary Server SHOULD accept SOA [RFC1033], AXFR The Hidden Primary Server SHOULD accept SOA [RFC1033], AXFR
[RFC1034], and IXFR [RFC1995] queries from its configured secondary [RFC1034], and IXFR [RFC1995] queries from its configured secondary
DNS server(s). The Hidden Primary Server SHOULD send NOTIFY messages DNS server(s). The Hidden Primary Server SHOULD send NOTIFY messages
skipping to change at page 18, line 51 skipping to change at page 20, line 12
Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone, Zone, local-scope addresses SHOULD NOT be part of the Homenet Zone,
and when possible, the CPE SHOULD sign the Homenet Zone. and when possible, the CPE SHOULD sign the Homenet Zone.
The Homenet Zone is expected to host public information only. It is The Homenet Zone is expected to host public information only. It is
not the scope of the DNS service to define local home network not the scope of the DNS service to define local home network
boundaries. Instead, local scope information is expected to be boundaries. Instead, local scope information is expected to be
provided to the home network using local scope naming services. mDNS provided to the home network using local scope naming services. mDNS
[RFC6762] DNS-SD [RFC6763] are two examples of these services. [RFC6762] DNS-SD [RFC6763] are two examples of these services.
Currently mDNS is limited to a single link network. However, future Currently mDNS is limited to a single link network. However, future
protocols are expected to leverage this constraint as pointed out in protocols are expected to leverage this constraint as pointed out in
[I-D.ietf-dnssd-requirements]. [RFC7558].
8. Homenet Reverse Zone 8. Homenet Reverse Zone
This section is focused on the Homenet Reverse Zone. This section is focused on the Homenet Reverse Zone.
Firstly, all considerations for the Homenet Zone apply to the Homenet Firstly, all considerations for the Homenet Zone apply to the Homenet
Reverse Zone. The main difference between the Homenet Reverse Zone Reverse Zone. The main difference between the Homenet Reverse Zone
and the Homenet Zone is that the parent zone of the Homenet Reverse and the Homenet Zone is that the parent zone of the Homenet Reverse
Zone is most likely managed by the ISP. As the ISP also provides the Zone is most likely managed by the ISP. As the ISP also provides the
IP prefix to the CPE, it may be able to authenticate the CPE using IP prefix to the CPE, it may be able to authenticate the CPE using
skipping to change at page 27, line 34 skipping to change at page 28, line 46
Abrahamson, Michael Richardson and Ray Bellis for their feedback on Abrahamson, Michael Richardson and Ray Bellis for their feedback on
handling different views as well as clarifying the impact of handling different views as well as clarifying the impact of
outsourcing the zone signing operation outside the CPE; Mark Andrew outsourcing the zone signing operation outside the CPE; Mark Andrew
and Peter Koch for clarifying the renumbering. and Peter Koch for clarifying the renumbering.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996. DOI 10.17487/RFC1995, August 1996,
<http://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://www.rfc-editor.org/info/rfc1996>.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
FUNCTIONS", RFC 2142, May 1997. Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<http://www.rfc-editor.org/info/rfc2142>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000. (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<http://www.rfc-editor.org/info/rfc2845>.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000,
<http://www.rfc-editor.org/info/rfc2930>.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
SIG(0)s )", RFC 2931, September 2000. ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <http://www.rfc-editor.org/info/rfc2931>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<http://www.rfc-editor.org/info/rfc4555>.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
4960, September 2007. RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, June 2010. (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in
DHCPv6 Reconfigure Messages", RFC 6644, July 2012. DHCPv6 Reconfigure Messages", RFC 6644, DOI 10.17487/
RFC6644, July 2012,
<http://www.rfc-editor.org/info/rfc6644>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, October 2014. (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
14.2. Informational References 14.2. Informational References
[I-D.howard-dnsop-ip6rdns] [I-D.howard-dnsop-ip6rdns]
Howard, L., "Reverse DNS in IPv6 for Internet Service Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", draft-howard-dnsop-ip6rdns-00 (work in Providers", draft-howard-dnsop-ip6rdns-00 (work in
progress), June 2014. progress), June 2014.
[I-D.ietf-dnssd-requirements]
Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
"Requirements for Scalable DNS-SD/mDNS Extensions", draft-
ietf-dnssd-requirements-06 (work in progress), March 2015.
[I-D.ietf-homenet-naming-architecture-dhc-options] [I-D.ietf-homenet-naming-architecture-dhc-options]
Migault, D., Cloetens, W., Griffiths, C., and R. Weber, Migault, D., Cloetens, W., Griffiths, C., and R. Weber,
"DHCP Options for Homenet Naming Architecture", draft- "DHCP Options for Homenet Naming Architecture", draft-
ietf-homenet-naming-architecture-dhc-options-02 (work in ietf-homenet-naming-architecture-dhc-options-02 (work in
progress), May 2015. progress), May 2015.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-07 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in
progress), April 2015. progress), August 2015.
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC
1033, November 1987. 1033, DOI 10.17487/RFC1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. DOI 10.17487/RFC4192, September 2005,
<http://www.rfc-editor.org/info/rfc4192>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
September 2013. DOI 10.17487/RFC7010, September 2013,
<http://www.rfc-editor.org/info/rfc7010>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, September DNSSEC Delegation Trust Maintenance", RFC 7344, DOI
2014. 10.17487/RFC7344, September 2014,
<http://www.rfc-editor.org/info/rfc7344>.
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
"IPv6 Home Networking Architecture Principles", RFC 7368, Weil, "IPv6 Home Networking Architecture Principles", RFC
October 2014. 7368, DOI 10.17487/RFC7368, October 2014,
<http://www.rfc-editor.org/info/rfc7368>.
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
"Requirements for Scalable DNS-Based Service Discovery
(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI
10.17487/RFC7558, July 2015,
<http://www.rfc-editor.org/info/rfc7558>.
Appendix A. Document Change Log Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-08
- 1: Clarification of the meaning of CPE. The architecture does not
consider a single CPE. The CPE represents multiple functions.
-07: -07:
Ray Hunter is added as a co-author. - 1: Ray Hunter is added as a co-author.
-06: -06:
Ray Hunter is added in acknowledgment. - 2: Ray Hunter is added in acknowledgment.
Adding Renumbering section with comments from Dallas meeting - 3: Adding Renumbering section with comments from Dallas meeting
Replacing Master / Primary - Slave / Secondary - 4: Replacing Master / Primary - Slave / Secondary
Security Consideration has been updated with Reflection attacks, Security Consideration has been updated with Reflection
flooding attacks, and replay attacks. attacks, flooding attacks, and replay attacks.
-05: -05:
*Clarifying on handling different views: *Clarifying on handling different views:
- 1: How the CPE may be involved in the resolution and responds - 1: How the CPE may be involved in the resolution and responds
without necessarily requesting the Public Authoritative without necessarily requesting the Public Authoritative
Server(s) (and eventually the Hidden Primary) Server(s) (and eventually the Hidden Primary)
- 2: How to handle local scope resolution that is link-local, site- - 2: How to handle local scope resolution that is link-local, site-
 End of changes. 51 change blocks. 
98 lines changed or deleted 179 lines changed or added

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