summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3832.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3832.txt')
-rw-r--r--doc/rfc/rfc3832.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3832.txt b/doc/rfc/rfc3832.txt
new file mode 100644
index 0000000..583ffdb
--- /dev/null
+++ b/doc/rfc/rfc3832.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group W. Zhao
+Request for Comments: 3832 H. Schulzrinne
+Category: Experimental Columbia University
+ E. Guttman
+ Sun Microsystems
+ C. Bisdikian
+ W. Jerome
+ IBM
+ July 2004
+
+
+ Remote Service Discovery in the
+ Service Location Protocol (SLP) via DNS SRV
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+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.
+
+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
+
+
+
+
+Zhao, et al. Experimental [Page 1]
+
+RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
+
+
+ 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 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 better
+ support for remote service discovery. First, a UA uses DNS SRV to
+ find SLP DAs at a remote DNS domain. Then, the UA uses SLP to query
+ 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 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].
+
+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, 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.
+
+
+
+
+
+Zhao, et al. Experimental [Page 2]
+
+RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
+
+
+ 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,
+ it is assumed 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.
+
+
+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.
+
+
+
+
+
+
+
+Zhao, et al. Experimental [Page 3]
+
+RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
+
+
+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
+ 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.
+
+
+
+
+
+
+
+Zhao, et al. Experimental [Page 4]
+
+RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
+
+
+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 register only
+ 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.
+
+ Note 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 have been registered with IANA:
+
+ Service Field Protocol Field Reference
+ ------------- -------------- ---------
+ slpda tcp [RFC3832]
+ slpda udp [RFC3832]
+
+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] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+ Location Protocol, Version 2 ", RFC 2608, June 1999.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+
+
+Zhao, et al. Experimental [Page 5]
+
+RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2535] Eastlake 3rd, D., "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. Experimental [Page 6]
+
+RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
+
+
+ Dr. Chatschik Bisdikian
+ IBM T. J. Watson Research Center
+ 30 Saw Mill River Road, M/S 3S-B34
+ Hawthorne, NY 10532, USA
+
+ Phone: +1 914 784 7439
+ Fax: +1 914 784 6225
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhao, et al. Experimental [Page 7]
+
+RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Zhao, et al. Experimental [Page 8]
+