One document matched: draft-ietf-dnssd-requirements-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3927 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3927.xml">
<!ENTITY RFC4291 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4862 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4903 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4903.xml">
<!ENTITY RFC4944 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC6550 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml">
<!ENTITY RFC7346 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7346.xml">
<!ENTITY RFC7368 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7368.xml">
<!ENTITY I-D.cheshire-dnsext-special-names SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-special-names.xml">
<!ENTITY I-D.sullivan-dnssd-mdns-dns-interop SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-sullivan-dnssd-mdns-dns-interop-01.xml">
]>
<!-- Use with the following tips & tools:
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
http://xml.resource.org/authoring/README.html OR
http://xml.resource.org/authoring/README-dev.html
http://xml.resource.org/ OR
http://xml.resource.org/experimental.html
http://fenron.net/~fenner/ietf/xml2rfc-valid/ link appears to be broken :(
http://tools.ietf.org/tools/idnits/
http://tools.ietf.org/rfcdiff
https://datatracker.ietf.org/submit/
-->
<!-- Then upload:
https://datatracker.ietf.org/idst/upload.cgi
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.35) -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes"?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="yes"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="1"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- "no" to keep one blank line between list items (rfced) -->
<?rfc subcompact="no" ?>
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr="trust200902" docName="draft-ietf-dnssd-requirements-05">
<front>
<title abbrev="Scalable DNS-SD Requirements"> Requirements for Scalable DNS-SD/mDNS Extensions </title>
<author fullname="Kerry Lynn" initials="K." surname="Lynn">
<organization> Verizon </organization>
<address>
<postal>
<street> 50 Sylvan Road </street>
<city> Waltham </city>
<region> MA </region>
<code> 95014 </code>
<country> USA </country>
</postal>
<phone> +1 781 296 9722 </phone>
<email> kerry.lynn@verizon.com </email>
</address>
</author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization> Apple, Inc. </organization>
<address>
<postal>
<street> 1 Infinite Loop </street>
<city> Cupertino </city>
<region> CA </region>
<code> 95014 </code>
<country> USA </country>
</postal>
<phone> +1 408 974 3207 </phone>
<email> cheshire@apple.com </email>
</address>
</author>
<author fullname="Marc Blanchet" initials="M." surname="Blanchet">
<organization> Viagenie </organization>
<address>
<postal>
<street> 246 Aberdeen </street>
<city> Quebec </city>
<region> QC </region>
<code> G1R 2E1 </code>
<country> Canada </country>
</postal>
<email> Marc.Blanchet@viagenie.ca </email>
<uri> http://viagenie.ca </uri>
</address>
</author>
<author fullname="Daniel Migault" initials="D." surname="Migault">
<organization> Ericsson </organization>
<address>
<postal>
<street> 8400 boulevard Decarie </street>
<city> Montreal </city>
<region> QC </region>
<code> H4P 2N2 </code>
<country> Canada </country>
</postal>
<phone> +1 514 452 2160 </phone>
<email> daniel.migault@ericsson.com </email>
</address>
</author>
<date day="4" month="March" year="2015"/>
<area> Applications </area>
<workgroup> DNS-SD/mDNS Extensions </workgroup>
<abstract>
<t>
DNS-SD over mDNS is widely used today for discovery and resolution of
services and names on a local link, but there are use cases to extend
DNS-SD/mDNS to enable service discovery beyond the local link. This
document provides a problem statement and a list of requirements.
</t>
</abstract>
</front>
<middle>
<!-- section anchor="sec-1" title="Introduction" -->
<section title="Introduction">
<t>
DNS-Based Service Discovery <xref target="DNS-SD"/> in combination with its
companion technology Multicast DNS <xref target="mDNS"/> is widely used today for
discovery and resolution of services and names on a local link.
However, as users move to multi-link home or campus networks they
find that mDNS (by design) does not work across routers. DNS-SD can also be used
in conjunction with conventional unicast DNS to enable wide-area
service discovery, but this capability is not yet widely deployed.
This disconnect between customer needs and current practice has led
to calls for improvement, such as the <xref target="EP">Educause petition</xref>.
</t><t>
In response to this and similar evidence of market demand, several
products now enable service discovery beyond the local link using
different ad hoc techniques. As yet, no consensus has emerged regarding
which approach represents the best long-term direction for DNS-based
service discovery protocol development.
</t><t>
Multicast DNS in its present form is also not optimized for network
technologies where multicast transmissions are relatively expensive.
Wireless networks such as <xref target="IEEE.802.11">Wi-Fi</xref> may be adversely affected by
excessive mDNS traffic due to the higher network overhead of
multicast transmissions. Wireless mesh networks such as 6LoWPAN <xref target="RFC4944"/>
are effectively multi-link subnets <xref target="RFC4903"/> where multicasts must be
forwarded by intermediate nodes.
</t><t>
It is in the best interests of end users, network administrators, and
vendors for all interested parties to cooperate within the context of
the IETF to develop an efficient, scalable, and interoperable
standards-based solution.
</t><t>
This document defines the problem statement and gathers requirements
for Scalable DNS-SD/mDNS Extensions.
</t>
<!-- section anchor="sec-1.1" title="Terminology" -->
<section title="Terminology and Acronyms">
<t>
Service: A listening endpoint (host and port) for a given application
protocol. Services are identified by Service Instance Names.
</t><t>
DNS-SD: DNS-Based Service Discovery <xref target="DNS-SD"/> is a
conventional application of DNS Resource Records and messages to
facilitate the naming, discovery, and location of services. When
used alone, it generally refers to the wide-area unicast protocol.
</t><t>
mDNS: Multicast DNS <xref target="mDNS"/> is a mechanism that
facilitates distributed DNS-like capabilities (including DNS-SD)
on a local link without need of traditional DNS infrastructure.
</t><t>
SSD: Scalable Service Discovery (or Scalable DNS-SD)
is a future extension of DNS-SD (and perhaps mDNS)
that meets the requirements set forth in this document.
</t><t>
Scope of Discovery: A subset of a local or global namespace, e.g.,
a DNS subdomain, that is the target of a given SSD query.
</t><t>
Zero Configuration: A deployment of SSD that requires no
administration (although some administration may be optional).
</t><t>
Incremental Deployment: An orderly transition, as a network
installation evolves, from DNS-SD/mDNS to SSD.
</t>
</section>
</section>
<!-- section anchor="sec-2" title="Problem Statement" -->
<section title="Problem Statement">
<t>
Service discovery beyond the local link is perhaps the most important
feature currently missing from the DNS-SD-over-mDNS framework
(also written as "DNS-SD over mDNS" or "DNS-SD/mDNS").
Other issues and requirements are summarized below.
</t>
<!-- section anchor="sec-2.1" title="Multi-link Naming and Discovery" -->
<section title="Multi-link Naming and Discovery">
<t>
A list of desired DNS-SD/mDNS improvements from network
administrators in the research and education community was issued in
the form of the <xref target="EP">Educause petition</xref>. The following is a summary
of their technical issues:
<list style="symbols">
<t>
Products that advertise services such as printing and multimedia
streaming via DNS-SD over mDNS are not currently discoverable by
devices on other links. It is common practice for enterprises and
institutions to use wireless links for client access and wired
networks for server infrastructure, typically on different
subnets. DNS-SD used with conventional unicast DNS does work when
devices are on different links, but the resource records that
describe the service must somehow be entered into the unicast DNS
namespace.
</t><t>
DNS-SD resource records may be entered manually into a unicast DNS
zone file <xref target="STATIC"/>, but this task must be performed by a DNS administrator.
It is labor-intensive and brittle when IP addresses of devices
change dynamically, as is common when DHCP is used.
</t><t>
Automatically adding DNS-SD records using DNS Update works, but
requires that the DNS server be configured to allow DNS Updates,
and requires that devices be configured with the DNS Update
credentials to permit such updates, which has proven to be onerous.
</t>
</list>
</t>
<t>
Therefore, a mechanism is desired that populates the DNS namespace
with the appropriate DNS-SD records with less manual administration
than typically needed for a unicast DNS server.
</t>
<t>
The following is a summary of their technical requirements:
<list style="symbols">
<t>
It must scale to a range of hundreds to thousands of
DNS-SD/mDNS-enabled devices in a given environment.
</t><t>
It must simultaneously operate over a variety of network link
technologies, such as wired and wireless networks.
</t><t>
It must not significantly increase network traffic (wired or
wireless).
</t><t>
It must be cost-effective to manage at up to enterprise scale.
</t>
</list>
</t>
</section>
<!-- section anchor="sec-2.2" title="Support for Low Power and Lossy Networks" -->
<section title="IEEE 802.11 Wireless LANs">
<t>
Multicast DNS was originally designed to run on Ethernet - the
dominant link-layer at the time. In shared Ethernet networks,
multicast frames place little additional demand on the shared network
medium compared to unicast frames. In IEEE 802.11 networks however,
multicast frames are transmitted at a low data rate supported by all
receivers. In practice, this data rate leads to a larger fraction
of airtime being devoted to multicast transmission. Some network
administrators block multicast traffic, or use access points that
transmit multicast frames using a series of link-layer unicast frames.
</t><t>
Wireless links may be orders of magnitude less reliable than their
wired counterparts. To improve transmission reliability, the IEEE
802.11 MAC requires positive acknowledgement of unicast frames. It
does not, however, support positive acknowledgement of multicast
frames. As a result, it is common to observe much higher loss of
multicast frames on wireless as compared to wired network technologies.
</t><t>
Enabling service discovery on IEEE 802.11 networks requires that the
number of multicast frames be restricted to a suitably low value, or
replaced with unicast frames to use the MAC’s reliability features.
</t>
</section>
<!-- section anchor="sec-2.3" title="Support for Low Power and Lossy Networks" -->
<section title="Low Power and Lossy Networks (LLNs)">
<t>
Emerging wireless mesh networking technologies such as RPL <xref target="RFC6550"/>
and 6LoWPAN present several challenges for the current DNS-SD/mDNS
design. First, Link-Local multicast scope <xref target="RFC4291"/>
is defined as a single-hop neighborhood. A wireless mesh network representing a
single logical subnet may often extend to multiple hops <xref target="RFC4903"/>, therefore
a larger multicast scope is required to span it <xref target="RFC7346"/>.
Multicast DNS was intentionally not specified for
greater than Link-Local scope, because of the additional off-link
multicast traffic that would generate.
</t><t>
Additionally, low-power nodes may be offline for significant periods
either because they are "sleeping" or due to connectivity problems.
In such cases LLN nodes might fail to respond to queries or defend
their names using the current design.
</t>
</section>
</section>
<?rfc needLines="8" ?>
<!-- section anchor="sec-3" title="Basic Use Cases" -->
<section title="Basic Use Cases">
<t>
The following use cases are defined with different characteristics to
help motivate, distinguish, and classify the target requirements. They
cover a spectrum of increasing deployment and administrative complexity.
<list>
<t>
(A) Personal Area networks (PANs): the simplest example of a network
may consist of a single client and server, e.g., one laptop and one
printer, on a common link. PANs that do not contain a router may use
Zero Configuration Networking <xref target="ZC"/> to
self-assign link-local addresses <xref target="RFC3927"/> <xref target="RFC4862"/>,
and Multicast DNS <xref target="mDNS"/> to provide naming and service discovery,
as currently implemented and deployed in Mac OS X, iOS,
Windows <xref target="B4W"/> and Android <xref target="NSD"/>.
</t><t>
(B) Classic home or 'hotspot' networks, with the following properties:
<list style="symbols">
<t>
Single exit router: the network may have one or more upstream
providers or networks, but all outgoing and incoming traffic goes
through a single router.
</t><t>
One-level depth: a single physical link, or
multiple physical links bridged to form a single logical link,
that is connected to the default router.
The single logical link provides a single broadcast domain,
facilitating use of link-local Multicast DNS, and also ARP,
which enables the home or 'hotspot' network to consist of just
a single IPv4 subnet.
</t><t>
Single administrative domain: all nodes under the same administrative authority.
(However, this does not necessarily imply a network administrator.)
</t>
</list>
</t><t>
(C) Advanced home and small business networks <xref target="RFC7368"/>:
</t><t>
Like B, but consist of multiple wired and/or wireless links, connected
by routers, generally behind a single exit router. However, the forwarding
nodes are largely self-configuring and do not require routing protocol
administration. Such networks should also not require DNS administration.
</t><t>
(D) Enterprise networks:
</t><t>
Consist of arbitrary network diameter under a single administrative
authority. A large majority of the forwarding and security devices are
configured and multiple exit routers are more common.
Large-scale conference-style networks, which are predominantly
wireless access, e.g., as available at IETF
meetings, also fall within this category.
</t><t>
(E) Higher Education networks:
</t><t>
Like D but the core network may be under a central administrative domain
while leaf networks are under local administrative domains.
</t><t>
(F) Mesh networks such as RPL/6LoWPAN:
</t><t>
Multi-link subnets with prefixes defined by one or more border
routers. May comprise any part of networks C, D, or E.
</t>
</list>
</t>
</section>
<!-- section anchor="sec-4" title="Requirements" -->
<section title="Requirements">
<t>
Any successful SSD solution(s) will have to strike the proper balance
between competing goals such as scalability, deployability, and
usability. With that in mind, none of the requirements listed below
should be considered in isolation.
</t><t>
<list style="format REQ%d:">
<t>
For use cases A, B, and C, there should be a Zero Configuration
mode of operation. This implies that servers and clients should
be able to automatically determine a default Scope of Discovery
in which to advertise and discover services, respectively.
</t><t>
For use cases C, D, and E, there should be a way to configure
Scopes of Discovery that support a range of topologically-
independent zones (e.g., from department to campus-wide).
This capability must exist in the protocol; individual
operators are not required to use this capability in all cases
-- in particular, use case C should support Zero Configuration
operation where that is desired.
If multiple scopes are available, there must be a way to enumerate
the choices from which a selection can be made. In use case C,
either Zero Configuration (one flat list of resources) or configured
(e.g., resources sorted by room) modes of operation should be available.
</t><t>
As stated in REQ2 above, the discovery scope need not be aligned
to network topology. For example, it may instead be aligned to
physical proximity (e.g., building) or organizational structure,
(e.g., "Sales" vs. "Engineering").
</t><t>
For use cases C, D, and E, there should be an incremental way to
deploy the solution.
</t><t>
SSD should leverage and build upon current link scope DNS-SD/mDNS
protocols and deployments.
</t><t>
SSD must not adversely affect or break any other current protocols
or deployments.
</t><t>
SSD must be capable of operating across networks that are
not limited to a single link or network technology,
including clients and services on non-adjacent links.
</t><t>
It is desirable that a user or device be able to discover services
within the sites or networks to which the user or device is
connected.
</t><t>
SSD should operate efficiently on common link layers and link
types.
</t><t>
SSD should be considerate of networks where power consumption
is a critical factor and, for example, nodes may be in a low
power or sleeping state.
</t><t>
SSD must be scalable to thousands of nodes with minimal
configuration and without degrading network performance. A
possible figure of merit is that, as the number of services
increases, the amount of traffic due to SSD on a given link
remains relatively constant.
</t><t>
SSD should enable a way to provide a consistent user
experience whether local or remote services are being
discovered.
</t><t>
The information presented by SSD should closely reflect
the current state of discoverable services on the network.
That is, new information should be available within a few seconds
and stale information should not persist indefinitely.
In networking all information is necessarily somewhat
out-of-date by the time it reaches the receiver,
even if only by a few microseconds, or less.
Thus timeliness is always an engineering trade-off against
efficiency. The engineering decisions for SSD should appropriately
balance timeliness against network efficiency.
</t><t>
SSD should operate over existing networks (as described by
use cases A-F above) without requiring changes to the network
at the physical, link, or internetworking layers.
</t>
</list>
</t>
</section>
<!-- section anchor="sec-5" title="Namespace Considerations" -->
<section title="Namespace Considerations">
<t>
The traditional unicast DNS namespace contains,
for the most part, globally unique names.
Multicast DNS provides every link with its own separate link-local
namespace, where names are unique only within the context of
that link. Clients discovering services may need to differentiate
between local and global names, and may need to determine
when names in different namespaces identify the same service.
</t><t>
Devices on different links may have the same mDNS name
(perhaps due to vendor defaults), because link-local mDNS
names are only guaranteed to be unique on a per-link basis.
Also, even devices that are on the same link may have
similar-looking names, such as one device with the name
"Bill" and another device using the similar-looking name
"Bi11" (using the digit "1" in place of the letter "l").
This may lead to a local label disambiguation problem between
presented results.
</t><t>
SSD should support rich internationalized labels within Service
Instance Names, as DNS-SD/mDNS does today. SSD must not negatively
impact the global DNS namespace or infrastructure.
</t><t>
The problem of publishing local services in the global DNS namespace
may be generally viewed as exporting local resource records and their
associated labels into some DNS zone. The issues related to defining
labels that are interoperable between local and global namespaces are
discussed in a separate document <xref target="I-D.sullivan-dnssd-mdns-dns-interop"/>.
</t>
</section>
<!-- section anchor="Security" title="Security Considerations" -->
<section title="Security Considerations">
<t>
Insofar as SSD may automatically gather DNS-SD resource records and
publish them over a wide area, the security issues are likely to include
the union of those discussed in the <xref target="mDNS">Multicast DNS</xref>
and <xref target="DNS-SD">DNS-Based Service Discovery</xref> specifications.
The following sections highlight potential threats that are posed by
deploying DNS-SD over multiple links or by automating DNS-SD
administration.
</t>
<!-- section anchor="sec-6.1" title="Scope of Discovery" -->
<section title="Scope of Discovery">
<t>
In some scenarios, the owner of the advertised service may
not have a clear indication of the scope of its advertisement.
</t><t>
For example, since mDNS is currently restricted to a single link,
the scope of the advertisement is limited, by design, to the
shared link between client and server. If the advertisement
propagates to a larger set of links than expected, this may
result in unauthorized clients (from the perspective of the owner)
discovering and then potentially attempting to connect to the
advertised service. It also discloses information (about the
host and service) to a larger set of potential attackers.
</t><t>
Note that discovery of a service does not necessarily imply that the service
is reachable by, or can be connected to, or can be used by, a given client.
Specific access control mechanisms are out of scope of this document.
</t><t>
If the scope of the discovery is not properly set up or constrained,
then information leaks will happen outside the appropriate network.
</t>
</section>
<!-- section anchor="sec-6.2" title="Multiple Namespaces" -->
<section title="Multiple Namespaces">
<t>
There is a possibility of conflicts between the local and global
DNS namespaces. Without adequate feedback, a discovering client
may not know if the advertised service is the correct one,
therefore enabling potential attacks.
</t>
</section>
<!-- section anchor="sec-6.3" title="Authorization" -->
<section title="Authorization">
<t>
DNSSEC can assert the validity but not the accuracy of records in
a zone file. The trust model of the global DNS relies on the fact
that human administrators either (a) manually enter resource records
into a zone file, or (b) configure the DNS server to authenticate a
trusted device (e.g., a DHCP server) that can automatically maintain
such records.
</t><t>
An impostor may register on the local link and appear as a
legitimate service. Such "rogue" services may then be automatically
registered in unicast DNS-SD.
</t>
</section>
<!-- section anchor="sec-6.4" title="Authentication" -->
<section title="Authentication">
<t>
Up to now, the "plug-and-play" nature of mDNS devices has relied
only on physical connectivity. If a device is visible via mDNS then
it is assumed to be trusted. This is not likely to be the case in
foreign networks.
</t><t>
If there is a risk that clients may be fooled by the deployment
of rogue services, then application layer authentication should
be considered as part of any security solution. Authentication of
any particular service is outside the scope of this document.
</t>
</section>
<!-- section anchor="sec-6.5" title="Access Control" -->
<section title="Access Control">
<t>
Access Control refers to the ability to restrict which users are able
to use a particular service that might be advertised via DNS-SD. In
this case, "use" of a service is different from the ability to
"discover" or "reach" a service.
</t><t>
While controlling access to an advertised service is outside the scope of
DNS-SD, we note that access control today often is provided by
existing site infrastructure (e.g., router access control lists,
firewalls) and/or by service-specific mechanisms (e.g., user
authentication to the service).
For example, networked printers can control access via a user-id and password.
Apple's software supports such access control for USB printers shared
via Mac OS X Printer Sharing, as do many networked printers themselves.
So the reliance on existing service-specific
security mechanisms (i.e. outside the scope of DNS-SD) does not
create new security considerations.
</t>
</section>
<!-- section anchor="sec-6.6" title="Privacy Issues" -->
<section title="Privacy Considerations">
<t>
Mobile devices such as smart phones or laptops that can expose the location
of their owners by registering services in arbitrary zones pose a
risk to privacy. Such devices must not register their services in
arbitrary zones without the approval ("opt-in") of their users.
However, it should be possible to configure one or more "safe"
zones in which mobile devices may automatically register their
services.
</t>
</section>
</section>
<!-- section anchor="IANA" title="IANA Considerations" -->
<section title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<!-- section anchor="Acknowledgments" title="Acknowledgments" -->
<section title="Acknowledgments">
<t>
We gratefully acknowledge contributions and review comments made by
RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David
Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler,
and Peter Van Der Stok.
<!-- <vspace blankLines='100' /> page break -->
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC3927;
&RFC4291;
&RFC4862;
&RFC4903;
&RFC4944;
&RFC6550;
&RFC7346;
&RFC7368;
<reference anchor="mDNS">
<front>
<title>Multicast DNS</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization/>
</author>
<date year="2013" month="February"/>
</front>
<seriesInfo name="RFC" value="6762"/>
<format type="TXT" octets="184992" target="http://www.rfc-editor.org/rfc/rfc6762.txt"/>
</reference>
<reference anchor="DNS-SD">
<front>
<title>DNS-Based Service Discovery</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization/>
</author>
<date year="2013" month="February"/>
</front>
<seriesInfo name="RFC" value="6763"/>
<format type="TXT" octets="125192" target="http://www.rfc-editor.org/rfc/rfc6763.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="B4W" target="http://en.wikipedia.org/wiki/Bonjour_(software)">
<front>
<title>Bonjour for Windows</title>
<author/>
<date/>
</front>
</reference>
&I-D.sullivan-dnssd-mdns-dns-interop;
<reference anchor="EP">
<front>
<title>Educause Petition</title>
<author>
</author>
<date month="July" year="2012"/>
</front>
<seriesInfo name="" value="https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group"/>
<format type="TXT" target="https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group"/>
</reference>
<reference anchor="IEEE.802.11" target="http://standards.ieee.org/getieee802/download/802.11-2012.pdf">
<front>
<title>
Information technology - Telecommunications and information exchange between systems -
Local and metropolitan area networks - Specific requirements -
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications
</title>
<author>
<organization/>
</author>
<date month="" year="2012"/>
</front>
<seriesInfo name="IEEE" value="Std 802.11-2012"/>
</reference>
<reference anchor="NSD" target="http://developer.android.com/reference/android/net/nsd/NsdManager.html">
<front>
<title>NsdManager | Android Developer</title>
<author/>
<date month="June" year="2012"/>
</front>
</reference>
<reference anchor="STATIC" target="http://www.dns-sd.org/ServerStaticSetup.html">
<front>
<title>Manually Adding DNS-SD Service Discovery Records to an Existing Name Server</title>
<author>
<organization/>
</author>
<date month="July" year="2013"/>
</front>
</reference>
<reference anchor="ZC">
<front>
<title>Zero Configuration Networking: The Definitive Guide</title>
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire"/>
<author initials="D.H." surname="Steinberg" fullname="Daniel H. Steinberg"/>
<date year="2005" month="December"/>
</front>
<seriesInfo name="O'Reilly Media, Inc." value=""/>
<seriesInfo name="ISBN" value="0-596-10100-7"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:55:49 |