Movatterモバイル変換

Network Working Group                                            W. ZhaoRequest for Comments: 3832                                H. SchulzrinneCategory: Experimental                               Columbia University                                                              E. Guttman                                                        Sun Microsystems                                                            C. Bisdikian                                                               W. Jerome                                                                     IBM                                                               July 2004Remote Service Discovery in theService Location Protocol (SLP) via DNS SRVStatus 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.  ToZhao, 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 inBCP 14,RFC 2119   [RFC2119].2.  The DNS SRV RRs for SLP DA services   According toRFC 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.com3.  Remote Service Discovery in SLP via DNS SRV   SLP DAs can be discovered in two ways: (1) using the mechanisms   described inRFC 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 20043.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 perRFC 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 20046.  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 perRFC 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.comZhao, 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.comZhao, et al.                  Experimental                      [Page 7]

RFC 3832          Remote Discovery in SLP via DNS SRV          July 200411.  Full Copyright Statement   Copyright (C) The Internet Society (2004).  This document is subject   to the rights, licenses and restrictions contained inBCP 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 inBCP 78 andBCP 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 athttp://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]