7 Network Working Group A. Young
8 Request for Comments: 1798 ISODE Consortium
9 Category: Standards Track June 1995
12 Connection-less Lightweight Directory Access Protocol
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 The protocol described in this document is designed to provide access
25 to the Directory while not incurring the resource requirements of the
26 Directory Access Protocol (DAP) [3]. In particular, it is aimed at
27 avoiding the elapsed time that is associated with connection-oriented
28 communication and it facilitates use of the Directory in a manner
29 analagous to the DNS [5,6]. It is specifically targeted at simple
30 lookup applications that require to read a small number of attribute
31 values from a single entry. It is intended to be a complement to DAP
32 and LDAP [4]. The protocol specification draws heavily on that of
37 The Directory can be used as a repository for many kinds of
38 information. The full power of DAP is unnecessary for applications
39 that require simple read access to a few attribute values.
40 Applications addressing is a good example of this type of use where
41 an application entity needs to determine the Presentation Address
42 (PA) of a peer entity given that peer's Application Entity Title
43 (AET). If the AET is a Directory Name (DN) then the required result
44 can be obtained from the PA attribute of the Directory entry
45 identified by the AET. This is very similar to DNS.
58 Young Standards Track [Page 1]
60 RFC 1798 CLDAP June 1995
63 Use of DAP to achieve this functionality involves a significant
64 number of network exchanges:
66 ___________________________________________________________
67 |_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
68 | 1| N-Connect.request -> |
69 | 2| <- N-Connect.response |
70 | 3| T-Connect.request -> |
71 | 4| <- T-Connect.response |
72 | | S-Connect.request, |
73 | | P-Connect.request, |
74 | | A-Associate.request, |
75 | 5| DAP-Bind.request -> |
76 | | S-Connect.response, |
77 | | P-Connect.response, |
78 | | A-Associate.response, |
79 | 6| <- DAP-Bind.response |
80 | 7| DAP-Read.request -> |
81 | 8| <- DAP-Read.response |
82 | | S-Release.request, |
83 | | P-Release.request, |
84 | | A-Release.request, |
85 | 9| DAP-Unbind.request -> |
86 | | S-Release.response, |
87 | | P-Release.response, |
88 | | A-Release.response, |
89 | 10| <- DAP-Unbind.response |
90 | | T-Disconnect.request, |
91 | 11| N-Disconnect.request -> |
92 | | T-Disconnect.response,|
93 | 12| <- N-Disconnect.response |
94 |___|______________________________________________________|
114 Young Standards Track [Page 2]
116 RFC 1798 CLDAP June 1995
119 This is 10 packets before the application can continue, given that it
120 can probably do so after issuing the T-Disconnect.request. (Some
121 minor variations arise depending upon the class of Network and
122 Transport service that is being used; for example use of TP4 over
123 CLNS reduces the packet count by two.) LDAP is no better in the case
124 where the LDAP server uses full DAP to communicate with the
127 ____________________________________________________________________
128 |__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______|
130 | 2 | <- TCP SYN ACK |
132 | 4 | N-Connect.req -> |
133 | 5 | <- N-Connect.res |
134 | 6 | T-Connect.req -> |
135 | 7 | <- T-Connect.res |
136 | 8 | DAP-Bind.req -> |
137 | 9 | <- DAP-Bind.res |
139 | 11 | SearchReq -> |
140 | 12 | DAP-Search.req -> |
141 | 13 | <- DAP-Search.res |
142 | 14 | <- SearchRes |
144 | 16 | DAP-Unbind.req -> |
145 | 17 | <- DAP-Unbind.res |
146 | 18 | N-Disconnect.req -> |
147 | 19 | <- N-Disconnect.res|
148 |____|______________________________________________________________|
170 Young Standards Track [Page 3]
172 RFC 1798 CLDAP June 1995
175 Here there are 14 packets before the application can continue. Even
176 if the LDAP server is on the same host as the DSA (so packet delay is
177 negligible), or if the DSA supports LDAP directly, then there are
180 ____________________________________
181 | #| Client LDAP LDAP server|
182 |__|________________________________|
188 |_6|_______________<-____SearchRes__|
191 This protocol provides for simple access to the Directory where the
192 delays inherent in the above exchanges are unacceptable and where the
193 additional functionality provided by connection-mode operation is not
198 CLDAP is based directly on LDAP [4] and inherits many of the key
199 aspects of the LDAP protocol:
201 - - Many protocol data elements are encoding as ordinary strings
202 (e.g., Distinguished Names).
204 - - A lightweight BER encoding is used to encode all protocol
207 It is different to LDAP in that:
209 - - Protocol elements are carried directly over UDP or other
210 connection-less transport, bypassing much of the
211 session/presentation overhead and that of connections (LDAP uses
212 a connection-mode transport service).
214 - - A restricted set of operations is available.
216 The definitions of most protocol elements are inherited from LDAP.
218 The general model adopted by this protocol is one of clients
219 performing protocol operations against servers. In this model, this
220 is accomplished by a client transmitting a protocol request
221 describing the operation to be performed to a server, which is then
222 responsible for performing the necessary operations on the Directory.
226 Young Standards Track [Page 4]
228 RFC 1798 CLDAP June 1995
231 Upon completion of the necessary operations, the server returns a
232 response containing any results or errors to the requesting client.
234 Note that, although servers are required to return responses whenever
235 such responses are defined in the protocol, there is no requirement
236 for synchronous behaviour on the part of either client or server
237 implementations: requests and responses for multiple operations may
238 be exchanged by client and servers in any order, as long as servers
239 eventually send a response for every request that requires one.
241 Also, because the protocol is implemented over a connection-less
242 transport service clients must be prepared for either requests or
243 responses to be lost. Clients should use a retry mechanism with
244 timeouts in order to achieve the desired level of reliability. For
245 example, a client might send off a request and wait for two seconds.
246 If no reply is forthcoming, the request is sent again and the client
247 waits four seconds. If there is still no reply, the client sends it
248 again and waits eight seconds, and so on, until some maximun time.
249 Such algorithms are widely used in other datagram-based protocol
250 implementations, such as the DNS. It is not appropriate to mandate a
251 specific algorithm as this will depend upon the requirments and
252 operational environment of individual CLDAP client implementations.
254 It is not required that a client abandon any requests to which no
255 response has been received and for which a reply is no longer
256 required (because the request has been timed out), but they may do
259 Consistent with the model of servers performing protocol operations
260 on behalf of clients, it is also to be noted that protocol servers
261 are expected to handle referrals without resorting to the return of
262 such referrals to the client. This protocol makes no provisions for
263 the return of referrals to clients, as the model is one of servers
264 ensuring the performance of all necessary operations in the
265 Directory, with only final results or errors being returned by
268 Note that this protocol can be mapped to a strict subset of the
269 Directory abstract service, so it can be cleanly provided by the DAP.
271 3. Mapping Onto Transport Services
273 This protocol is designed to run over connection-less transports,
274 with all 8 bits in an octet being significant in the data stream.
275 Specifications for two underlying services are defined here, though
276 others are also possible.
282 Young Standards Track [Page 5]
284 RFC 1798 CLDAP June 1995
287 3.1. User Datagram Protocol (UDP)
289 The CLDAPMessage PDUs are mapped directly onto UDP datagrams. Only
290 one request may be sent in a single datagram. Only one response may
291 be sent in a single datagram. Server implementations running over
292 the UDP should provide a protocol listener on port 389.
294 3.2. Connection-less Transport Service (CLTS)
296 Each LDAPMessage PDU is mapped directly onto T-Unit-Data.
298 4. Elements of Protocol
300 CLDAP messages are defined by the following ASN.1:
302 CLDAPMessage ::= SEQUENCE {
304 user LDAPDN, -- on request only --
306 searchRequest SearchRequest,
307 searchResponse SEQUENCE OF
309 abandonRequest AbandonRequest
313 where MessageID, LDAPDN, SearchRequest, SearchResponse and
314 AbandonRequest are defined in the LDAP protocol.
316 The 'user' element is supplied only on requests (it should be zero
317 length and is ignored in responses). It may be used for logging
318 purposes but it is not required that a CLDAP server implementation
319 apply any particular semantics to this field.
322 There has been some discussion about the desirability of
323 authentication with CLDAP requests and the addition of the fields
324 necessary to support this. This might take the form of a clear
325 text password (which would go against the current IAB drive to
326 remove such things from protocols) or some arbitrary credentials.
327 Such a field is not included. It is felt that, in general,
328 authentication would incur sufficient overhead to negate the
329 advantages of the connectionless basis of CLDAP. If an
330 application requires authenticated access to the Directory then
331 CLDAP is not an appropriate protocol.
338 Young Standards Track [Page 6]
340 RFC 1798 CLDAP June 1995
343 Within a searchResponse all but the last SearchResponse has choice
344 'entry' and the last SearchResponse has choice 'resultCode'. Within
345 a searchResponse, as an encoding optimisation, the value of the
346 objectName LDAP DN may use a trailing '*' character to refer to the
347 baseObject of the corresponding searchRequest. For example, if the
348 baseObject is specified as "o=UofM, c=US", then the following
349 objectName LDAPDNs in a response would have the indicated meanings
351 objectName returned actual LDAPDN denoted
352 ____________________________________________________
354 "cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"
358 The following error code is added to the LDAPResult.resultCode
361 resultsTooLarge (70),
363 This error is returned when the LDAPMessage PDU containing the
364 results of an operation are too large to be sent in a single
369 A simple lookup can be performed in 4 packets. This is reduced to 2
370 if either the DSA implements the CLDAP protocol, the CLDAP server has
371 a cache of the desired results, or the CLDAP server and DSA are co-
372 located such that there is insignificant delay between them.
374 _______________________________________________________________
375 |_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
377 | 2| DAP-Search.req -> |
378 | 3| <- DAP-Search.res|
380 |__|___________________________________________________________|
382 5. Implementation Considerations
384 The following subsections provide guidance on the implementation of
385 clients and servers using the CLDAP protocol.
394 Young Standards Track [Page 7]
396 RFC 1798 CLDAP June 1995
399 5.1. Server Implementations
401 Given that the goal of this protocol is to minimise the elapsed time
402 between making a Directory request and receiving the response, a
403 server which uses DAP to access the directory should use techniques
406 - - A server should remain bound to the Directory during reasonably
407 long idle periods or should remain bound permanently.
409 - - Cacheing of results is highly desirable but this must be
410 tempered by the need to provide up-to-date results given the
411 lack of a cache invalidation protocol in DAP (either implicit
412 via timers or explicit) and the lack of a dontUseCopy service
413 control in the protocol.
415 Of course these issues are irrelevant if the CLDAP protocol is
416 directly supported by a DSA.
418 5.2. Client Implementations
420 For simple lookup applications, use of a retry algorithm with
421 multiple servers similar to that commonly used in DNS stub resolver
422 implementations is recommended. The location of a CLDAP server or
423 servers may be better specified using IP addresses (simple or
424 broadcast) rather than names that must first be looked up in another
425 directory such as DNS.
427 6. Security Considerations
429 This protocol provides no facilities for authentication. It is
430 expected that servers will bind to the Directory either anonymously
431 or using simple authentication without a password.
435 [1] The Directory: Overview of Concepts, Models and Service. CCITT
436 Recommendation X.500, 1988.
438 [2] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
439 1/SC21; International Standard 9594-2, 1988.
441 [3] The Directory: Abstract Service Definition. CCITT Recommendation
442 X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
444 [4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
445 Access Protocol", RFC 1487, Performance Systems International,
446 University of Michigan, ISODE Consortium, July 1993.
450 Young Standards Track [Page 8]
452 RFC 1798 CLDAP June 1995
455 [5] Mockapetris, P., "Domain Names - Implementation and
456 Specification", STD 13, RFC 1035, USC/Information Sciences
457 Institute, November 1987.
459 [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
460 13, RFC 1034, USC/Information Sciences Institute, November 1987.
464 Many thanks to Tim Howes and Steve Kille for their detailed comments
465 and to other members of the working group.
467 This work was initiated by the Union Bank of Switzerland.
477 Phone: +44 81 332 9091
478 EMail: A.Young@isode.com
479 X.400: i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI
506 Young Standards Track [Page 9]