1 IETF LDAPEXT Working Group Christopher Lukas [Editor]
2 INTERNET-DRAFT Internet Scout Project
4 Netscape Communications Corp.
8 Netscape Communications Corp.
14 Named Referrals in LDAP Directories
15 <draft-ietf-ldapext-namedref-00.txt>
19 1. Status of this Memo
21 This document is an Internet-Draft and is in full conformance with all
22 provisions of Section 10 of RFC2026.
24 Internet-Drafts are working documents of the Internet Engineering Task
25 Force (IETF), its areas, and its working groups. Note that other groups
26 may also distribute working documents as Internet-Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet- Drafts as reference material
31 or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 Distribution of this document is unlimited. Please send comments to the
40 authors or the LDAPEXT mailing list, ietf-ldapext@netscape.com.
42 Copyright Notice: Copyright (C) The Internet Society (1999). All Rights
45 This draft is a revision of a draft formerly published as draft-ietf-
46 ldapext-referral-00.txt.
48 This draft expires December 6, 1999.
52 Howes, et al. IETF LDAPEXT Working Group [Page 1]
58 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
63 This document defines a "ref" attribute and associated "referral" object
64 class for representing generic knowledge information in LDAP directories
65 [RFC2251]. The attribute uses URIs [RFC1738] to represent knowledge,
66 enabling LDAP and non-LDAP services alike to be referenced. The object
67 class can be used to construct entries in an LDAP directory containing
68 references to other directories or services. This document also defines
69 procedures directory servers should follow when supporting these schema
70 elements and when responding to requests for which the directory server
71 does not contain the requested object but may contain some knowledge of
72 the location of the requested object.
74 3. Background and intended usage
76 The broadening of interest in LDAP directories beyond their use as front
77 ends to X.500 directories has created a need to represent knowledge
78 information in a more general way. Knowledge information is information
79 about one or more servers maintained in another server, used to link
80 servers and services together.
82 This document defines a general method of representing knowledge infor-
83 mation in LDAP directories, based on URIs.
85 The key words "MUST", "SHOULD", and "MAY" used in this document are to
86 be interpreted as described in [RFC2119].
88 4. The ref attribute type
90 This section defines the ref attribute type for holding general
91 knowledge reference information.
93 ( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'URL reference'
94 EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
95 USAGE distributedOperation )
97 The ref attribute type has IA5 syntax and is case sensitive. The ref
98 attribute is multivalued. Values placed in the attribute MUST conform to
99 the specification given for the labeledURI attribute defined in
100 [RFC2079]. The labeledURI specification defines a format that is a URI,
101 optionally followed by whitespace and a label. This document does not
102 make use of the label portion of the syntax. Future documents MAY enable
103 new functionality by imposing additional structure on the label portion
104 of the syntax as it appears in the ref attribute.
106 If the URI contained in the ref attribute refers to an LDAPv3 server, it
107 must be in the LDAP URI format described in [RFC2255].
112 Howes, et al. IETF LDAPEXT Working Group [Page 2]
118 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
121 When returning a referral result, the server must not return the label
122 portion of the labeledURI as part of the referral. Only the URI portion
123 of the ref attribute should be returned.
125 5. Use of the ref attribute
127 One usage of the ref attribute is defined in this document. Other uses
128 of the ref attribute MAY be defined in subsequent documents, or by bila-
129 teral agreement between cooperating clients and servers.
131 Except when the manageDsaIT control (documented in section 8 of this
132 document) is present in the operation request, the ref attribute is not
133 visible to clients, except as its value is returned in referrals or con-
134 tinuation references.
136 If the manageDsaIT control is not set, and the entry named in a request
137 contains the ref attribute, and the entry is not the root DSE, the
138 server returns an LDAPResult with the resultCode field set to "referral"
139 and the referral field set to contain the value(s) of the ref attribute
140 minus any optional trailing whitespace and labels that might be present.
142 If the manageDsaIT control is not set, and an entry containing the ref
143 attribute is in the scope of a one level or subtree search request, the
144 server returns a SearchResultReference for each such entry containing
145 the value(s) of the entry's ref attribute.
147 When the manageDsaIT control is present in a request, the server will
148 treat an entry containing the ref attribute as an ordinary entry, and
149 the ref attribute as an ordinary attribute, and the server will not
150 return referrals or continuation references corresponding to ref attri-
153 The following sections detail these usages of the ref attribute.
157 This use of the ref attribute is to facilitate distributed name resolu-
158 tion or search across multiple servers. The ref attribute appears in an
159 entry named in the referencing server. The value of the ref attribute
160 points to the corresponding entry maintained in the referenced server.
162 While the distinguished name in a value of the ref attribute is typi-
163 cally that of an entry in a naming context below the naming context held
164 by the referencing server, it is permitted to be the distinguished name
165 of any entry. If the ref attribute is multi-valued all the DNs in the
166 values of the ref attribute SHOULD have the same value. It is the
167 responsibility of clients to not loop repeatedly if a naming loop is
168 present in the directory. Administrators SHOULD avoid configuring
172 Howes, et al. IETF LDAPEXT Working Group [Page 3]
178 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
181 naming loops using referrals.
183 Clients SHOULD perform at least simple "depth-of-referral count" loop
184 detection by incrementing a counter each time a new set of referrals is
185 received. Clients MAY perform more sophisticated loop detection, for
186 example not chasing the same URI twice.
188 If an entry containing the ref attribute is immediately subordinate to
189 the base object named in a one level search request, then the referring
190 server MUST include a scope of "base" in any LDAP URIs returned in the
191 corresponding SearchResultReference.
195 The following sections contain specifications of how the ref attribute
196 should be used in different scenarios followed by examples that illus-
197 trate that usage. The scenarios described consist of referral operation
198 when finding a base or target object, referral operation when performing
199 a one level search, and referral operation when performing a subtree
202 It is to be noted that, in this document, a search operation is concep-
203 tually divided into two distinct, sequential phases: (1) finding the
204 base object where the search is to begin, and (2) performing the search
205 itself. The operation of the server with respect to referrals in phase
206 (1) is almost identical to the operation of the server while finding the
207 target object for a non-search operation.
209 It is to also be noted that multiple ref attributes are allowed in any
210 entry and, where these sections refer to a single ref attribute, multi-
211 ple ref attributes may be substituted and should be processed and
212 returned as a group in an LDAPResult or search result in the same way as
213 described for a single attribute. The order of the returned continuation
214 references within a result is not defined.
217 5.1.1.1. Example configuration
232 Howes, et al. IETF LDAPEXT Working Group [Page 4]
238 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
241 |------------------------------------------------------------|
243 | dn: o=abc,c=us dn: o=xyz,c=us |
245 | ref: ldap://hostB/o=abc,c=us ref: ldap://hostD/o=xyz,c=us |
246 | ref: ldap://hostC/o=abc,c=us objectclass: referral |
247 | objectclass: referral objectclass: extensibleObject|
248 | objectclass: extensibleObject |
249 |____________________________________________________________|
251 |---------------------| |---------------------| |---------------------|
252 | Server B | | Server D | | Server C |
253 | dn: o=abc,c=us | | dn: o=xyz,c=us | | dn: o=abc,c=us |
254 | o: abc | | o: xyz | | o: abc |
255 | other attributes... | | other attributes... | | other attributes... |
256 |_____________________| |_____________________| |_____________________|
258 In this example, Server A holds references for two entries: "o=abc,c=us"
259 and "o=xyz,c=us". For the "o=abc,c=us" entry, Server A holds two refer-
260 ences, one to Server B and one to Server C. The entries referenced are
261 replicas of each other. For the "o=xyz,c=us" entry, Server A holds a
262 single reference to the entry contained in Server D.
264 In the following protocol interaction examples, the client has contacted
265 Server A. Server A holds the naming context "c=us".
267 5.1.1.2. Base or target object considerations
269 As previously described, the process of generating referrals for a
270 search can be described in two phases. The first, which is described in
271 this section, is generating referrals based on the base object specified
272 in the search. This process is identical to the process of generating
273 referrals based on the target object while processing other operations
274 (modify, add, delete, modify DN, and compare) with the sole exception
275 that for these other operations, the DN in the referral must be modified
278 If a client requests any of these operations, there are four cases that
279 the server must handle with respect to the base or target object speci-
282 Case 1: The base or target object is not held by the server and is not
283 subordinate to any object held by the server with a ref attribute.
285 The handling of this case is described in section 6.
287 Case 2: The base or target object is held by the server and contains a
292 Howes, et al. IETF LDAPEXT Working Group [Page 5]
298 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
301 In this case, if the type of operation requested is a search or the URI
302 contained in the ref attribute of the requested base object is NOT an
303 LDAP URI as defined in [RFC2255], the server should return the URI value
304 contained in the ref attribute of the base object whose DN is the DN
305 requested by the client as the base for the operation.
309 If the client issues a search in which the base object is "o=xyz,c=us",
312 SearchResultDone "referral" {
313 ldap://hostD/o=xyz,c=us
316 If the type of operation requested is not a search and the URI contained
317 in the ref attribute of the requested target object is an LDAP URI
318 [RFC2255], the server should return a modified form of this URL. The
319 returned URL must have only the protocol, host, port, and trailing "/"
320 portion of the URL contained in the ref attribute. The server should
321 strip any dn, attributes, scope, and filter parts of the URL.
325 If the client issues a modify request for the target object of
326 "o=abc,c=us", server A will return
328 ModifyResponse "referral" {
333 Case 3: The base or target object is not held by the server, but is
334 subordinate to an object with a ref attribute held by the server.
337 If a client requests an operation for which the base or target object is
338 not held by the server, but is subordinate to one or more objects with a
339 ref attribute held by the server, the server must return the referral
340 from the superior held object nearest to the requested base or target
341 object. Nearest superior object with a referral, in this document, means
342 an object superior to the base or target object with the DN that has the
343 most attribute values in common with the DN of the base or target object
344 and contains a ref attribute.
346 The process of finding the nearest superior object can be envisioned as
347 walking up the locally held part of the DIT from the requested base or
348 target object checking each superior object until either an object with
352 Howes, et al. IETF LDAPEXT Working Group [Page 6]
358 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
361 a ref attribute is found or the top-most locally held object is reached.
362 Once possible implementation of this algorithm is as follows:
364 1. Remove the leftmost attribute/value pair from the DN of the
365 requested base or target object.
366 2. If the remaining DN represents a locally held object that contains
367 a ref attribute, that object is the nearest superior object with a
368 referral. Stop and process the referral as described below.
369 3. If the remaining DN is the root of the locally held part of the
370 DIT, stop and proceed as described in section 6.
371 4. Continue with step 1.
373 Once the nearest superior object has been identified, if the referral
374 contained in that object is not an LDAP URI [RFC2255], it should be
375 returned as-is. If the referral is an LDAP URI, the referral must be
376 modified, regardless of the type of operation, as case 2 describes for a
377 non-search requuest. That is, the dn, attributes, scope, and filter
378 parts of the URL must be stripped from the referral and the referral
383 If the client issues an add request where the target object has a DN of
384 "cn=Chris Lukas,o=abc,c=us", server A will return
386 AddResponse "referral" {
394 5.1.1.3. Search with one level scope
396 For search operations, once the base object has been found and deter-
397 mined not to contain a ref attribute, the search may progress. Any
398 entries matching the filter and scope of the search that do NOT contain
399 a ref attribute are returned to the client normally as described in
400 [RFC2251]. Any entries matching the filter and one level scope that do
401 contain a ref attribute must be returned as referrals as described here.
403 If a matching entry contains a ref attribute and the URI contained in
404 the ref attribute is NOT an LDAP URI [RFC2255], the server should return
405 the URI value contained in the ref attribute of that entry in a Sear-
408 If a matching entry contains a ref attribute in the LDAP URI syntax
412 Howes, et al. IETF LDAPEXT Working Group [Page 7]
418 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
421 [RFC2255], the URL from the ref attribute must be modified before it is
422 returned by adding or substituting a "base" scope into the URL. If the
423 URL does not contain a scope specifier, the "base" scope specifier must
424 be added. If the URL does contain a scope specifier, the existing scope
425 specifier must be replaced by the "base" scope.
429 If a client requests a one level search of "c=US" then, in addition to
430 any entries one level below the "c=US" naming context matching the
431 filter (shown below as "... SearchResultEntry responses ..."), the
432 server will also return referrals modified to include the "base" scope
433 to maintain the one level search semantics.
435 The order of the SearchResultEntry responses and the SearchResultRefer-
436 ence responses is undefined. One possible sequence is shown.
438 ... SearchResultEntry responses ...
440 SearchResultReference {
441 ldap://hostB/o=abc,c=us??base
442 ldap://hostC/o=abc,c=us??base
445 SearchResultReference {
446 ldap://hostD/o=xyz,c=us??base
449 SearchResultDone "success"
452 5.1.1.4. Search with subtree scope
454 For a search operation with a subtree scope, once the base object has
455 been found, the search progresses. As with the one level search, any
456 entries matching the filter and scope of the search that do NOT contain
457 a ref attribute are returned to the client normally as described in
460 If an entry matching the requested scope and filter contains a ref
461 attribute, the server should return the URI value in a SearchResul-
466 If a client requests a subtree search of "c=us", then in addition to any
467 entries in the "c=us" naming context which match the filter, Server A
468 will also return two continuation references. As described in the
472 Howes, et al. IETF LDAPEXT Working Group [Page 8]
478 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
481 preceding section, the order of the responses is not defined.
483 One possible response might be:
485 ... SearchResultEntry responses ...
487 SearchResultReference {
488 ldap://hostB/o=abc,c=us
489 ldap://hostC/o=abc,c=us
492 SearchResultReference {
493 ldap://hostD/o=xyz,c=us
496 SearchResultDone "success"
499 6. Superior Reference
501 An LDAP server may be configured to return a superior reference in the
502 case where the server does not hold either the requested base object or
503 an object containing a ref attribute that is superior to that base
506 An LDAP server's root DSE MAY contain a ref attribute. The values of the
507 ref attribute in the root DSE that are LDAP URIs SHOULD NOT contain any
508 dn part, just the host name and optional port number.
510 If the LDAP server's root DSE contains a ref attribute and a client
511 requests an object not held by the server and not subordinate to any
512 held object, the server must return the URI component of the values in
513 the ref attribute of the root DSE as illustrated in the example.
515 If the LDAP server's root DSE does not contain a ref attribute, the
516 server may return one or more references that the server determines via
517 a method not defined in this document to be appropriate.
519 The default reference may be to any server that might contain more
520 knowledge of the namespace than the responding server. In particular,
521 the client must not expect the superior reference to be identical from
522 session to session as the reference may be dynamically created by the
523 server based on the details of the query submitted by the client.
525 When the server receives an operation for which the base or target entry
526 of the request is not contained in or subordinate to any naming context
527 held by the server or a referral entry, the server will return an
528 LDAPResult with the resultCode set to "referral", and with the referral
532 Howes, et al. IETF LDAPEXT Working Group [Page 9]
538 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
541 field filled with a referral that the server has determined to be
546 If a client requests a subtree search of "c=de" from server A in the
547 example configuration, and server A has the following ref attribute
548 defined in it's root DSE:
552 then server A will return
554 SearchResultDone "referral" {
559 7. The referral object class
561 The referral object class is defined as follows.
563 ( 2.16.840.1.113730.3.2.6 NAME 'referral' SUP top STRUCTURAL
566 The referral object class is a subclass of top and may contain the
567 referral attribute. The referral object class should, in general, be
568 used in conjunction with the extensibleObject object class to support
569 the naming attributes used in the entry's distinguished name.
571 Servers must support the ref attribute through use of the referral
572 object class. Any named reference must be of the referral object class
573 and will likely also be of the extensibleObject object class to support
574 naming and use of other attributes.
576 8. The manageDsaIT control
578 A client MAY specify the following control when issuing a search, com-
579 pare, add, delete, modify, or modifyDN request or an extended operation
580 for which the control is defined.
582 The control type is 2.16.840.1.113730.3.4.2. The control SHOULD be
583 marked as critical. There is no value; the controlValue field is
586 This control causes entries with the "ref" attribute to be treated as
587 normal entries, allowing clients to read and modify these entries.
592 Howes, et al. IETF LDAPEXT Working Group [Page 10]
598 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
601 This control is not needed if the entry containing the referral attri-
602 bute is one used for directory administrative purposes, such as the root
603 DSE, or the server change log entries. Operations on these entries
604 never cause referrals or continuation references to be returned.
606 9. Relationship to X.500 Knowledge References
608 The X.500 standard defines several types of knowledge references, used
609 to bind together different parts of the X.500 namespace. In X.500,
610 knowledge references can be associated with a set of unnamed entries
611 (e.g., a reference, associated with an entry, to a server containing the
612 descendants of that entry).
614 This creates a potential problem for LDAP clients resolving an LDAPv3
615 URL referral referring to an LDAP directory back-ended by X.500. Sup-
616 pose the search is a subtree search, and that server A holds the base
617 object of the search, and server B holds the descendants of the base
618 object. The behavior of X.500(1993) subordinate references is that the
619 base object on server A is searched, and a single continuation reference
620 is returned pointing to all of the descendants held on server B.
622 An LDAP URI only allows the base object to be specified. It is not pos-
623 sible using standard LDAP URIs to indicate a search of several entries
624 whose names are not known to the server holding the superior entry.
626 X.500 solves this problem by having two fields, one indicating the pro-
627 gress of name resolution and the other indicating the target of the
628 search. In the above example, name resolution would be complete by the
629 time the query reached server B, indicating that it should not refer the
632 This document does not address this problem. This problem will be
633 addressed in separate documents which define the changes to the X.500
634 distribution model and LDAPv3 extensions to indicate the progress of
637 10. Security Considerations
639 This document defines mechanisms that can be used to "glue" LDAP (and
640 other) servers together. The information used to specify this glue
641 information should be protected from unauthorized modification. If the
642 server topology information itself is not public information, the infor-
643 mation should be protected from unauthorized access as well.
645 Clients should use caution when re-using credentials while following
646 referrals as the client may be directed to any server which may or may
647 not respect or use those credentials appropriately.
652 Howes, et al. IETF LDAPEXT Working Group [Page 11]
658 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
664 Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform Resource
665 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
666 Minnesota, December 1994.
669 M. Smith, "Definition of an X.500 Attribute Type and an Object Class
670 to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January
674 S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev-
675 els", RFC 2119, March 1997. (Format: TXT=4723 bytes) (Also BCP0014)
676 (Status: BEST CURRENT PRACTICE)
679 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
680 (v3)", RFC 2251, December 1997.
683 T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December, 1997.
684 (Format: TXT=20685 bytes) (Status: PROPOSED STANDARD)
687 ITU-T Rec. X.501, "The Directory: Models", 1993.
692 Netscape Communications Corp.
693 501 E. Middlefield Rd.
695 Mountain View, CA 94043
698 EMail: howes@netscape.com
701 Internet Scout Project
702 Computer Sciences Dept.
703 University of Wisconsin-Madison
707 EMail: lukas@cs.wisc.edu
712 Howes, et al. IETF LDAPEXT Working Group [Page 12]
718 INTERNET-DRAFT LDAPv3 Named Referrals March 1999
722 Internet Scout Project
723 Computer Sciences Dept.
724 University of Wisconsin-Madison
728 EMail: mfr@cs.wisc.edu
731 Netscape Communications Corp.
732 501 E. Middlefield Rd.
734 Mountain View, CA 94043
736 EMail: mcs@netscape.com
739 Innosoft International, Inc.
740 8911 Capital of Texas Hwy #4140
742 EMail: M.Wahl@innosoft.com
745 This draft expires December 6, 1999.
772 Howes, et al. IETF LDAPEXT Working Group [Page 13]