[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 RFC 3832
INTERNET DRAFT W. Zhao
draft-zhao-slp-remote-da-discovery-06.txt H. Schulzrinne
[Target Category: Experimental] Columbia University
March 23, 2004 E. Guttman
Expires: September 23, 2004 Sun Microsystems
C. Bisdikian
W. Jerome
IBM
Remote Service Discovery in the Service Location Protocol via DNS SRV
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Remote service discovery refers to discovering desired services in
given remote (i.e., non-local) DNS domains. This document describes
remote service discovery in the Service Location Protocol (SLP) via
DNS SRV. It defines the DNS SRV Resource Records for SLP Directory
Agent services, discusses various issues in using SLP and DNS SRV
together for remote service discovery, and gives the steps for
discovering desired services in remote DNS domains.
Zhao, et al. Expires: September 23, 2004 [Page 1]
Internet Draft Remote Discovery in SLP via DNS SRV March 23, 2004
1. Introduction
This document describes remote service discovery in the Service
Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782]. We consider
remote service discovery as discovering desired services in given
remote DNS domains, and local service discovery as discovering
desired services within the local administrative domain.
SLP provides a scalable framework for local service discovery and
selection. In SLP, User Agents (UAs) discover desired services in the
local administrative domain by querying all Service Agents (SAs) via
multicast or querying a Directory Agent (DA) via unicast. To query a
DA using unicast, a UA needs to first learn about the DA via DHCP,
static configuration or multicast (listening for DAAdvert multicast
or issuing DA discovery SrvRqst multicast).
DNS SRV provides a good support for remote service discovery.
However, if multiple servers are discovered via DNS SRV for a
service, only priority and weight can be used to make a selection. If
additional service properties (such as cost, speed and service
quality) need to be considered in the selection process, DNS SRV
becomes insufficient.
We propose that using SLP and DNS SRV together can provide a better
support for remote service discovery. First, a UA uses DNS SRV to
find SLP DAs at a remote DNS domain. Then, the UA queries one of
those DAs to discover desired services. In this way, we can avoid the
limitations in using SLP and DNS SRV separately. On one hand, without
DNS SRV, an SLP UA needs to depend on static configuration to learn
about remote DAs because DHCP and multicast DA discovery are not
generally applicable beyond the local administrative domain. On the
other hand, without SLP, DNS SRV has limited support for service
selection.
In this document, we first define the DNS SRV Resource Records (RRs)
for SLP DA services, which are used to map a given DNS domain to
remotely accessible (i.e., accessible from the Internet) DAs in that
domain. Then, we discuss various issues in using SLP and DNS SRV
together for remote service discovery. Finally, we give the steps for
discovering desired services in remote DNS domains.
1.1. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
Zhao, et al. Expires: September 23, 2004 [Page 2]
Internet Draft Remote Discovery in SLP via DNS SRV March 23, 2004
2. The DNS SRV RRs for SLP DA services
According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services
are defined as follows:
_slpda._Proto.Name TTL Class SRV Priority Weight Port Target
where "slpda" is the symbolic name for SLP DA services in Assigned
Numbers [NUMBERS], the Proto field is either "tcp" or "udp", and the
Target field is the domain name of an SLP DA. Please refer to
[RFC2782] for detailed explanation of each field in DNS SRV RRs.
Next we show an example of using DNS SRV RRs to map a given DNS
domain to remotely accessible DAs in that domain. To discover
remotely accessible DAs in a remote domain (say, example.com), a UA
makes a DNS query [RFC1034,RFC1035] for QNAME=_slpda._tcp.example.com
(or QNAME=_slpda._udp.example.com), QCLASS=IN, and QTYPE=SRV. Then
the UA will receive a list of DNS SRV RRs in a DNS reply, which gives
all remotely accessible DAs in the domain example.com, such as:
;; Priority Weight Port Target
_slpda._tcp.example.com IN SRV 0 0 427 da1.example.com
_slpda._tcp.example.com IN SRV 0 0 427 da2.example.com
3. Remote Service Discovery in SLP via DNS SRV
SLP DAs can be discovered in two ways: (1) using the mechanisms
described in RFC 2608, and (2) using DNS SRV RRs as described in this
document. The second approach is useful for UAs to acquire service
information for remote DNS domains. For example, a mobile node
visiting a network (without the use of mobile IP) may want to obtain
information about services in its home network.
3.1. The DNS Domain of Interest for Remote Service Discovery
Using DNS SRV RRs to discover SLP DAs requires knowledge of the
domain where SLP DAs are registered. For remote service discovery, we
assume that the DNS domain of interest is known via a priori
knowledge. For example, a UA is configured with a domain name or the
user provides the domain name manually.
Note that there is no implied "search order" of DNS domains in
finding remote DAs. For instance, if a UA is looking for remote DAs
in the domain foo.bar.example.com, it SHOULD only look for
_slp._tcp.foo.bar.example.com (or _slp._udp.foo.bar.example.com), and
MUST NOT fall back to look for _slp._tcp.bar.example.com,
_slp._tcp.example.com, and so on.
Zhao, et al. Expires: September 23, 2004 [Page 3]
Internet Draft Remote Discovery in SLP via DNS SRV March 23, 2004
3.2. SLP DAs for Remote Service Discovery
A UA discovers desired services in a given remote DNS domain by
unicasting requests to DAs in that domain. The UA uses remote DAs
according to these prioritized rules: (1) using DAs which it has been
configured with, and (2) using DAs which it has discovered via DNS
SRV.
3.3. SLP Scopes for Remote Service Discovery
As SLP scopes are intended to be used only within one administrative
domain, they are likely incomprehensible to users outside of the
administrative domain. Thus, any remotely accessible service MUST be
registered in the "default" scope, but it MAY be registered in other
scopes at the same time. Similarly, all DAs advertised via DNS SRV
MUST serve the "default" scope, but they MAY serve other scopes at
the same time. As a result, users wishing to discover services at a
remote DNS domain SHOULD only search the "default" scope.
4. Steps for Remote Service Discovery
The steps for a User Agent U to discover desired services in a remote
DNS domain D are as follows.
(1) U makes a DNS query for QNAME=_slpda._tcp.D (or
QNAME=_slpda._udp.D), QCLASS=IN, and QTYPE=SRV. Then U gets a
list of DNS SRV RRs (referred to as L) in a DNS reply, which
gives all remotely accessible DAs in D.
(2) U selects a DA X from L based on the priority and weight
information per RFC 2782.
(3) U queries X in the "default" scope to discover desired services
in D.
Note that the services discovered in the above steps may not
necessarily be remotely accessible.
5. Security Considerations
To support remote service discovery, a domain exposes its service
information to the Internet. Standard SLP authentication SHOULD be
used to protect valuable service information. First, there is a risk
that any SA could advertise any service on a DA accessible from the
Internet. Such a DA SHOULD reject all registrations and
deregistrations that cannot be authenticated. Secondly, to avoid
disclosing unintended service information to remote users, a DA
accessible from the Internet SHOULD at least authenticate service
Zhao, et al. Expires: September 23, 2004 [Page 4]
Internet Draft Remote Discovery in SLP via DNS SRV March 23, 2004
queries that are not in the "default" scope. In addition, the
security considerations for DNS SRV [RFC2782] apply to this document.
Also, the DNS security extensions [RFC 2535] SHOULD be used to
provide origin authentication and integrity protection for DNS data.
6. Applicability Statements
This specification describes remote service discovery in SLP via DNS
SRV. It facilitates discovering services at a remote DNS domain if
the domain name is known via a priori knowledge. However, it does not
intend to solve the problem of Internet-wide service discovery.
Users should be aware of two constraints in using DNS SRV to discover
SLP DAs: (1) they SHOULD only use DNS SRV to discover DAs in the
"default" scope, and (2) an administrator may choose to only register
a subset of all DAs in the "default" scope via DNS SRV. Thus, to
discover local DAs, implementations MUST use the standard SLP
mechanisms per RFC 2608. In addition, implementations supporting this
specification MAY use DNS SRV to discover local DAs in the "default"
scope.
As SLP scopes are not intended to be used outside the local
administrative domain, all remote service discovery in SLP SHOULD be
carried only in the "default" scope.
Notice that the services discovered via DNS SRV and remote SLP DAs
may not necessarily be remotely accessible.
7. IANA Considerations
In the DNS SRV RRs for SLP DA services, the symbolic name for the
Service field is "slpda", supported protocols are "tcp" and "udp".
The following values are to be registered with IANA:
Service Field Protocol Field Reference
------------- -------------- ---------
slpda tcp [RFCxxxx]
slpda udp [RFCxxxx]
8. Acknowledgments
The authors would like to thank Bernard Aboba, Kevin Arnold, Steven
Bellovin, Ted Hardie, James Kempf, Thomas Narten, Erik Nordmark and
Jon Peterson for their valuable comments.
9. Normative References
[RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service
Zhao, et al. Expires: September 23, 2004 [Page 5]
Internet Draft Remote Discovery in SLP via DNS SRV March 23, 2004
Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2782] A. Gulbrandsen, P. Vixie and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[NUMBERS] http://www.iana.org/assignments/port-numbers
[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification", STD 13, RFC 1034, November 1987.
[RFC2535] D. Eastlake, "Domain Name System Security Extensions",
RFC 2535, March 1999.
10. Authors' Addresses
Weibin Zhao
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
EMail: zwb@cs.columbia.edu
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
EMail: hgs@cs.columbia.edu
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
EMail: Erik.Guttman@sun.com
Zhao, et al. Expires: September 23, 2004 [Page 6]
Internet Draft Remote Discovery in SLP via DNS SRV March 23, 2004
Chatschik Bisdikian
IBM Corp.
Thomas J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532, USA
EMail: bisdik@us.ibm.com
William F. Jerome
IBM Corp.
Thomas J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532, USA
EMail: wfj@us.ibm.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zhao, et al. Expires: September 23, 2004 [Page 7]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/