< draft-moats-finding-00.txt		draft-moats-finding-01.txt >
	Internet-Draft Ryan Moats		Internet-Draft Ryan Moats
	draft-moats-finding-00.txt AT&T		draft-moats-finding-01.txt AT&T
	Expires in six months September 1997		Expires in six months September 1997
	How to find LDAP servers		How to find LDAP Servers
	Filename: draft-moats-finding-00.txt		Filename: draft-moats-finding-01.txt
	Status of This Memo		Status of This Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its		documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Abstract		Abstract
	This document discusses methods available for LDAP server discovery		This document discusses methods available for LDAP server discovery
	and advertisement based on previous IETF and ongoing IETF work.		and advertisement based on previous IETF and ongoing IETF work.
	1. Introduction		1. Introduction
	The Lightweight Directory Access Protocol (LDAP) [1] can be used to		The Lightweight Directory Access Protocol (LDAP) [1] can be used to
	build "islands" of servers that are not a priori tied into a single		build "islands" of servers that are not a priori tied into a single
	Directory Information Tree (DIT). In this case, it is necessary to		Directory Information Tree (DIT.) Here, it is necessary to determine
	determine how a client can discover an LDAP server and how LDAP		how a client can discover LDAP servers and how LDAP servers can
	servers can discover each other's existence. This documents discusses		discover each other's existence. This documents discusses the methods
	the methods available based on current and previous IETF work.		available based on current and previous IETF work.
	2. Server Discovery of Other Servers		2. Server Discovery of Other Servers
	A LDAP server discovers other LDAP servers by either using a proposed		An LDAP server discovers other LDAP servers by either using a
	naming scheme and the DNS or by using a additional server to server		proposed naming scheme and the DNS or by using an additional server
	indexing protocol. Once a server discovers other servers it can		to server indexing protocol. Once a server discovers other servers
	collect information for returning LDAP v3 referrals to clients.		it can collect information for returning LDAP v3 referrals (as LDAP
			URLs) to clients.
	2.1. Discovery via DNS		2.1. Discovery via DNS
	An LDAP server may either be registered using SRV records [2] or, if		An LDAP server may either be registered using SRV records [2] or, if
	an LDAP server uses the "dc-naming" scheme [3], it can attempt to		the server uses the "dc-naming" scheme ([3, 4]), it can attempt to
	find the server managing its parent node by using DNS to look for the		find the server managing its parent node by using DNS to look for the
	LDAP server for the parent domain. Additionally, an LDAP server may		LDAP server for the parent domain. Additionally, an LDAP server may
	be named using a common alias as described in [4]. As an example, a		be named using a common alias as described in [5]. In either case,
	server in domain foo.bar.com would first look for a SRV record for		it is necessary to include information about the root of the LDAP
	ldap.tcp.foo.bar.com, then for a SRV record for ldap.tcp.bar.com. If		server's subtree by using DNS TXT records as discussed in [6].
	no SRV records were found, then the server would follow [4] by
	looking for ldap.foo.bar.com and lastly, for ldap.bar.com.
	2.2. Discovery via the Common Indexing Protocol [5], [6]		As an example, consider a server with the RDN "dc=foo,dc=bar,dc=com"
			(i.e. in domain foo.bar.com). To find its parent server, it would
			first look for a SRV record for ldap.tcp.bar.com and then follow [5]
			by looking for ldap.bar.com. If any of these records were found, it
			would then look for a TXT record for the same domain to determine the
			root of its parent server's sub-tree.
	Independent of what DIT we are managing, LDAP servers could export		2.2. Discovery via the Common Indexing Protocol [7, 8]
			Independent of what DIT is being managed, LDAP servers could export
	index information about their portion of the tree via the Common		index information about their portion of the tree via the Common
	Indexing Protocol. This requires some a priori discovery and set up		Indexing Protocol. This requires some a priori discovery and set up
	of the index mesh.		of the index mesh and the inclusion of the root DN of the server's
			portion of the tree in the exported index information.
	3. Client Discovery of LDAP Servers		3. Client Discovery of LDAP Servers
	To discover an LDAP server, clients should follow the sequence of		To discover LDAP servers, clients should follow the sequence of steps
	steps specified in [7] with the target service being LDAP.		specified in [9] (which uses DNS and the service location protocol)
	Alternatively, a client that supports DHCP may use the DHCP extension		with the target service being LDAP. If a DNS record is found for a
	for LDAP server location as specified in [8].		name that begins with ldap (i.e. ldap.tcp.foo.com or ldap.foo.com) a
			further DNS lookup for a TXT record under that name would return the
			root of that server's subtree. If a client supports DHCP, it may
			use the DHCP extension specified in [10] to locate LDAP servers.
			Alternatively, LDAP clients may have a list of preconfigured LDAP
			servers included with them that a user can select from. Here, some
			of the servers in the preconfigured list might provide the
			functionality described in this document, to allow for simpler
			clients.
	4. Security Considerations		4. Security Considerations
	Since this draft only summarizes available methods, it adds no		Since this draft only summarizes available methods, it adds no
	additional security considerations to those inherent in the		additional security considerations to those inherent in the
	referenced documents. Implementors are strongly recommended to read		referenced documents. Implementors are strongly recommended to read
	and follow the security considerations provided in the referenced		and follow the security considerations provided in the referenced
	documents.		documents.
	5. Acknowledgments		5. Acknowledgments
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 33 ¶
	available from <URL:ftp://ftp.internic.net> and numerous mirror		available from <URL:ftp://ftp.internic.net> and numerous mirror
	sites.		sites.
	[1] W. Yeong, T. Howes, S. Kille, "Lightweight Direc-		[1] W. Yeong, T. Howes, S. Kille, "Lightweight Direc-
	tory Access Protocol," RFC 1777, March 1995.		tory Access Protocol," RFC 1777, March 1995.
	[2] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying		[2] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying
	the location of services (DNS SRV)," RFC 2052,		the location of services (DNS SRV)," RFC 2052,
	October 1996.		October 1996.
	[3] S. Kille, S. Sataluri, A. Grimstad, "Naming Plan		[3] A. Grimstad et al., "Naming Plan for an Internet
	for an Internet Directory Service," Work In Pro-		Directory Service," Internet Draft (work in pro-
	gress, March 19, 1997.		gress), March 19, 1997.
	[4] M. Hamilton, R. Wright, "Use of DNS Aliases for		[4] S. Kille et al., "Using Domains in LDAP Dis-
	Network Services," Work In Progress, August, 1997.		tinguished Names," Internet Draft (work in pro-
			gress), August 1997.
	[5] M. Mealling, J. Allen, "MIME Object Definitions for		[5] M. Hamilton, R. Wright, "Use of DNS Aliases for
	the Common Indexing Protocol(CIP)," Work In Pro-		Network Services," Internet Draft (work in pro-
	gress, June 11, 1997.		gress), August, 1997.
	[6] M. Mealling, J. Allen, "The Architecture of the		[6] R. Moats, M. Hamilton, "Advertising Services,"
	Common Indexing Protocol (CIP),"Work In Progress,		Internet Draft (work in progress), June 1997.
	June 11, 1997.
	[7] R. Moats, M. Hamilton, P. Leach, "Finding Stuff		[7] M. Mealling, J. Allen, "MIME Object Definitions for
			the Common Indexing Protocol(CIP)," Internet Draft
			(work in progress), June 11, 1997.
			[8] M. Mealling, J. Allen, "The Architecture of the
			Common Indexing Protocol (CIP)," Internet Draft
			(work in progress), June 11, 1997.
			[9] R. Moats, M. Hamilton, P. Leach, "Finding Stuff
	(How to discover services)," Internet Draft (work		(How to discover services)," Internet Draft (work
	in progress), June 1997.		in progress), June 1997.
	[8] L. Hedstrom, L. Howard, "DHCP Options for Locating		[10] L. Hedstrom, L. Howard, "DHCP Options for Locating
	LDAP Servers", Internet Draft (work in progress),		LDAP Servers," Internet Draft (work in progress),
	July 1997		July 1997
	7. Author's address		7. Author's address
	Ryan Moats		Ryan Moats
	AT&T		AT&T
	15621 Drexel Circle		15621 Drexel Circle
	Omaha, NE 68135-2358		Omaha, NE 68135-2358
	USA		USA
End of changes. 16 change blocks.
	38 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/