draft-ietf-dnssd-srp-09.txt   draft-ietf-dnssd-srp-10.txt 
Internet Engineering Task Force T. Lemon Internet Engineering Task Force T. Lemon
Internet-Draft S. Cheshire Internet-Draft S. Cheshire
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: 15 July 2021 11 January 2021 Expires: 13 January 2022 12 July 2021
Service Registration Protocol for DNS-Based Service Discovery Service Registration Protocol for DNS-Based Service Discovery
draft-ietf-dnssd-srp-09 draft-ietf-dnssd-srp-10
Abstract Abstract
The Service Registration Protocol for DNS-Based Service Discovery The Service Registration Protocol for DNS-Based Service Discovery
uses the standard DNS Update mechanism to enable DNS-Based Service uses the standard DNS Update mechanism to enable DNS-Based Service
Discovery using only unicast packets. This makes it possible to Discovery using only unicast packets. This makes it possible to
deploy DNS Service Discovery without multicast, which greatly deploy DNS Service Discovery without multicast, which greatly
improves scalability and improves performance on networks where improves scalability and improves performance on networks where
multicast service is not an optimal choice, particularly 802.11 multicast service is not an optimal choice, particularly 802.11
(Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 15 July 2021. This Internet-Draft will expire on 13 January 2022.
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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 6, line 39 skipping to change at page 6, line 39
that typically use Constrained-Node Networks may have very limited that typically use Constrained-Node Networks may have very limited
battery power. The series of DNS lookups required to discover an SRP battery power. The series of DNS lookups required to discover an SRP
server and then communicate with it will increase the power required server and then communicate with it will increase the power required
to advertise a service; for low-power devices, the additional to advertise a service; for low-power devices, the additional
flexibility this provides does not justify the additional use of flexibility this provides does not justify the additional use of
power. It is also fairly typical of such networks that some network power. It is also fairly typical of such networks that some network
service information is obtained as part of the process of joining the service information is obtained as part of the process of joining the
network, and so this can be relied upon to provide nodes with the network, and so this can be relied upon to provide nodes with the
information they need. information they need.
Networks that are not constrained networks can more complicated Networks that are not constrained networks can have more complicated
topologies at the Internet layer. Nodes connected to such networks topologies at the Internet layer. Nodes connected to such networks
can be assumed to be able to do DNSSD service registration domain can be assumed to be able to do DNSSD service registration domain
discovery. Such networks are generally able to provide registration discovery. Such networks are generally able to provide registration
domain discovery and routing. By requiring the use of TCP, the domain discovery and routing. By requiring the use of TCP, the
possibility of off-network spoofing is eliminated. possibility of off-network spoofing is eliminated.
2.2. Protocol Details 2.2. Protocol Details
We will discuss several parts to this process: how to know what to We will discuss several parts to this process: how to know what to
publish, how to know where to publish it (under what name), how to publish, how to know where to publish it (under what name), how to
skipping to change at page 14, line 38 skipping to change at page 14, line 38
sign the message, sign the message,
* there is a Service Instance Name Instruction in the SRP update for * there is a Service Instance Name Instruction in the SRP update for
which the SRV RR that is added points to the hostname being which the SRV RR that is added points to the hostname being
updated by this update. updated by this update.
* Host Description updates do not modify any other records. * Host Description updates do not modify any other records.
2.3.2. Valid SRP Update Requirements 2.3.2. Valid SRP Update Requirements
An SRP Update MUST include zero or more Service Discovery An SRP Update MUST include zero or more Service Discovery
instructions. For each Service Discovery instruction, there MUST be instructions. For each Service Discovery instruction, there MUST be
at least one Service Description instruction. For each Service at least one Service Description instruction. Note that in the case
Description instruction there MUST be at least one Service Discovery of SRP subtypes Section 7.1 of [RFC6763], it's quite possible that
instruction with its service instance name as the target of its PTR two Service Discovery instructions might reference the same Service
record. There MUST be exactly one Host Description Instruction. Description instruction. For each Service Description instruction
Every Service Description instruction must have that Host Description there MUST be at least one Service Discovery instruction with its
instruction as the target of its SRV record. A DNS Update that does service instance name as the target of its PTR record. There MUST be
not meet these constraints is not an SRP update. exactly one Host Description Instruction. Every Service Description
instruction must have that Host Description instruction as the target
of its SRV record. A DNS Update that does not meet these constraints
is not an SRP update.
A DNS Update that contains any additional adds or deletes that cannot A DNS Update that contains any additional adds or deletes that cannot
be identified as Service Discovery, Service Description or Host be identified as Service Discovery, Service Description or Host
Description instructions is not an SRP update. A DNS update that Description instructions is not an SRP update. A DNS update that
contains any prerequisites is not an SRP update. Such messages contains any prerequisites is not an SRP update. Such messages
should either be processed as regular RFC2136 updates, including should either be processed as regular RFC2136 updates, including
access control checks and constraint checks, if supported, or else access control checks and constraint checks, if supported, or else
rejected with RCODE=REFUSED. rejected with RCODE=REFUSED.
In addition, in order for an update to be a valid SRP update, the In addition, in order for an update to be a valid SRP update, the
skipping to change at page 24, line 46 skipping to change at page 24, line 46
doing a nice developmental edit, Tim Wattenberg for doing a SRP doing a nice developmental edit, Tim Wattenberg for doing a SRP
client proof-of-concept implementation at the Montreal Hackathon at client proof-of-concept implementation at the Montreal Hackathon at
IETF 102, and Tom Pusateri for reviewing during the hackathon and IETF 102, and Tom Pusateri for reviewing during the hackathon and
afterwards. afterwards.
12. Normative References 12. Normative References
[I-D.sekar-dns-ul] [I-D.sekar-dns-ul]
Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases", Cheshire, S. and T. Lemon, "Dynamic DNS Update Leases",
Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2 Work in Progress, Internet-Draft, draft-sekar-dns-ul-02, 2
August 2018, August 2018, <https://datatracker.ietf.org/doc/html/draft-
<https://tools.ietf.org/html/draft-sekar-dns-ul-02>. sekar-dns-ul-02>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>. <https://www.rfc-editor.org/info/rfc2132>.
[RFC2136] Vixie, P., Ed., 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, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
skipping to change at page 27, line 18 skipping to change at page 27, line 18
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>.
[RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
2020, <https://www.rfc-editor.org/info/rfc8766>. 2020, <https://www.rfc-editor.org/info/rfc8766>.
[I-D.cheshire-dnssd-roadmap] [I-D.cheshire-dnssd-roadmap]
Cheshire, S., "Service Discovery Road Map", Work in Cheshire, S., "Service Discovery Road Map", Work in
Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03,
23 October 2018, <https://tools.ietf.org/html/draft- 23 October 2018, <https://datatracker.ietf.org/doc/html/
cheshire-dnssd-roadmap-03>. draft-cheshire-dnssd-roadmap-03>.
[I-D.cheshire-edns0-owner-option] [I-D.cheshire-edns0-owner-option]
Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", Work
in Progress, Internet-Draft, draft-cheshire-edns0-owner- in Progress, Internet-Draft, draft-cheshire-edns0-owner-
option-01, 3 July 2017, <https://tools.ietf.org/html/ option-01, 3 July 2017,
draft-cheshire-edns0-owner-option-01>. <https://datatracker.ietf.org/doc/html/draft-cheshire-
edns0-owner-option-01>.
[I-D.sctl-advertising-proxy] [I-D.sctl-advertising-proxy]
Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD
Service Registration Protocol", Work in Progress, Service Registration Protocol", Work in Progress,
Internet-Draft, draft-sctl-advertising-proxy-00, 13 July Internet-Draft, draft-sctl-advertising-proxy-01, 22
2020, <https://tools.ietf.org/html/draft-sctl-advertising- February 2021, <https://datatracker.ietf.org/doc/html/
proxy-00>. draft-sctl-advertising-proxy-01>.
[ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration [ZC] Cheshire, S. and D.H. Steinberg, "Zero Configuration
Networking: The Definitive Guide", O'Reilly Media, Inc. , Networking: The Definitive Guide", O'Reilly Media, Inc. ,
ISBN 0-596-10100-7, December 2005. ISBN 0-596-10100-7, December 2005.
Appendix A. Testing using standard RFC2136-compliant servers Appendix A. Testing using standard RFC2136-compliant servers
It may be useful to set up a DNS server for testing that does not It may be useful to set up a DNS server for testing that does not
implement SRP. This can be done by configuring the server to listen implement SRP. This can be done by configuring the server to listen
on the anycast address, or advertising it in the on the anycast address, or advertising it in the
 End of changes. 9 change blocks. 
20 lines changed or deleted 24 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/