idnits 2.17.1 draft-ietf-ldapext-ldap-taxonomy-05.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 Internet-Drafts being working documents. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (July 2001) is 8292 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2251 (ref. '1') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Downref: Normative reference to an Informational RFC: RFC 2377 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Experimental RFC: RFC 2654 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2052 (ref. '12') (Obsoleted by RFC 2782) -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Ryan Moats 2 draft-ietf-ldapext-ldap-taxonomy-05 Lemur Networks 3 Expires in six months Roland Hedberg 4 Track: Informational Catalogix 5 July 2001 7 A Taxonomy of Methods for LDAP Clients Finding Servers 8 Filename: draft-ietf-ldapext-ldap-taxonomy-05.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 There are several different methods for a LDAP client to find a LDAP 32 server. This draft discusses these methods and provides pointers for 33 interested parties to learn more about implementing a particular 34 method. 36 1. Introduction 38 The Lightweight Directory Access Protocol (LDAP) [1] can be used to 39 build "islands" of servers that are not a priori tied into a single 40 Directory Information Tree (DIT.) Here, it is necessary to determine 41 how a client can discover LDAP servers. This documents discusses the 42 currently available methods and provides pointers for interested 43 parties to learn more about implementing a particular method. 45 This draft documents only those methods that are currently being 46 pursued in the IETF. Other methods have been considered for this 47 problem and the history of these other methods are presented in the 48 Appendix. 50 2. Methods 52 2.1 Client Configuration 54 The simplest method of enabling a LDAP client to discover LDAP 55 servers is for the client administrator to configure the client with 56 a list of known LDAP servers (and associated base objects) to send 57 queries to. While this method has the advantage of being correct 58 (initially), it adds the requirement that the list of initial servers 59 be kept small and constant. Otherwise, the required client update 60 process won't scale. 62 2.2 Well known DNS aliases 64 If the DIT uses a naming scheme similar to that in RFC 2377 [2], then 65 it is possible to build the DNS names of potential servers using well 66 known DNS aliases, like those documented in RFC 2219 [3]. When a 67 different naming scheme is used, it is also possible to build 68 potential server names based on the client's fully qualified domain 69 name or local (within the organization or country) environment. 71 One shortcoming of this method are that it is not exact. Multiple 72 DNS lookups and LDAP protocol operations may be necessary to find the 73 proper LDAP server to serve the client requests. To support client 74 roaming, it is necessary that either the RFC 2377 (or similar) naming 75 scheme be used or that roaming be implemented through tunnels. 77 Because this method uses DNS, it inherits all the security 78 considerations of using DNS to discover LDAP servers: see the 79 security consideration in [3] for more details. 81 2.3 Service Location Protocol 83 If a client supports the service location protocol [4], it could use 84 a SLP query for LDAP servers. The SLP template that is used to 85 describe LDAP servers is presented in [5], and requires that the 86 servers announce themselves using SLP and this template. 88 Using this method inherits the scaling and security considerations 89 for the service location protocol, which are documented further in 90 [4]. 92 2.4 Referrals 94 In LDAPv3, servers can return referrals to the client if the server 95 has knowledge of where a query might be satisfiable. Two ways of 96 deploying referral information are deploying a LDAP knowledge server 97 or exchanging CIP index objects [6] between servers. 99 A LDAP knowledge server would hold cross references to possibly 100 hundreds of other LDAP servers, so that a client would only need to 101 know about its local LDAP server and the knowledge server. As an 102 optimization, the local LDAP server could also act as a knowledge 103 server. 105 If CIP index objects are exchanged between LDAP servers, then those 106 objects can also carry URL information for providing referrals to 107 clients. Here, the client would only need to know about the local 108 server. Using CIP index objects inherits the security considerations 109 of CIP: see [6, 7, 8] for more details. 111 In either of these cases, the local LDAP server could be determined 112 using another of the methods discussed. 114 2.5 Using SRV records 116 RFC 2052 [12] defined SRV records for DNS, which bound a host name 117 and port to a label in the DNS. This makes it possible for a client 118 to look up information about a supported protocol for a domain and 119 get back a weighted list of fully qualified domain names and ports 120 for where that protocol is supported. For more information, see 121 [13]. 123 3. Implementation 125 The Norwegian Directory Forum plans to start a service based on a 126 central LDAP service containing contact information for every 127 organization within Norway [10]. If an organization has more 128 information about its sub-units, employees or functions that it wants 129 to publish it can do so by placing this information in a publicly 130 available LDAP server and providing the management of the central 131 service with a pointer (URL) to this server. 133 The TISDAG project is running a test service based on the TISDAG 134 specification [11]. This service gathers indices from connected White 135 Pages Service Providers using CIP Tagged Index Objects [9]. The 136 rationale for this service is that by supplying the name of a person 137 or a function/role to the service it will return pointers to where 138 more information can be found about persons/functions with that name. 140 The European cofunded project DESIRE (www.desire.org) is designing a 141 system to use a LDAP server that communicates with a referral index 142 that in turn, uses CIP Tagged Index Objects [9] and is fed by LDAP 143 crawlers. DANTE plans to set up a European infrastructure of such 144 referral index servers. 146 4. References 148 Request For Comments (RFC) and Internet Draft documents are available 149 from numerous mirror sites. 151 [1] M. Wahl, T. Howes, S. Kille, Lightweight Directory Access 152 Protocol (v3), RFC 2251, December 1997. 154 [2] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, Naming Plan for 155 Internet Directory-Enabled Applications, RFC 2377, September 156 1998. 158 [3] M. Hamilton, R. Wright, "Use of DNS Aliases for Network Ser- 159 vices," RFC 2219 (Also BCP 17), October 1997. 161 [4] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Loca- 162 tion Protocol, Version 2," RFC 2608, June 1999. 164 [5] J. Wood, R. Tam, "The LDAP Service Type," SVRLOC Template 165 http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/ 166 naming-directory_ldap.1.0.en 168 [6] J. Allen, M. Mealling, "The Architecture of the Common 169 Indexing Protocol (CIP)," RFC 2651, August 1999. 171 [7] J. Allen, M. Mealling, "MIME Object Definitions for the Com- 172 mon Indexing Protocol (CIP)," RFC 2652, August 1999. 174 [8] J. Allen, P. Leach, R. Hedberg, "CIP Transport Protocols," 175 RFC 2653, August 1999. 177 [9] R. Hedberg, B. Greenblatt, R. Moats, M. Wahl, "A Tagged 178 Index Object for use in the Common Indexing Protocol," RFC 179 2654, August 1999. 181 [10] R. Hedberg, H. Alverstrand, "Technical Specification, The 182 Norwegian Directory of Directories (NDD)," http:// 183 www.catalogix.se/doc/draft-hedberg-alvestrad-ndd-01.txt 185 [11] R. Hedberg, L. Daigle, "Technical Infrastructure for Swedish 186 Directory Access Gateways (TISDAG)," Internet Draft (work in 187 progress), February 2000. 189 [12] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the loca- 190 tion of services (DNS SRV)," RFC 2052, October 1996. 192 [13] M. Armijo, L. Esibov, P. Leach, "Discovering LDAP Services 193 with DNS," Internet Draft (work in progress), July 1999. 195 5. Author's Addresses 197 Ryan Moats Roland Hedberg 198 Lemur Networks Catalogix 199 15621 Drexel Circle Dalsveien 53 200 Omaha, NE 68135 0775 Oslo 201 USA Norway 202 Email: rmoats@lemurnetworks.net Email: roland@catalogix.se 204 Appendix A. Historical Methods 206 A.1 Discovery 208 The discovery approach was to use a combination of other methods pre- 209 sented in this taxonomy along with storing either the search DN or a 210 related URL in the DNS in some way. Using both TXT or NAPTR records 211 in the DNS were considered. This approach requires an administrator 212 to configure the DNS with necessary information. Further, the idea 213 of storing standards based information (either a DN or an URL) in a 214 DNS RR has been an extremely controversial one in the IETF. 216 A.2 DHCP extensions 218 Another proposed method was to use DHCP to deliver information about 219 LDAP server to a DHCP client. This would require that such informa- 220 tion be configured into the DHCP server and that the client use DHCP 221 to load host configuration information. While there has been some 222 nascent interest in this method, there has been no interest in imple- 223 mentation of this approach.