draft-cheshire-dnssd-roadmap-01.txt   draft-cheshire-dnssd-roadmap-02.txt 
Internet Engineering Task Force S. Cheshire Internet Engineering Task Force S. Cheshire
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational March 18, 2018 Intended status: Informational October 22, 2018
Expires: September 19, 2018 Expires: April 25, 2019
Service Discovery Road Map Service Discovery Road Map
draft-cheshire-dnssd-roadmap-01 draft-cheshire-dnssd-roadmap-02
Abstract Abstract
Over the course of several years, a rich collection of technologies Over the course of several years, a rich collection of technologies
has developed around DNS-Based Service Discovery, described across has developed around DNS-Based Service Discovery, described across
multiple documents. This "Road Map" document gives an overview of multiple documents. This "Road Map" document gives an overview of
how these related but separate technologies (and their documents) fit how these related but separate technologies (and their documents) fit
together, to facilitate service discovery in various environments. together, to facilitate service discovery in various environments.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 September 19, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 33 skipping to change at page 2, line 33
guidance about which components to use depending on the problem being guidance about which components to use depending on the problem being
solved. solved.
2. Namespace of Service Types 2. Namespace of Service Types
The single most important concept in service discovery is the The single most important concept in service discovery is the
namespace specifying how different service types are identified. namespace specifying how different service types are identified.
This is how a client communicates what it needs, and how a server This is how a client communicates what it needs, and how a server
communicates what it offers. For a client to discover a server, the communicates what it offers. For a client to discover a server, the
client and server need to have a common language to describe what client and server need to have a common language to describe what
they need and what they offer. The need to use the same namespace of they need and what they offer. They need to use the same namespace
service types, otherwise they may actually speak the same application of service types, otherwise they may actually speak the same
protocol over the air or on the wire, and may in fact be completely application protocol over the air or on the wire, and may in fact be
compatible, and yet may be unable to detect this because they are completely compatible, and yet may be unable to detect this because
using different names to refer to the same actual service. Hence, they are using different names to refer to the same actual service.
having a consistent namespace of service types is the essential Hence, having a consistent namespace of service types is the
prerequisite for any useful service discovery. essential prerequisite for any useful service discovery.
IANA manages the registry of Service Types [RFC6335][STR]. This IANA manages the registry of Service Types [RFC6335][STR]. This
registry of Service Types can (and should) be used in any service registry of Service Types can (and should) be used in any service
discovery protocol as the vocabulary for describing *all* IP-based discovery protocol as the vocabulary for describing *all* IP-based
services, not only DNS-Based Service Discovery [RFC6763]. services, not only DNS-Based Service Discovery [RFC6763].
In this document we focus on the use of the IANA Service Type In this document we focus on the use of the IANA Service Type
Registry [STR] in conjunction with DNS-Based Service Discovery, Registry [STR] in conjunction with DNS-Based Service Discovery,
though that should not be taken in any way to imply any criticism of though that should not be taken in any way to imply any criticism of
other service discovery protocols sharing the same namespace of other service discovery protocols sharing the same namespace of
service types. In different circumstances different Service service types. In different circumstances different Service
Discovery protocols are appropriate. Discovery protocols are appropriate.
For example, for service discovery of services potentially available For example, for service discovery of services potentially available
via a Wi-Fi access point, prior to association with that Wi-Fi access via a Wi-Fi access point, prior to association with that Wi-Fi access
point, when no IP link has yet been established, a service discovery point, when no IP communication has yet been established, a service
protocol may use raw 802.11 frames, not necessarily IP, UDP, or DNS- discovery protocol may use raw 802.11 frames, not necessarily IP,
formatted messages. For Service Discovery using peer-to-peer Wi-Fi UDP, or DNS-formatted messages. For Service Discovery using peer-to-
technologies, without any Wi-Fi access point at all, it may also be peer Wi-Fi technologies, without any Wi-Fi access point at all, it
preferable to use raw 802.11 frames instead of IP, UDP, or DNS- may also be preferable to use raw 802.11 frames instead of IP, UDP,
formatted messages. Service Discovery using IEEE 802.15.4 radios may or DNS-formatted messages. Service Discovery using IEEE 802.15.4
use yet another over-the-air protocol. What is important is that radios may use yet another over-the-air protocol. What is important
they all share the same vocabulary to describe all IP-based services. is that they all share the same vocabulary to describe all IP-based
Using the same service type vocabulary means that client and server services. Using the same service type vocabulary means that client
software, using agnostic APIs to consume and offer services on the and server software, using agnostic APIs to consume and offer
network, has a common language to identify those services, services on the network, has a common language to identify those
independent of the medium or the particular service discovery services, independent of the medium or the particular service
protocol in use on that medium. Just as TCP/IP runs on many discovery protocol in use on that medium. Just as TCP/IP runs on
different link layers, and the concept of using an IP address to many different link layers, and the concept of using an IP address to
identify a particular peer is consistent across many different link identify a particular peer is consistent across many different link
layers, the concept of using a name from the IANA Service Type layers, the concept of using a name from the IANA Service Type
Registry to identify a particular service type also needs to be Registry to identify a particular service type also needs to be
consistent across all IP-supporting link layers. consistent across all IP-supporting link layers.
Originally, the IANA Service Type Registry [RFC6335][STR] used the Originally, the IANA Service Type Registry [RFC6335][STR] used the
term "Service Name" rather than "Service Type". Later it became term "Service Name" rather than "Service Type". Later it became
clear that this term could be ambiguous. For a given service clear that this term could be ambiguous. For a given service
instance on the network, there is the machine-visible name of the instance on the network, there is the machine-visible name of the
type of service it provides, and the human-visible name of the type of service it provides, and the human-visible name of the
particular instance of that type of service. For clarity, this particular instance of that type of service. For clarity, this
document and related specifications use the term "Service Type" to document and related specifications use the term "Service Type" to
denote the machine-visible name of the type of service, and the term denote the machine-visible name of the type of service, and the term
"Instance Name" to denote the human-visible name of a particular "Instance Name" to denote the human-visible name of a particular
instance. instance.
3. Service Discovery Operational Model 3. Service Discovery Operational Model
The original DNS-Based Service Discovery specifications [RFC6763] The original DNS-Based Service Discovery specification [RFC6763] used
used the terms "register" (advertise a service), "browse" (discover the terms "register" (advertise a service), "browse" (discover
service instances), and "resolve" (get IP address and port for a service instances), and "resolve" (get IP address and port for a
specific service instance). This terminology is reflective of the specific service instance). This terminology is reflective of the
thinking at the time, which viewed service discovery as a new and thinking at the time, which viewed service discovery as a new and
separate step, added to existing networking code. For example, a separate step, added to existing networking code. For example, a
server would first open a listening socket as it always had, and then server would first open a listening socket as it always had, and then
"register" that listening socket with the service discovery engine. "register" that listening socket with the service discovery engine.
Similarly, a client would first "resolve" a service instance to an IP Similarly, a client would first "resolve" a service instance to an IP
address and port, and then, having done that, "connect" to that IP address and port, and then, having done that, "connect" to that IP
address and port. address and port.
skipping to change at page 4, line 47 skipping to change at page 4, line 47
service discovery mechanism. service discovery mechanism.
The second step, "Enumerate", is when a client device wishes to The second step, "Enumerate", is when a client device wishes to
perform some action, but does not yet know which particular service perform some action, but does not yet know which particular service
instance will be used to perform that action. For example, when a instance will be used to perform that action. For example, when a
user taps the "AirPrint" button on an iPhone or iPad, the iPhone or user taps the "AirPrint" button on an iPhone or iPad, the iPhone or
iPad knows that the user wishes to print, but not which particular iPad knows that the user wishes to print, but not which particular
printer to use. The desired *function* is known (IPP printing), but printer to use. The desired *function* is known (IPP printing), but
not the particular instance. In this case, the client device needs not the particular instance. In this case, the client device needs
to enumerate the list of available service instances that are able to to enumerate the list of available service instances that are able to
perform the desired task. In most cases this list of service perform the desired task. In some cases this list of service
instances is presented to a human user to choose from; in some cases instances is presented to a human user to choose from; in some cases
it is software that examines the list of available service instances it is software that examines the list of available service instances
and determines the best one to use. This second step is the and determines the best one to use. This second step is the
operation that was called "browsing" in the original specifications. operation that was called "browsing" in the original specifications.
The third step, "Use", is when particular service instance has been The third step, "Use", is when particular service instance has been
selected, and the client wants to make use of that service instance. selected, and the client wants to make use of that service instance.
This encompasses both the "resolve" step (finding IP address(es) and This encompasses both the "resolve" step (finding IP address(es) and
port(s) for the service instance) and the subsequent steps to port(s) for the service instance) and the subsequent steps to
establish communication with it, which may include details like establish communication with it, which may include details like
skipping to change at page 5, line 28 skipping to change at page 5, line 28
step more detailed information (e.g, target host IP address, port step more detailed information (e.g, target host IP address, port
number, etc.) is requested about one specific service instance. number, etc.) is requested about one specific service instance.
Requesting all the detailed information about all available service Requesting all the detailed information about all available service
instances would be inefficient and wasteful on the network. If the instances would be inefficient and wasteful on the network. If the
information about services on the network is imagined as a table, information about services on the network is imagined as a table,
then the second step is requesting just one column from that table then the second step is requesting just one column from that table
(the name column) and the third step is requesting just one row from (the name column) and the third step is requesting just one row from
that table (the information pertaining to just one named service that table (the information pertaining to just one named service
instance). instance).
To give an example, clicking the "+" button in the printer settings To give a concrete example, clicking the "+" button in the printer
on macOS is an operation performing the second step. It is settings on macOS is an operation performing the second step. It is
requesting the names of all available printers. Once a desired requesting the names of all available printers. Depending on the
printer has been chosen and configured, subsequent printing of specific use case, this step may be performed only rarely. For
documents is an operation performing the third step. It only needs example, a user may do this just one once, the first time they
to request information about the specific printer in question. It is configure their computer to use their preferred printer, and never
not necessary to repeatedly discover the list of every printer on the again.
network if the client device already knows which one it intends to
use. Once a desired printer has been chosen and configured, subsequent
printing of documents is an operation performing the third step.
This step may be done frequently, perhaps multiple times per day.
This third step is important because, in a world of DHCP, IPv6
Stateless Autoconfiguration, and similar dynamic address allocation
schemes, a printer's IP address could change from day to day, and to
use the printer, its current address must be known. However, this
third step need not be performed for every printer on the network,
just the specific printer that is about to be used. Also, it is not
necessary to repeat the second step again, learning the names of
every printer on the network, if the client device already knows the
name of the printer it intends to use.
DNS-Based Service Discovery [RFC6763] implements these three DNS-Based Service Discovery [RFC6763] implements these three
principal service discovery operations using DNS records and queries, principal service discovery operations using DNS records and queries,
either using Multicast DNS [RFC6762] (for queries limited to the either using Multicast DNS [RFC6762] (for queries limited to the
local link) or conventional unicast DNS [RFC1034] [RFC1035] (for local link) or conventional unicast DNS [RFC1034] [RFC1035] (for
queries beyond the local link). queries beyond the local link).
Other service discovery protocol achieve the same semantics using Other service discovery protocol achieve the same semantics using
different packet formats and mechanisms. different packet formats and mechanisms.
One incidental benefit of using DNS as the foundation layer for One incidental benefit of using DNS as the foundation layer for
service discovery, in cases where that makes sense, is that both service discovery, in cases where that makes sense, is that both
Multicast DNS and conventional unicast DNS are also used provide name Multicast DNS and conventional unicast DNS are also used provide name
resolution (mapping host names to IP addresses). There is some resolution (mapping host names to IP addresses). There is some
efficiency and code reuse gained by using the same underlying efficiency and code reuse gained by using the same underlying
protocol for both service discovery and naming. protocol for both service discovery and naming.
A final requirement is that the service discovery protocol perform A final requirement is that the service discovery protocol should not
discovery not only at a single moment in time, but also ongoing only perform discovery at a single moment in time, but should also
change notification (sometimes called "Publish & Subscribe"). provide ongoing change notification (sometimes called "Publish &
Without support for ongoing change notification, clients would be Subscribe"). Clients need to be notified in a timely fashion when
forced to resort to polling to keep data up to date, which is new data of interest appears, when data of interest changes, and,
inefficient and wasteful on the network. equally importantly, when data of interest goes away ("goodbye
packets"). Without support for ongoing change notification, clients
would be forced to resort to polling to keep data up to date, which
is inefficient and wasteful on the network.
Multicast DNS [RFC6762] implicitly includes change notification by Multicast DNS [RFC6762] implicitly includes change notification by
virtue of announcing record changes via IP Multicast, which allows virtue of announcing record creation, update, and deletion, via IP
these changes to be seen by all peers on the same link (i.e., same Multicast, which allows these changes to be seen by all peers on the
broadcast domain). same link (i.e., same broadcast domain).
Conventional unicast DNS [RFC1034] [RFC1035] has historically not had Conventional unicast DNS [RFC1034] [RFC1035] has historically not had
broad support for change notification. This capability is added via broad support for change notification. This capability is added via
the new mechanism for DNS Push Notifications [Push]. the new mechanism for DNS Push Notifications [Push].
When using DNS-Based Service Discovery [RFC6763] there are two When using DNS-Based Service Discovery [RFC6763] there are two
aspects to consider: firstly how the clients choose what DNS names to aspects to consider: firstly how the clients determine the
query, and what query mechanisms to use, and secondly how the appropriate DNS names to query (and what query mechanisms to use) and
relevant information got into the DNS namespace in the first place, secondly how the relevant information got into the DNS namespace in
so as to be available when clients query for it. the first place, so as to be available when clients query for it.
The available namespaces are discussed below in Section 4. Client The available namespaces are discussed broadly in Section 4 below.
operation is discussed in Section 5 and server operation is discussed Client operation is then discussed in detail in Section 5, and server
in Section 6. operation is discussed in detail in Section 6.
4. Service Discovery Namespace 4. Service Discovery Namespace
When used with Multicast DNS [RFC6762] queries are automatically When used with Multicast DNS [RFC6762] Service Discovery queries
performed in the ".local" parent domain. necessarily use the ".local" parent domain reserved for this purpose
[SUDN].
When used with conventional unicast DNS [RFC1034] [RFC1035] some When used with conventional unicast DNS [RFC1034] [RFC1035] some
other domain must be used. other domain must be used.
For individuals and organizations with a globally-unique domain name For individuals and organizations with a globally-unique domain name
registered to them, their globally-unique domain name, or a subdomain registered to them, their globally-unique domain name, or a subdomain
of it, can be used for service discovery. of it, can be used for service discovery.
However, it would be convenient for capable service discovery to be However, it would be convenient for advanced service discovery to be
available even to people who haven't taken the step of registering available even to people who haven't taken the step of registering
and paying for a globally-unique domain name. For these people it and paying annually for a globally-unique domain name. For these
would be useful if devices arrived preconfigured with some suitable people it would be useful if devices arrived preconfigured with some
factory-default service discovery domain, such as suitable factory-default service discovery domain, such as
"services.home.arpa" [I-D.ietf-homenet-dot]. Services published in "services.home.arpa" [RFC8375]. Services published in this factory-
this factory-default service discovery domain would not be globally default service discovery domain are not globally unique or globally
unique or globally resolvable, but they could have scope larger than resolvable, but they can have scope larger than the single link
the single link provided by Multicast DNS. provided by Multicast DNS.
5. Client Configuration and Operation 5. Client Configuration and Operation
When using DNS-Based Service Discovery [RFC6763], clients have to When using DNS-Based Service Discovery [RFC6763], clients have to
choose what DNS names to query. choose what DNS names to query.
When used with Multicast DNS [RFC6762] queries are automatically When used with Multicast DNS [RFC6762] on the local link, queries are
performed in the ".local" parent domain. necessarily performed in the ".local" parent domain reserved for this
purpose [SUDN].
For discovery beyond the local link, a unicast DNS domain must be For discovery beyond the local link, a unicast DNS domain must be
used. This unicast DNS domain can be configured manually by the used. This unicast DNS domain can be configured manually by the
user, or it can be learned dynamically from the network (as has been user, or it can be learned dynamically from the network (as has been
done for many years at IETF meetings to facilitate discovery of the done for many years at IETF meetings to facilitate discovery of the
IETF Terminal Room printer, from outside the IETF Terminal Room). In IETF Terminal Room printer, from outside the IETF Terminal Room). In
the DNS-SD specification [RFC6763] section 11, "Discovery of Browsing the DNS-SD specification [RFC6763] section 11, "Discovery of Browsing
and Registration Domains (Domain Enumeration)", describes how a and Registration Domains (Domain Enumeration)", describes how a
client device learns one or more recommended service discovery client device learns one or more recommended service discovery
domains from the network, using the special "lb._dns-sd._udp" query. domains from the network, using the special "lb._dns-sd._udp" query.
skipping to change at page 8, line 43 skipping to change at page 8, line 44
displayed on a screen for a user to see, it is desirable to keep that displayed on a screen for a user to see, it is desirable to keep that
list up to date without the user having to repeatedly tap a "refresh" list up to date without the user having to repeatedly tap a "refresh"
button, and without the software repeatedly polling the network on button, and without the software repeatedly polling the network on
the user's behalf. the user's behalf.
And early solution to provide asynchronous change notifications for And early solution to provide asynchronous change notifications for
unicast DNS was the UDP-based protocol DNS Long-Lived Queries unicast DNS was the UDP-based protocol DNS Long-Lived Queries
[DNS-LLQ]. This was used, among other things, by Apple's Back to My [DNS-LLQ]. This was used, among other things, by Apple's Back to My
Mac Service [RFC6281] introduced in Mac OS X 10.5 Leopard in 2007. Mac Service [RFC6281] introduced in Mac OS X 10.5 Leopard in 2007.
Recent experience has shown that an asynchronous change notification A decade of operational experience has shown that an asynchronous
protocol built on TCP would be preferable, so the IETF is now change notification protocol built on TCP is preferable for a variety
developing DNS Push Notifications [Push]. of reasons, so the IETF is has developed DNS Push Notifications
[Push].
Because DNS Push Notifications is built on top of a DNS TCP Because DNS Push Notifications is built on top of a DNS TCP
connection, DNS Push Notifications adopts the conventions specified connection, DNS Push Notifications adopts the conventions specified
by DNS Stateful Operations [DSO] rather than inventing its own by DNS Stateful Operations [DSO] rather than inventing its own
session management mechanisms. session management mechanisms.
6. Server Configuration and Operation 6. Server Configuration and Operation
Section 5 above describes how clients perform their queries. The Section 5 above describes how clients perform their queries. The
related question is how the relevant information got into the DNS related question is how the relevant information got into the DNS
namespace in the first place, so as to be available when clients namespace in the first place, so as to be available when clients
query for it. query for it.
One way that relevant service discovery information can get into the One trivial way that relevant service discovery information can get
DNS namespace is simply via manual configuration, creating the into the DNS namespace is simply via manual configuration, creating
necessary PTR, SRV and TXT records [RFC6763], and indeed this is how the necessary PTR, SRV and TXT records [RFC6763] by hand, and indeed
the IETF Terminal Room printer has been advertised to IETF meeting this is how the IETF Terminal Room printer has been advertised to
attendees for many years. While this is easy for the experienced IETF meeting attendees for many years. While this is easy for the
network operators at the IETF, it can be onerous to others less experienced network operators at the IETF, it can be onerous to
familiar with how to set up DNS-SD records. others less familiar with how to set up DNS-SD records.
Hence it would be convenient to automate this process of populating Hence it would be convenient to automate this process of populating
the DNS namespace with relevant service discovery information. Two the DNS namespace with relevant service discovery information. Two
efforts are underway to address this need, the Service Discovery efforts are underway to address this need, the Service Discovery
Proxy [DisProx] (see Section 6.1) and the Service Registration Proxy [DisProx] (see Section 6.1) and the Service Registration
Protocol [RegProt] (see Section 6.4). Protocol [RegProt] (see Section 6.4).
6.1. Service Discovery Proxy 6.1. Service Discovery Proxy
The first effort in the direction of automatically populating the DNS The first technique in the direction of automatically populating the
namespace is the Service Discovery Proxy [DisProx]. This technology DNS namespace is the Service Discovery Proxy [DisProx]. This
is designed to work with today's existing devices that advertise technology works with today's existing devices that advertise
services using Multicast DNS only (such as almost all network services using Multicast DNS only (such as almost all network
printers sold in the last decade). A Service Discovery Proxy is a printers sold in the last decade). A Service Discovery Proxy is a
device colocated on the same link as the devices we wish to be able device with a presence on the same link as the devices we wish to be
to discover from afar. A remote client sends unicast queries to the able to discover from afar. A remote client sends unicast queries to
Discovery Proxy, which performs local Multicast DNS queries on behalf the Discovery Proxy, which performs local Multicast DNS queries on
of the remote client, and then sends back the answers it discovers. behalf of the remote client, and then sends back the answers it
discovers.
Because the time it takes to receive Multicast DNS responses is Because the time it takes to receive Multicast DNS responses is
uncertain, this mechanism benefits from being able to deliver uncertain, this mechanism benefits from being able to deliver
asynchronous change notifications as new answers come in, using DNS asynchronous change notifications as new answers come in, using DNS
Long-Lived Queries [DNS-LLQ] or the newer DNS Push Notifications Long-Lived Queries [DNS-LLQ] or the newer DNS Push Notifications
[Push] on top of DNS Stateful Operations [DSO]. [Push] on top of DNS Stateful Operations [DSO].
6.2. Multicast DNS Discovery Relay 6.2. Multicast DNS Discovery Relay
As an alternative to having to be physically connected to the desired As an alternative to having to be physically connected to the desired
skipping to change at page 10, line 23 skipping to change at page 10, line 23
entire enterprise. This is modeled after the DHCP protocol. In entire enterprise. This is modeled after the DHCP protocol. In
simple residential scenarios the DHCP server resides in the home simple residential scenarios the DHCP server resides in the home
gateway, which is physically attached to the (single) local link. In gateway, which is physically attached to the (single) local link. In
complex enterprise networks, it is common to have a single complex enterprise networks, it is common to have a single
centralized DHCP server, which resides in the data center and centralized DHCP server, which resides in the data center and
communicates with a multitude of simple lightweight BOOTP relay communicates with a multitude of simple lightweight BOOTP relay
agents, implemented in the routers on each physical link. agents, implemented in the routers on each physical link.
6.3. Service Discovery Broker 6.3. Service Discovery Broker
Finally, when clients are making TCP connections to multiple Service Finally, when clients are communicating with multiple Service
Discovery Proxies at the same time, this can be burdensome for the Discovery Proxies at the same time, this can be burdensome for the
clients (which may be mobile and battery powered) and for the the clients (which may be mobile and battery powered) and for the Service
Service Discovery Proxies (which may have to serve hundreds of Discovery Proxies (which may have to serve hundreds of clients).
clients). This situation is remedied by use of a Service Discovery This situation is remedied by use of a Service Discovery Broker
Broker [Broker]. A Service Discovery Broker is an intermediary [Broker]. A Service Discovery Broker is an intermediary between
between client and server. A client can issue a single query to the client and server. A client can issue a single query to the Service
Service Discovery Broker and have the Service Discovery Broker do the Discovery Broker and have the Service Discovery Broker do the hard
hard work of issuing multiple queries on behalf of the client. And a work of issuing multiple queries on behalf of the client. And a
Service Discovery Broker can shield a Service Discovery Proxy from Service Discovery Broker can shield a Service Discovery Proxy from
excessive load by collapsing multiple duplicate queries from excessive load by collapsing multiple duplicate queries from
different client down to a single query to the Service Discovery different client down to a single query to the Service Discovery
Proxy. Proxy.
6.4. Service Registration Protocol 6.4. Service Registration Protocol
The second effort in the direction of automatically populating the The second technique in the direction of automatically populating the
DNS namespace is the Service Registration Protocol [RegProt]. This DNS namespace is the Service Registration Protocol [RegProt]. This
technology is designed to enable future devices that will explicitly technology is designed to enable future devices that will explicitly
cooperate with the network infrastructure to advertise their cooperate with the network infrastructure to advertise their
services. services.
The Service Registration Protocol is effectively DNS Update, with The Service Registration Protocol is effectively DNS Update, with
some minor additions. some minor additions.
One addition is the introduction of a lifetime on DNS Updates, using One addition to the basic DNS Update protocol is the introduction of
the the Dynamic DNS Update Lease EDNS(0) option [DNS-UL]. This a lifetime on DNS Updates, using the Dynamic DNS Update Lease EDNS(0)
option has similar semantics to a DHCP address lease, where a device option [DNS-UL]. This option has similar semantics to a DHCP address
is granted an address with with a certain lease lifetime, and if the lease, where a device is granted an address with with a certain DHCP
device fails to renew the lease before it expires then the address lease lifetime, and if the device fails to renew the DHCP lease
will be reclaimed and become available to be allocated to a different before it expires then the address will be reclaimed and become
device. In cases where DHCP is being used, a device will generally available to be allocated to a different device. In cases where DHCP
request a DNS Update Lease with the same expiration time as its DHCP is being used for address assignment, a device will generally request
address lease. This way, if the device is abruptly disconnected from a DNS Update Lease with the same expiration time as its DHCP address
the network, around the same time as its address gets reclaimed its lease. This way, if the device is abruptly disconnected from the
DNS records will also be garbage collected. network, around the same time as its address gets reclaimed its DNS
records will also be garbage collected.
The second addition is the introduction of information that tells the The second addition to the basic DNS Update protocol is the
Service Registration server that the device will be going to sleep to introduction of information, carried using the EDNS(0) OWNER Option
save power, combined with information specifying how to wake it up [Owner], that tells the Service Registration server that the device
again on demand, using the EDNS(0) OWNER Option [Owner]. will be going to sleep to save power, and how the Service
Registration server can wake it up again on demand when needed. The
use of power management information in the Service Registration
messages allows devices to sleep to save power, which is especially
beneficial for battery-powered devices in the home.
The use of an explicit Service Registration Protocol is beneficial in The use of an explicit Service Registration Protocol is beneficial in
networks where multicast is expensive, inefficient, or outright networks where multicast is expensive, inefficient, or outright
blocked, such as many Wi-Fi networks. An explicit Service blocked, such as many Wi-Fi networks. An explicit Service
Registration Protocol is also beneficial in networks where multicast Registration Protocol is also beneficial in networks where multicast
and broadcast are supported poorly, if at all, such as mesh networks and broadcast are supported poorly, if at all, such as some mesh
like those using IEEE 802.15.4. networks.
The use of power management information in the Service Registration
messages allows devices to sleep to save power, which is especially
beneficial for battery-powered devices in the home.
7. Security Considerations 7. Security Considerations
As an informational document, this document introduces no new As an informational document, this document introduces no new
Security Considerations of its own. The various referenced documents Security Considerations of its own. The various referenced documents
each describe their own relevant Security Considerations as each describe their own relevant Security Considerations as
appropriate. appropriate.
8. Informative References 8. Informative References
skipping to change at page 12, line 20 skipping to change at page 12, line 20
[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>.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", "Understanding Apple's Back to My Mac (BTMM) Service",
RFC 6281, DOI 10.17487/RFC6281, June 2011, RFC 6281, DOI 10.17487/RFC6281, June 2011,
<https://www.rfc-editor.org/info/rfc6281>. <https://www.rfc-editor.org/info/rfc6281>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
to Replace the AppleTalk Name Binding Protocol (NBP)", to Replace the AppleTalk Name Binding Protocol (NBP)",
RFC 6760, DOI 10.17487/RFC6760, February 2013, RFC 6760, DOI 10.17487/RFC6760, February 2013,
<https://www.rfc-editor.org/info/rfc6760>. <https://www.rfc-editor.org/info/rfc6760>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://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, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[I-D.ietf-homenet-dot] [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
Pfister, P. and T. Lemon, "Special Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
'home.arpa.'", draft-ietf-homenet-dot-14 (work in <https://www.rfc-editor.org/info/rfc8375>.
progress), September 2017.
[Broker] Cheshire, S. and T. Lemon, "Service Discovery Broker",
drdraft-sctl-discovery-broker-00 (work in progress), July
2017.
[DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-08 (work in Service Discovery", draft-ietf-dnssd-hybrid-08 (work in
progress), March 2018. progress), March 2018.
[Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", [DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
draft-ietf-dnssd-push-14 (work in progress), March 2018. llq-01 (work in progress), August 2006.
[DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns-
ul-01 (work in progress), August 2006.
[DSO] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [DSO] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
draft-ietf-dnsop-session-signal-07 (work in progress), draft-ietf-dnsop-session-signal-07 (work in progress),
March 2018. March 2018.
[DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns-
ul-01 (work in progress), August 2006.
[DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
llq-01 (work in progress), August 2006.
[Owner] Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- [Owner] Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft-
cheshire-edns0-owner-option-01 (work in progress), July cheshire-edns0-owner-option-01 (work in progress), July
2017. 2017.
[Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-14 (work in progress), March 2018.
[RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service- for DNS-Based Service Discovery", draft-sctl-service-
registration-00 (work in progress), July 2017. registration-00 (work in progress), July 2017.
[Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery [Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery
Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress), Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress),
March 2018. March 2018.
[Broker] Cheshire, S. and T. Lemon, "Service Discovery Broker",
drdraft-sctl-discovery-broker-00 (work in progress), July
2017.
[STR] "Service Name and Transport Protocol Port Number [STR] "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/ Registry", <http://www.iana.org/assignments/
service-names-port-numbers/>. service-names-port-numbers/>.
[SUDN] "Special-Use Domain Names Registry",
<https://www.iana.org/assignments/
special-use-domain-names/>.
[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration [ZC] Cheshire, S. and D. 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. IETF Terminal Room Printer Discovery Walk-through Appendix A. IETF Terminal Room Printer Discovery Walk-Through
For about a decade now, the capable IETF network staff have provided For about a decade now, the talented IETF network staff have provided
off-link DNS Service Discovery for the Terminal Room printer at IETF off-link DNS Service Discovery for the Terminal Room printer at IETF
meetings three times a year. In the case of the IETF meetings the meetings three times a year. In the case of the IETF meetings the
necessary DNS records are entered manually, whereas this document necessary DNS records are entered manually, whereas this document
advocates for increased automation of that task, but the process by advocates for increased automation of that task, but either way the
which clients query to discover services is the same either way. process by which clients query to discover services is the same.
This appendix gives a detailed step-by step account of how this This appendix gives a detailed step-by step account of how this
works. It starts with joining the Wi-Fi network and doing a DHCP client query process works. It starts with a client joining the Wi-
request, and ends with paper coming out of the printer. The reason Fi network and doing a DHCP request, and ends with paper coming out
the explanation is so detailed is to avoid inadvertently having a of the printer. The reason the explanation is gives the specific
hand-waving "and then a miracle occurs" part, which skips over details of every step is to avoid inadvertently having a hand-waving
important details. And one of the reasons for asking the IETF "and then a miracle occurs" part, which misses out some important
network team to set this up for IETF meetings is that operational use detail. And one of the reasons for asking the IETF network team to
is an important reality check. When standing in front of a room, set this up for IETF meetings is that operational use is an important
giving a presentation, if you miss out some vital step, people may reality check. When standing in front of a room, giving a
not notice. When running an actual service used by actual people, if presentation, if you miss out some vital step, people may not notice.
you miss out some vital step, no paper comes out of the printer, and When running an actual service used by actual people, if you miss out
everyone notices. some vital step, no paper comes out of the printer, and everyone
notices.
Using a macOS computer, at an IETF meeting, you can repeat the steps Using a macOS computer, at an IETF meeting, you can repeat the steps
illustrated here to see exactly how it works. Or you can simply illustrated here to see exactly how it works. Or you can simply
press Cmd-P in any application and see that "term-printer" appears as press Cmd-P in any application and see that "term-printer" appears as
an available printer, to confirm that it does in fact work. an available printer, to confirm that it does in fact work.
First, let's see what the macOS computer learned from the local DHCP First, let's see what the macOS computer learned from the local DHCP
server: server:
% scutil % scutil
skipping to change at page 15, line 5 skipping to change at page 15, line 5
Option_15 : <data> 0x6d656574696e672e696574662e6f7267 Option_15 : <data> 0x6d656574696e672e696574662e6f7267
... ...
} }
Option_15 is Domain Name. To see what domain name, we need to decode Option_15 is Domain Name. To see what domain name, we need to decode
the hexadecimal data to ASCII. the hexadecimal data to ASCII.
% echo 6d656574696e672e696574662e6f7267 0A | xxd -r -p % echo 6d656574696e672e696574662e6f7267 0A | xxd -r -p
meeting.ietf.org meeting.ietf.org
A.1. Domain Enumeration using PTR queries
Our DHCP domain name is meeting.ietf.org. Does meeting.ietf.org Our DHCP domain name is meeting.ietf.org. Does meeting.ietf.org
recommend that we look in any Wide Area Service Discovery domains? recommend that we look in any Wide Area Service Discovery domains?
This step is called Domain Enumeration [RFC6763], and is performed
using a DNS PTR query for a name with the special prefix "lb._dns-
sd._udp":
% dig lb._dns-sd._udp.meeting.ietf.org. ptr % dig lb._dns-sd._udp.meeting.ietf.org. ptr
; <<>> DiG 9.6-ESV-R4-P3 <<>> lb._dns-sd._udp.meeting.ietf.org. ptr ; <<>> DiG 9.6-ESV-R4-P3 <<>> lb._dns-sd._udp.meeting.ietf.org. ptr
;; global options: +cmd ;; global options: +cmd
;; Got answer: ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35624 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35624
;; flags: qr aa rd ra; ;; flags: qr aa rd ra;
QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
skipping to change at page 15, line 30 skipping to change at page 15, line 35
;; ANSWER SECTION: ;; ANSWER SECTION:
lb._dns-sd._udp.meeting.ietf.org. 3600 IN PTR meeting.ietf.org. lb._dns-sd._udp.meeting.ietf.org. 3600 IN PTR meeting.ietf.org.
... ...
;; Query time: 8 msec ;; Query time: 8 msec
;; SERVER: 130.129.5.6#53(130.129.5.6) ;; SERVER: 130.129.5.6#53(130.129.5.6)
;; WHEN: Wed Mar 13 10:16:40 2013 ;; WHEN: Wed Mar 13 10:16:40 2013
;; MSG SIZE rcvd: 188 ;; MSG SIZE rcvd: 188
In the middle there you'll see that the answer is "meeting.ietf.org". In the middle there in the Answer Section you'll see that the answer
In this case the answer is self-referential -- "meeting.ietf.org" is to the PTR query is "meeting.ietf.org". In this case the answer is
inviting us to look for services in "meeting.ietf.org", but the PTR self-referential -- "meeting.ietf.org" is inviting us to look for
record(s) could equally well point at any other domain, such as services in "meeting.ietf.org", but the PTR record(s) could equally
"services.ietf.org", or anything else. well point at any other domain, such as "services.ietf.org", or
anything else.
Note that this answer does not depend on the client device being "on" Note that this answer does not depend on the client device being "on"
the IETF meeting network, which is in any case a loosely defined the IETF meeting network, which is in any case a loosely defined
concept at best. Nor does it depend on sending the DNS query to a concept at best. Nor does it depend on sending the DNS query to a
DNS server that is "on" the IETF meeting network. Any capable DNS DNS server that is "on" the IETF meeting network. Any capable DNS
recursive resolver anywhere on the planet will give the same answer. recursive resolver anywhere on the planet will give the same answer.
We can test this by sending the same DNS query to Google's 8.8.8.8 We can test this by sending the same DNS PTR query to Google's
public resolver: 8.8.8.8 public resolver:
% dig @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr % dig @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr
; <<>> DiG 9.6-ESV-R4-P3 <<>> ; <<>> DiG 9.6-ESV-R4-P3 <<>>
@8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr
; (1 server found) ; (1 server found)
;; global options: +cmd ;; global options: +cmd
;; Got answer: ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24571 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24571
;; flags: qr rd ra; QUERY:1, ANSWER:1, AUTHORITY:0, ADDITIONAL:0 ;; flags: qr rd ra; QUERY:1, ANSWER:1, AUTHORITY:0, ADDITIONAL:0
skipping to change at page 16, line 34 skipping to change at page 16, line 34
;lb._dns-sd._udp.meeting.ietf.org. IN PTR ;lb._dns-sd._udp.meeting.ietf.org. IN PTR
;; ANSWER SECTION: ;; ANSWER SECTION:
lb._dns-sd._udp.meeting.ietf.org. 1532 IN PTR meeting.ietf.org. lb._dns-sd._udp.meeting.ietf.org. 1532 IN PTR meeting.ietf.org.
;; Query time: 21 msec ;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) ;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Mar 13 10:18:27 2013 ;; WHEN: Wed Mar 13 10:18:27 2013
;; MSG SIZE rcvd: 64 ;; MSG SIZE rcvd: 64
In the middle there you'll see that the answer is still In the Answer Section you'll see that the answer is still
"meeting.ietf.org". "meeting.ietf.org".
In this example, this particular test was done at the 86th IETF in In this example, this particular test was done at the 86th IETF in
Orlando, Florida, in March 2013. The Google 8.8.8.8 public resolver Orlando, Florida, in March 2013. The Google 8.8.8.8 public resolver
still gave the correct answer, even though it was 13 hops away: still gave the correct answer, even though it was 13 hops away:
% traceroute -q 1 8.8.8.8 % traceroute -q 1 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 rtra (130.129.80.2) 1.369 ms 1 rtra (130.129.80.2) 1.369 ms
2 75-112-170-148.net.bhntampa.com (75.112.170.148) 14.494 ms 2 75-112-170-148.net.bhntampa.com (75.112.170.148) 14.494 ms
skipping to change at page 17, line 33 skipping to change at page 17, line 33
13 google-public-dns-a.google.com (8.8.8.8) 32.961 ms 13 google-public-dns-a.google.com (8.8.8.8) 32.961 ms
For the rest of this example we use the Google 8.8.8.8 public For the rest of this example we use the Google 8.8.8.8 public
resolver for all the queries. resolver for all the queries.
In the case of IETF meetings the PTR is self-referential -- In the case of IETF meetings the PTR is self-referential --
meeting.ietf.org is advising us to look in meeting.ietf.org, but it meeting.ietf.org is advising us to look in meeting.ietf.org, but it
could easily be set up to direct us elsewhere. However, since it's could easily be set up to direct us elsewhere. However, since it's
suggesting we look for services in meeting.ietf.org, we'll do that. suggesting we look for services in meeting.ietf.org, we'll do that.
A.2. Instance Enumeration using PTR queries on a macOS computer
Once one or more service discovery domains have been determined, the
client then looks for instances of the desired service type. This
step is called Instance Enumeration and is also performed using a DNS
PTR queries, using a name with a prefix indicating the type of
service that is being sought.
A macOS computer with appropriate printer drivers installed will look A macOS computer with appropriate printer drivers installed will look
for instances of the "_pdl-datastream._tcp" service type at for instances of the service type "_pdl-datastream._tcp" in the
"meeting.ietf.org": domain "meeting.ietf.org", as shown below. This is typically
performed just once, the first time the macOS computer is set up to
use that printer.
% dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. ptr % dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. ptr
term-printer._pdl-datastream._tcp.meeting.ietf.org. term-printer._pdl-datastream._tcp.meeting.ietf.org.
There's one printing service available here, called "term-printer". There's one printing service available here, called "term-printer".
That's what you see when you press the "+" button in the Print & Fax That's what you see when you press the "+" button in the Print & Fax
Preference Pane on macOS. Preference Pane on macOS.
When the user actually prints something, macOS does these queries: A.3. Printing from a macOS computer
When the user actually prints something, macOS sends a DNS SRV query
for the printer name learned in the previous Instance Enumeration
step, to learn the target host and port for the service. This DNS
SRV query is then followed by address queries for the target host's
IPv4 and/or IPv6 addresses. The necessary address records are
usually included in the Additional Section of the reply to the SRV
query, so that these address queries can be answered from the local
cache, without resulting in additional packets over the air.
% dig +short @8.8.8.8 \ % dig +short @8.8.8.8 \
term-printer._pdl-datastream._tcp.meeting.ietf.org. srv term-printer._pdl-datastream._tcp.meeting.ietf.org. srv
0 0 9100 term-printer.meeting.ietf.org. 0 0 9100 term-printer.meeting.ietf.org.
% dig +short @8.8.8.8 term-printer.meeting.ietf.org. AAAA % dig +short @8.8.8.8 term-printer.meeting.ietf.org. AAAA
2001:df8::48:200:74ff:fee0:6cf8 2001:df8::48:200:74ff:fee0:6cf8
This tells the computer that to use this printer, it must connect to This tells the computer that to use this printer, it must connect to
[2001:df8::48:200:74ff:fee0:6cf8]:9100, using the installed printer [2001:df8::48:200:74ff:fee0:6cf8]:9100, using the installed printer
driver, which speaks the appropriate vendor-specific printing driver, which speaks the appropriate vendor-specific printing
protocol for that printer. protocol for that printer.
A.4. Instance Enumeration using PTR queries on an iOS device
Printing from an iPhone or iPad is similar, except there are no Printing from an iPhone or iPad is similar, except there are no
vendor-specific printer drivers installed. Instead, printing from an vendor-specific printer drivers installed. Instead, printing from an
iPhone or iPad uses the IETF Standard IPP printing protocol, using an iPhone or iPad uses the IETF Standard IPP printing protocol, using an
IPP printer that supports at least URF (Universal Raster Format): IPP printer that supports at least URF (Universal Raster Format).
Consequently, the iOS device sends its Instance Enumeration DNS PTR
queries using the prefix "_universal._sub._ipp._tcp" to indicate that
it is looking for the subset of IPP printers that support Universal
Raster Format.
% dig +short @8.8.8.8 \ % dig +short @8.8.8.8 \
_universal._sub._ipp._tcp.meeting.ietf.org. ptr _universal._sub._ipp._tcp.meeting.ietf.org. ptr
term-printer._ipp._tcp.meeting.ietf.org. term-printer._ipp._tcp.meeting.ietf.org.
An iPhone or iPad will discover that there's one IPP-based printing An iPhone or iPad will discover that there's one URF-capable IPP-
service available here, called "term-printer". It has the same name based printing service available here, called "term-printer". It has
as the pdl-datastream printing service, and exists on the same the same name as the pdl-datastream printing service, and exists on
physical hardware, but uses a different printing protocol. the same physical hardware, but uses a different printing protocol.
A.5. Printing from an iOS device
When the user prints from their iPhone or iPad using AirPrint, iOS When the user prints from their iPhone or iPad using AirPrint, iOS
does these queries: does these DNS SRV and address queries:
% dig +short @8.8.8.8 term-printer._ipp._tcp.meeting.ietf.org. srv % dig +short @8.8.8.8 term-printer._ipp._tcp.meeting.ietf.org. srv
0 0 631 term-printer.meeting.ietf.org. 0 0 631 term-printer.meeting.ietf.org.
% dig +short @8.8.8.8 term-printer.meeting.ietf.org. aaaa % dig +short @8.8.8.8 term-printer.meeting.ietf.org. aaaa
2001:df8::48:200:74ff:fee0:6cf8 2001:df8::48:200:74ff:fee0:6cf8
Note that the "_ipp._tcp" service has the same target hostname and Note that the "_ipp._tcp" service has the same target hostname and
IPv6 address as the "_pdl-datastream" service, but is accessed at a IPv6 address as the "_pdl-datastream" service from the macOS example,
different TCP port on that hardware device. but is accessed at a different TCP port on that hardware device.
To use this printer, the iPhone or iPad connects to To use this printer, the iPhone or iPad connects to
[2001:df8::48:200:74ff:fee0:6cf8]:631, and uses IPP to print. [2001:df8::48:200:74ff:fee0:6cf8]:631, and uses IPP to print.
Author's Address Author's Address
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014
 End of changes. 51 change blocks. 
169 lines changed or deleted 225 lines changed or added

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