Difference between revisions of "RFC3832"

From RFC-Wiki
 
Line 12: Line 12:
 
           Service Location Protocol (SLP) via DNS SRV
 
           Service Location Protocol (SLP) via DNS SRV
  
Status of this Memo
+
'''Status of this Memo'''
  
 
This memo defines an Experimental Protocol for the Internet
 
This memo defines an Experimental Protocol for the Internet
Line 19: Line 19:
 
Distribution of this memo is unlimited.
 
Distribution of this memo is unlimited.
  
Copyright Notice
+
'''Copyright Notice'''
  
 
Copyright (C) The Internet Society (2004).
 
Copyright (C) The Internet Society (2004).
  
Abstract
+
'''Abstract'''
  
 
Remote service discovery refers to discovering desired services in
 
Remote service discovery refers to discovering desired services in
Line 36: Line 36:
  
 
This document describes remote service discovery in the Service
 
This document describes remote service discovery in the Service
Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782].  We consider
+
Location Protocol (SLP) [[RFC2608]] via DNS SRV [[RFC2782]].  We consider
 
remote service discovery as discovering desired services in given
 
remote service discovery as discovering desired services in given
 
remote DNS domains, and local service discovery as discovering
 
remote DNS domains, and local service discovery as discovering
Line 78: Line 78:
 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
+
document are to be interpreted as described in [[BCP14|BCP 14]], [[RFC2119|RFC 2119]]
[RFC2119].
+
[[RFC2119]].
  
 
== The DNS SRV RRs for SLP DA services ==
 
== The DNS SRV RRs for SLP DA services ==
  
According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services
+
According to [[RFC2782|RFC 2782]] [[RFC2782]], the DNS SRV RRs for SLP DA services
 
are defined as follows:
 
are defined as follows:
  
Line 90: Line 90:
 
where "slpda" is the symbolic name for SLP DA services, the Proto
 
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
 
field is either "tcp" or "udp", and the Target field is the domain
name of an SLP DA.  Please refer to [RFC2782] for detailed
+
name of an SLP DA.  Please refer to [[RFC2782]] for detailed
 
explanation of each field in DNS SRV RRs.
 
explanation of each field in DNS SRV RRs.
  
Line 108: Line 108:
  
 
SLP DAs can be discovered in two ways: (1) using the mechanisms
 
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
+
described in [[RFC2608|RFC 2608]], and (2) using DNS SRV RRs as described in this
 
document.  The second approach is useful for UAs to acquire service
 
document.  The second approach is useful for UAs to acquire service
 
information for remote DNS domains.  For example, a mobile node
 
information for remote DNS domains.  For example, a mobile node
Line 159: Line 159:
  
 
(2) U selects a DA X from L based on the priority and weight
 
(2) U selects a DA X from L based on the priority and weight
     information per RFC 2782.
+
     information per [[RFC2782|RFC 2782]].
  
 
(3) U queries X in the "default" scope to discover desired services
 
(3) U queries X in the "default" scope to discover desired services
Line 178: Line 178:
 
accessible from the Internet SHOULD at least authenticate service
 
accessible from the Internet SHOULD at least authenticate service
 
queries that are not in the "default" scope.  In addition, the
 
queries that are not in the "default" scope.  In addition, the
security considerations for DNS SRV [RFC2782] apply to this document.
+
security considerations for DNS SRV [[RFC2782]] apply to this document.
Also, the DNS security extensions [RFC 2535] SHOULD be used to
+
Also, the DNS security extensions [[[RFC2535|RFC 2535]]] SHOULD be used to
 
provide origin authentication and integrity protection for DNS data.
 
provide origin authentication and integrity protection for DNS data.
  
Line 194: Line 194:
 
a subset of all DAs in the "default" scope via DNS SRV.  Thus, to
 
a subset of all DAs in the "default" scope via DNS SRV.  Thus, to
 
discover local DAs, implementations MUST use the standard SLP
 
discover local DAs, implementations MUST use the standard SLP
mechanisms per RFC 2608.  In addition, implementations supporting
+
mechanisms per [[RFC2608|RFC 2608]].  In addition, implementations supporting
 
this specification MAY use DNS SRV to discover local DAs in the
 
this specification MAY use DNS SRV to discover local DAs in the
 
"default" scope.
 
"default" scope.
Line 213: Line 213:
 
     Service Field      Protocol Field    Reference
 
     Service Field      Protocol Field    Reference
 
     -------------      --------------    ---------
 
     -------------      --------------    ---------
         slpda                tcp          [RFC3832]
+
         slpda                tcp          [[RFC3832]]
         slpda                udp          [RFC3832]
+
         slpda                udp          [[RFC3832]]
  
 
== Acknowledgments ==
 
== Acknowledgments ==
Line 224: Line 224:
 
== Normative References ==
 
== Normative References ==
  
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+
[[RFC2608]] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
           Location Protocol, Version 2 ", RFC 2608, June 1999.
+
           Location Protocol, Version 2 ", [[RFC2608|RFC 2608]], June 1999.
  
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+
[[RFC2782]] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
           specifying the location of services (DNS SRV)", RFC 2782,
+
           specifying the location of services (DNS SRV)", [[RFC2782|RFC 2782]],
 
           February 2000.
 
           February 2000.
  
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+
[[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.
+
           Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
  
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+
[[RFC1034]] Mockapetris, P., "Domain names - concepts and facilities",
           STD 13, RFC 1034, November 1987.
+
           [[STD13|STD 13]], [[RFC1034|RFC 1034]], November 1987.
  
[RFC1035] Mockapetris, P., "Domain names - implementation and
+
[[RFC1035]] Mockapetris, P., "Domain names - implementation and
           specification", STD 13, RFC 1035, November 1987.
+
           specification", [[STD13|STD 13]], [[RFC1035|RFC 1035]], November 1987.
  
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
+
[[RFC2535]] Eastlake 3rd, D., "Domain Name System Security Extensions",
           RFC 2535, March 1999.
+
           [[RFC2535|RFC 2535]], March 1999.
  
 
10.  Authors' Addresses
 
10.  Authors' Addresses
Line 289: Line 289:
  
 
Copyright (C) The Internet Society (2004).  This document is subject
 
Copyright (C) The Internet Society (2004).  This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
+
to the rights, licenses and restrictions contained in [[BCP78|BCP 78]], and
 
except as set forth therein, the authors retain all their rights.
 
except as set forth therein, the authors retain all their rights.
  
Line 309: Line 309:
 
made any independent effort to identify any such rights.  Information
 
made any independent effort to identify any such rights.  Information
 
on the procedures with respect to rights in RFC documents can be
 
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
+
found in [[BCP78|BCP 78]] and [[BCP79|BCP 79]].
  
 
Copies of IPR disclosures made to the IETF Secretariat and any
 
Copies of IPR disclosures made to the IETF Secretariat and any
Line 328: Line 328:
 
Funding for the RFC Editor function is currently provided by the
 
Funding for the RFC Editor function is currently provided by the
 
Internet Society.
 
Internet Society.
 +
 +
[[Category:Experimental]]

Latest revision as of 09:44, 4 October 2020

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.

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 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.

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.

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.

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

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.

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.

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.

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.

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.

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 [[[RFC2535|RFC 2535]]] SHOULD be used to provide origin authentication and integrity protection for DNS data.

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.

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

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.

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.

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: [email protected]

Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003

EMail: [email protected]

Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany

EMail: [email protected]

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: [email protected]

William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA

EMail: [email protected]

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- [email protected].

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.