idnits 2.17.1 draft-zhao-slp-remote-da-discovery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in '[Target Category: Experimental]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2535' is mentioned on line 194, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFCxxxx' is mentioned on line 229, but not defined == Unused Reference: 'RFC2535' is defined on line 257, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NUMBERS' -- Duplicate reference: RFC1034, mentioned in 'RFC1035', was also mentioned in 'RFC1034'. ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT W. Zhao 3 draft-zhao-slp-remote-da-discovery-06.txt H. Schulzrinne 4 [Target Category: Experimental] Columbia University 5 March 23, 2004 E. Guttman 6 Expires: September 23, 2004 Sun Microsystems 7 C. Bisdikian 8 W. Jerome 9 IBM 11 Remote Service Discovery in the Service Location Protocol via DNS SRV 13 Status of This Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Remote service discovery refers to discovering desired services in 41 given remote (i.e., non-local) DNS domains. This document describes 42 remote service discovery in the Service Location Protocol (SLP) via 43 DNS SRV. It defines the DNS SRV Resource Records for SLP Directory 44 Agent services, discusses various issues in using SLP and DNS SRV 45 together for remote service discovery, and gives the steps for 46 discovering desired services in remote DNS domains. 48 1. Introduction 50 This document describes remote service discovery in the Service 51 Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782]. We consider 52 remote service discovery as discovering desired services in given 53 remote DNS domains, and local service discovery as discovering 54 desired services within the local administrative domain. 56 SLP provides a scalable framework for local service discovery and 57 selection. In SLP, User Agents (UAs) discover desired services in the 58 local administrative domain by querying all Service Agents (SAs) via 59 multicast or querying a Directory Agent (DA) via unicast. To query a 60 DA using unicast, a UA needs to first learn about the DA via DHCP, 61 static configuration or multicast (listening for DAAdvert multicast 62 or issuing DA discovery SrvRqst multicast). 64 DNS SRV provides a good support for remote service discovery. 65 However, if multiple servers are discovered via DNS SRV for a 66 service, only priority and weight can be used to make a selection. If 67 additional service properties (such as cost, speed and service 68 quality) need to be considered in the selection process, DNS SRV 69 becomes insufficient. 71 We propose that using SLP and DNS SRV together can provide a better 72 support for remote service discovery. First, a UA uses DNS SRV to 73 find SLP DAs at a remote DNS domain. Then, the UA queries one of 74 those DAs to discover desired services. In this way, we can avoid the 75 limitations in using SLP and DNS SRV separately. On one hand, without 76 DNS SRV, an SLP UA needs to depend on static configuration to learn 77 about remote DAs because DHCP and multicast DA discovery are not 78 generally applicable beyond the local administrative domain. On the 79 other hand, without SLP, DNS SRV has limited support for service 80 selection. 82 In this document, we first define the DNS SRV Resource Records (RRs) 83 for SLP DA services, which are used to map a given DNS domain to 84 remotely accessible (i.e., accessible from the Internet) DAs in that 85 domain. Then, we discuss various issues in using SLP and DNS SRV 86 together for remote service discovery. Finally, we give the steps for 87 discovering desired services in remote DNS domains. 89 1.1. Notation Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in BCP 14, RFC 2119 94 [RFC2119]. 96 2. The DNS SRV RRs for SLP DA services 98 According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services 99 are defined as follows: 101 _slpda._Proto.Name TTL Class SRV Priority Weight Port Target 103 where "slpda" is the symbolic name for SLP DA services in Assigned 104 Numbers [NUMBERS], the Proto field is either "tcp" or "udp", and the 105 Target field is the domain name of an SLP DA. Please refer to 106 [RFC2782] for detailed explanation of each field in DNS SRV RRs. 108 Next we show an example of using DNS SRV RRs to map a given DNS 109 domain to remotely accessible DAs in that domain. To discover 110 remotely accessible DAs in a remote domain (say, example.com), a UA 111 makes a DNS query [RFC1034,RFC1035] for QNAME=_slpda._tcp.example.com 112 (or QNAME=_slpda._udp.example.com), QCLASS=IN, and QTYPE=SRV. Then 113 the UA will receive a list of DNS SRV RRs in a DNS reply, which gives 114 all remotely accessible DAs in the domain example.com, such as: 116 ;; Priority Weight Port Target 117 _slpda._tcp.example.com IN SRV 0 0 427 da1.example.com 118 _slpda._tcp.example.com IN SRV 0 0 427 da2.example.com 120 3. Remote Service Discovery in SLP via DNS SRV 122 SLP DAs can be discovered in two ways: (1) using the mechanisms 123 described in RFC 2608, and (2) using DNS SRV RRs as described in this 124 document. The second approach is useful for UAs to acquire service 125 information for remote DNS domains. For example, a mobile node 126 visiting a network (without the use of mobile IP) may want to obtain 127 information about services in its home network. 129 3.1. The DNS Domain of Interest for Remote Service Discovery 131 Using DNS SRV RRs to discover SLP DAs requires knowledge of the 132 domain where SLP DAs are registered. For remote service discovery, we 133 assume that the DNS domain of interest is known via a priori 134 knowledge. For example, a UA is configured with a domain name or the 135 user provides the domain name manually. 137 Note that there is no implied "search order" of DNS domains in 138 finding remote DAs. For instance, if a UA is looking for remote DAs 139 in the domain foo.bar.example.com, it SHOULD only look for 140 _slp._tcp.foo.bar.example.com (or _slp._udp.foo.bar.example.com), and 141 MUST NOT fall back to look for _slp._tcp.bar.example.com, 142 _slp._tcp.example.com, and so on. 144 3.2. SLP DAs for Remote Service Discovery 146 A UA discovers desired services in a given remote DNS domain by 147 unicasting requests to DAs in that domain. The UA uses remote DAs 148 according to these prioritized rules: (1) using DAs which it has been 149 configured with, and (2) using DAs which it has discovered via DNS 150 SRV. 152 3.3. SLP Scopes for Remote Service Discovery 154 As SLP scopes are intended to be used only within one administrative 155 domain, they are likely incomprehensible to users outside of the 156 administrative domain. Thus, any remotely accessible service MUST be 157 registered in the "default" scope, but it MAY be registered in other 158 scopes at the same time. Similarly, all DAs advertised via DNS SRV 159 MUST serve the "default" scope, but they MAY serve other scopes at 160 the same time. As a result, users wishing to discover services at a 161 remote DNS domain SHOULD only search the "default" scope. 163 4. Steps for Remote Service Discovery 165 The steps for a User Agent U to discover desired services in a remote 166 DNS domain D are as follows. 168 (1) U makes a DNS query for QNAME=_slpda._tcp.D (or 169 QNAME=_slpda._udp.D), QCLASS=IN, and QTYPE=SRV. Then U gets a 170 list of DNS SRV RRs (referred to as L) in a DNS reply, which 171 gives all remotely accessible DAs in D. 173 (2) U selects a DA X from L based on the priority and weight 174 information per RFC 2782. 176 (3) U queries X in the "default" scope to discover desired services 177 in D. 179 Note that the services discovered in the above steps may not 180 necessarily be remotely accessible. 182 5. Security Considerations 184 To support remote service discovery, a domain exposes its service 185 information to the Internet. Standard SLP authentication SHOULD be 186 used to protect valuable service information. First, there is a risk 187 that any SA could advertise any service on a DA accessible from the 188 Internet. Such a DA SHOULD reject all registrations and 189 deregistrations that cannot be authenticated. Secondly, to avoid 190 disclosing unintended service information to remote users, a DA 191 accessible from the Internet SHOULD at least authenticate service 192 queries that are not in the "default" scope. In addition, the 193 security considerations for DNS SRV [RFC2782] apply to this document. 194 Also, the DNS security extensions [RFC 2535] SHOULD be used to 195 provide origin authentication and integrity protection for DNS data. 197 6. Applicability Statements 199 This specification describes remote service discovery in SLP via DNS 200 SRV. It facilitates discovering services at a remote DNS domain if 201 the domain name is known via a priori knowledge. However, it does not 202 intend to solve the problem of Internet-wide service discovery. 204 Users should be aware of two constraints in using DNS SRV to discover 205 SLP DAs: (1) they SHOULD only use DNS SRV to discover DAs in the 206 "default" scope, and (2) an administrator may choose to only register 207 a subset of all DAs in the "default" scope via DNS SRV. Thus, to 208 discover local DAs, implementations MUST use the standard SLP 209 mechanisms per RFC 2608. In addition, implementations supporting this 210 specification MAY use DNS SRV to discover local DAs in the "default" 211 scope. 213 As SLP scopes are not intended to be used outside the local 214 administrative domain, all remote service discovery in SLP SHOULD be 215 carried only in the "default" scope. 217 Notice that the services discovered via DNS SRV and remote SLP DAs 218 may not necessarily be remotely accessible. 220 7. IANA Considerations 222 In the DNS SRV RRs for SLP DA services, the symbolic name for the 223 Service field is "slpda", supported protocols are "tcp" and "udp". 224 The following values are to be registered with IANA: 226 Service Field Protocol Field Reference 227 ------------- -------------- --------- 228 slpda tcp [RFCxxxx] 229 slpda udp [RFCxxxx] 231 8. Acknowledgments 233 The authors would like to thank Bernard Aboba, Kevin Arnold, Steven 234 Bellovin, Ted Hardie, James Kempf, Thomas Narten, Erik Nordmark and 235 Jon Peterson for their valuable comments. 237 9. Normative References 239 [RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service 240 Location Protocol, Version 2", RFC 2608, June 1999. 242 [RFC2782] A. Gulbrandsen, P. Vixie and L. Esibov, "A DNS RR for 243 specifying the location of services (DNS SRV)", RFC 2782, 244 February 2000. 246 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [NUMBERS] http://www.iana.org/assignments/port-numbers 251 [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities", 252 STD 13, RFC 1034, November 1987. 254 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 255 Specification", STD 13, RFC 1034, November 1987. 257 [RFC2535] D. Eastlake, "Domain Name System Security Extensions", 258 RFC 2535, March 1999. 260 10. Authors' Addresses 262 Weibin Zhao 263 Department of Computer Science 264 Columbia University 265 1214 Amsterdam Avenue, MC 0401 266 New York, NY 10027-7003 268 EMail: zwb@cs.columbia.edu 270 Henning Schulzrinne 272 Department of Computer Science 273 Columbia University 274 1214 Amsterdam Avenue, MC 0401 275 New York, NY 10027-7003 277 EMail: hgs@cs.columbia.edu 279 Erik Guttman 280 Sun Microsystems 281 Eichhoelzelstr. 7 282 74915 Waibstadt 283 Germany 285 EMail: Erik.Guttman@sun.com 286 Chatschik Bisdikian 287 IBM Corp. 288 Thomas J. Watson Research Center 289 19 Skyline Drive 290 Hawthorne, NY 10532, USA 292 EMail: bisdik@us.ibm.com 294 William F. Jerome 295 IBM Corp. 296 Thomas J. Watson Research Center 297 19 Skyline Drive 298 Hawthorne, NY 10532, USA 300 EMail: wfj@us.ibm.com 302 11. Full Copyright Statement 304 Copyright (C) The Internet Society (2004). All Rights Reserved. 306 This document and translations of it may be copied and furnished to 307 others, and derivative works that comment on or otherwise explain it 308 or assist in its implementation may be prepared, copied, published 309 and distributed, in whole or in part, without restriction of any 310 kind, provided that the above copyright notice and this paragraph are 311 included on all such copies and derivative works. However, this 312 document itself may not be modified in any way, such as by removing 313 the copyright notice or references to the Internet Society or other 314 Internet organizations, except as needed for the purpose of 315 developing Internet standards in which case the procedures for 316 copyrights defined in the Internet Standards process must be 317 followed, or as required to translate it into languages other than 318 English. 320 The limited permissions granted above are perpetual and will not be 321 revoked by the Internet Society or its successors or assigns. 323 This document and the information contained herein is provided on an 324 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 325 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 326 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 327 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 328 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.