draft-ietf-homenet-dot-10.txt   draft-ietf-homenet-dot-11.txt 
Network Working Group P. Pfister Network Working Group P. Pfister
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: RFC7788 (if approved) T. Lemon Updates: RFC7788 (if approved) T. Lemon
Intended status: Standards Track Nominum, Inc. Intended status: Standards Track Nominum, Inc.
Expires: January 29, 2018 July 28, 2017 Expires: February 9, 2018 August 8, 2017
Special Use Domain 'home.arpa.' Special Use Domain 'home.arpa.'
draft-ietf-homenet-dot-10 draft-ietf-homenet-dot-11
Abstract Abstract
This document specifies the behavior that is expected from the Domain This document specifies the behavior that is expected from the Domain
Name System with regard to DNS queries for names ending with Name System with regard to DNS queries for names ending with
'.home.arpa.', and designates this domain as a special-use domain '.home.arpa.', and designates this domain as a special-use domain
name. 'home.arpa.' is designated for non-unique use in residential name. 'home.arpa.' is designated for non-unique use in residential
home networks. Home Networking Control Protocol (HNCP) is updated to home networks. Home Networking Control Protocol (HNCP) is updated to
use the 'home.arpa.' domain instead of '.home'. use the 'home.arpa.' domain instead of '.home'.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 29, 2018. This Internet-Draft will expire on February 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3
4. Domain Name Reservation Considerations . . . . . . . . . . . 3 4. Domain Name Reservation Considerations . . . . . . . . . . . 3
5. Updates to Home Networking Control Protocol . . . . . . . . . 5 5. Updates to Home Networking Control Protocol . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Users and devices within a home network (hereafter "homenet") require Users and devices within a home network (hereafter "homenet") require
devices and services to be identified by names that are unique within devices and services to be identified by names that are unique within
the boundaries of the homenet [RFC7368]. The naming mechanism needs the boundaries of the homenet [RFC7368]. The naming mechanism needs
to function without configuration from the user. While it may be to function without configuration from the user. While it may be
possible for a name to be delegated by an ISP, homenets must also possible for a name to be delegated by an ISP, homenets must also
function in the absence of such a delegation. A default name with a function in the absence of such a delegation. A default name with a
scope limited to each individual homenet needs to be used. scope limited to each individual homenet needs to be used.
This document corrects an error in [RFC7788], replacing '.home' with This document corrects an error in [RFC7788], replacing '.home' with
'home.arpa.' as the default domain-name for homenets. '.home' had 'home.arpa.' as the default domain-name for homenets. '.home' had
been selected as the most user-friendly option. However, there are been selected as the most user-friendly option. However, there are
existing uses of '.home' that may be in conflict with this use: existing uses of '.home' that may be in conflict with this use:
evidence indicates that '.home' queries frequently leak out and reach evidence indicates that '.home' queries frequently leak out and reach
the root name servers [ICANN1] [ICANN2]. the root name servers [ICANN1] [ICANN2].
In addition, it's necessary, for compatibility with DNSSEC In addition, it's necessary, for compatibility with DNSSEC
(Section 6), that an unsigned delegation be present for the name. (Section 6), that an insecure delegation ([RFC4035] section 4.3) be
There is an existing process for allocating names under '.arpa' present for the name. There is an existing process for allocating
[RFC3172]. No such process is available for requesting a similar names under '.arpa' [RFC3172]. No such process is available for
delegation in the root at the request of the IETF, which does not requesting a similar delegation in the root at the request of the
administer that zone. As a result, the use of '.home' is deprecated. IETF, which does not administer that zone. As a result, the use of
'.home' is deprecated.
This document registers the domain '.home.arpa.' as a special-use This document registers the domain '.home.arpa.' as a special-use
domain name [RFC6761] and specifies the behavior that is expected domain name [RFC6761] and specifies the behavior that is expected
from the Domain Name System with regard to DNS queries for names from the Domain Name System with regard to DNS queries for names
whose rightmost non-terminal labels are 'home.arpa.'. Queries for whose rightmost non-terminal labels are 'home.arpa.'. Queries for
names ending with '.home.arpa.' are of local significance within the names ending with '.home.arpa.' are of local significance within the
scope of a homenet, meaning that identical queries will result in scope of a homenet, meaning that identical queries will result in
different results from one homenet to another. In other words, a different results from one homenet to another. In other words, a
name ending in 'home.arpa.' is not globally unique. name ending in 'home.arpa.' is not globally unique.
skipping to change at page 6, line 27 skipping to change at page 6, line 29
([RFC4034] Section 5). Since the zone is not globally unique, no one ([RFC4034] Section 5). Since the zone is not globally unique, no one
key would work. key would work.
An alternative would be to install a authenticated denial of An alternative would be to install a authenticated denial of
existence ([RFC4033] Section 3.2). However, this assumes that existence ([RFC4033] Section 3.2). However, this assumes that
validation is being done on a caching resolver that is aware of the validation is being done on a caching resolver that is aware of the
special local meaning of 'home.arpa.'. If a host stub resolver special local meaning of 'home.arpa.'. If a host stub resolver
attempts to validate a name in 'home.arpa.', an authenticated denial attempts to validate a name in 'home.arpa.', an authenticated denial
of existence of 'home' as a subdomain of 'arpa.' would cause the of existence of 'home' as a subdomain of 'arpa.' would cause the
validation to fail. Therefore, the only delegation that will allow validation to fail. Therefore, the only delegation that will allow
names under 'home.arpa.' to be resolved is an unsigned delegation. names under 'home.arpa.' to be resolved is an insecure delegation, as
in [RFC6303] section 7.
Consequently, unless a trust anchor for the particular instance of Consequently, unless a trust anchor for the particular instance of
the 'home.arpa.' zone being validated is manually configured on the the 'home.arpa.' zone being validated is manually configured on the
validating resolver, DNSSEC signing of names within the 'home.arpa.' validating resolver, DNSSEC signing of names within the 'home.arpa.'
zone is not possible. zone is not possible.
Although in principle it might be useful to install a trust anchor Although in principle it might be useful to install a trust anchor
for a particular instance of 'home.arpa.', it's reasonable to expect for a particular instance of 'home.arpa.', it's reasonable to expect
that a host with such a trust anchor might from time to time connect that a host with such a trust anchor might from time to time connect
to more than one network with its own instance of 'home.arpa.'. Such to more than one network with its own instance of 'home.arpa.'. Such
skipping to change at page 7, line 9 skipping to change at page 7, line 9
'home.arpa.' that could be used to identify which trust anchor to 'home.arpa.' that could be used to identify which trust anchor to
rely on for validating names in that particular instance. However, rely on for validating names in that particular instance. However,
the security implications of this are complicated, and such a the security implications of this are complicated, and such a
mechanism, as well as a discussion of those implications, is out of mechanism, as well as a discussion of those implications, is out of
scope for this document. scope for this document.
7. Delegation of 'home.arpa.' 7. Delegation of 'home.arpa.'
In order to be fully functional, there must be a delegation of In order to be fully functional, there must be a delegation of
'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST
NOT be signed, MUST NOT include a DS record, and MUST point to one or NOT include a DS record, and MUST point to one or more black hole
more black hole servers, for example 'blackhole-1.iana.org.' and servers, for example 'blackhole-1.iana.org.' and 'blackhole-
'blackhole-2.iana.org.'. The reason that this delegation must not be 2.iana.org.'. The reason that this delegation must not be signed is
signed is that not signing the delegation breaks the DNSSEC chain of that not signing the delegation breaks the DNSSEC chain of trust,
trust, which prevents a validating stub resolver from rejecting names which prevents a validating stub resolver from rejecting names
published under 'home.arpa.' on a homenet name server. published under 'home.arpa.' on a homenet name server.
8. IANA Considerations 8. IANA Considerations
IANA is requested to record the domain name 'home.arpa.' in the IANA is requested to record the domain name 'home.arpa.' in the
Special-Use Domain Names registry [SUDN]. IANA is requested, with Special-Use Domain Names registry [SUDN]. IANA is requested, with
the approval of IAB, to implement the delegation requested in the approval of IAB, to implement the delegation requested in
Section 7. Section 7.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Stuart Cheshire for his prior work on The authors would like to thank Stuart Cheshire for his prior work on
'.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis.
We would also like to thank Paul Hoffman for providing review and We would also like to thank Paul Hoffman for providing review and
comments on the IANA considerations section, Andrew Sullivan for his comments on the IANA considerations section, Andrew Sullivan for his
review and proposed text, and Suzanne Woolf and Ray Bellis for their review and proposed text, and Suzanne Woolf and Ray Bellis for their
very detailed review comments and process insights. very detailed review comments and process insights. Thanks to Mark
Andrews for providing an exhaustive reference list on the topic of
insecure delegations.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <http://www.rfc-editor.org/info/rfc3172>. September 2001, <http://www.rfc-editor.org/info/rfc3172>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011, RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>. <http://www.rfc-editor.org/info/rfc6303>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013, RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>. <http://www.rfc-editor.org/info/rfc6761>.
[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, <http://www.rfc-editor.org/info/rfc8174>. May 2017, <http://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[ICANN1] "New gTLD Collision Risk Mitigation", October 2013,
<https://www.icann.org/en/system/files/files/new-gtld-
collision-mitigation-05aug13-en.pdf>.
[ICANN2] "New gTLD Collision Occurence Management", October 2013,
<https://www.icann.org/en/system/files/files/resolutions-
new-gtld-annex-1-07oct13-en.pdf>.
[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, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 8, line 34 skipping to change at page 8, line 50
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles", Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014, RFC 7368, DOI 10.17487/RFC7368, October 2014,
<http://www.rfc-editor.org/info/rfc7368>. <http://www.rfc-editor.org/info/rfc7368>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>. 2016, <http://www.rfc-editor.org/info/rfc7788>.
[ICANN1] "New gTLD Collision Risk Mitigation", October 2013,
<https://www.icann.org/en/system/files/files/new-gtld-
collision-mitigation-05aug13-en.pdf>.
[ICANN2] "New gTLD Collision Occurence Management", October 2013,
<https://www.icann.org/en/system/files/files/resolutions-
new-gtld-annex-1-07oct13-en.pdf>.
[SUDN] "Special-Use Domain Names Registry", July 2012, [SUDN] "Special-Use Domain Names Registry", July 2012,
<http://www.iana.org/assignments/special-use-domain-names/ <http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>. special-use-domain-names.xhtml>.
Authors' Addresses Authors' Addresses
Pierre Pfister Pierre Pfister
Cisco Systems Cisco Systems
Paris Paris
France France
Email: pierre.pfister@darou.fr Email: pierre.pfister@darou.fr
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
800 Bridge Parkway 800 Bridge Parkway
 End of changes. 12 change blocks. 
24 lines changed or deleted 34 lines changed or added

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