[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                   A. Brown
Internet Draft                                          Nortel
Expires:                                                C. Weider
Category:                                               Microsoft
                                                        Mark Wahl
                                                        Innosoft
                                                        April 10, 1997


                Practical guidance for naming and interconnectivity
                        <draft-ietf-lsd-nandi-00.txt>


Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups.  Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time.  It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).

Abstract

There are existing communities of LDAP, X.500 and Whois++ servers
on the Internet.  An LDAPv3 server can be a part of one of more of
these communities.  LDAP directory services would benefit from
reduced naming conflicts and increased ability to locate servers
and information both within LDAP islands and between LDAP and
other communities.  This document recommends guidelines for naming
and interconnection of LDAP servers to enable the existence of
communities of a loosely coupled LDAP-based directory service that
can leverage the X.500 knowledge model and the existing
infrastructure of names from the Domain Name System (DNS).  This
will facilitate the establishment of a global naming plan and the
interconnection of a global directory.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  and "MAY" in this
document are to be interpreted as described in RFC 2119 [10].

1 Introduction

1.1 Background

While some directory implementations will have a requirement to
use the dc naming structure described in [DC Naming] which is
based on DNS naming, this does not preclude connection to the
infrastructure that comprises a hierarchy resulting from the
knowledge model [X.500].  Similarly, there may be implementations
that are part of the knowledge model infrastructure that may wish
to make use of the dc naming model.

1.2 Purpose

The aim of this document is to facilitate the interconnection of
LDAP servers.  One goal is to enable the location of directory
servers and information stored on those servers.  Another goal is
to allow the initial interconnection of LDAP servers into
arbitrary islands, in such a way as to allow these islands to
interconnect at a later date without causing naming conflicts.
This will facilitate the establishment of a global naming plan and
the interconnection of a global directory.

1.3 Scope

Use of each naming philosophy has its own implications, such as
registration, and may require cooperation of large communities
before being used on a large scale.  The dc naming and knowledge
models are introduced, along with a section on bridging these
models.  Recommendations are provided on which model(s) to use,
based on a list of requirements that each model addresses. [Ed.
Note: Do we need this section?]  Using these guidelines, an
administrator can chose one or a combination of namespace choices,
based on the requirements (e.g., browsing, intra-server searching,
cost, timely updates, performance, security, etc.) of the
directory being deployed.

2 Internet Directory Naming

If you wish to install an LDAP server that will never, for all time, be
used by anyone outside your organization, you may use any root name for
your LDAP server's namespace that you wish. However, if you might want
to be able to connect your server with other servers within your
organization, or wish to allow users outside your organization to
access some of your data, you need to use one of the generally accepted
LDAP naming schemes to allow your computer to find and be found by
other computers.

There are two basic models for naming of LDAP servers. The first
continues the tradition used by X.500, which uses a geographically
based namespace. A typical example would be 'country = Canada, province=
Ontario, organization = Nortel.'.   The second, recently developed in
the IETF, leverages the  existing DNS naming structure to create LDAP
names. An example would be dc = critical-angle, dc = com.  Each of these
has its advantages and disadvantages. We will discuss each of these in
detail below.

2.1 dc Names

The basis for 'dc naming', as it is called, is the existing DNS
naming  infrastructure. Since a DNS name is today a prerequisite
for supplying a service to the Internet, and since a DNS name is
guaranteed to be globally unique, it can be used through the DC
naming algorithm as a root for your local LDAP server.

The algorithm used to take an existing DNS name and turn it into
an LDAP root is extremely simple. Given a DNS name, such as
foo.bar.com, simply split it up into components and use each
component as a level in the name, i.e. dc = foo, dc = bar, dc =
com. This can then be used as a root for an LDAP server, so that a
typical entry on that server might have the Distinguished Name
(DN) cn=Ebenezer Scrooge, o= Scrooge and Marley, dc =  foo, dc =
bar, dc = com.

Interconnection issues for servers using DC names are covered
below.

2.1.1 Obtaining a dc name

To connect to the Internet and provide a service, you
typically need a DNS name for your organization. This is
usually provided as a part of  your Internet connectivity
package from your local Internet provider.  Once you have
this name, if you wish to connect your LDAP server to the
Global Directory, or allow it to be found by users who may
only know the DNs of entries on your server, you will need
to follow the algorithm above and build a root name for your
server.

2.2 X.500 Naming

X.500 naming is similar to DNS naming in that each component of an
X.500 name represents a level in a hierarchy.  However X.500
naming is not limited to domain components.  An X.500 name
component, called a Relative Distinguished Name (RDN), can be a
geographical entity, an organization's name, a component in a
natural hierarchy, such as a digit in the E.164 numbering plan, or
some other name that is useful to applications and users that
access a directory.

In X.500 there is considered to be one hierarchical tree, which
may be comprised of sub-trees, such as one structured after the
E.164 numbering plan.

2.2.1 Obtaining a Name in X.500

To become part of the global X.500 directory hierarchy, you
must register a name that is unique among its siblings under
a particular node in the tree.  The registration authority
for the top level of the hierarchy is currently being
established.  [Ed. Note: What is the status of ANSI's
proposal to the ITU?]  This registrar may delegate authority
to entities who wish to have entries directly under the root
of the tree, such as countries and international
organizations. These authorities may further delegate sub-
trees under their responsibility to other organizations.

3 Interconnection Models

Each LDAP server holds a part of the overall LDAP namespace. Tying LDAP
servers together into a global directory requires that servers be able
to locate each other. There is an existing mechanism for locating
servers using the knowledge model, which will be outlined below. This
document defines an additional mechanism for locating servers using the
DC style naming, and section 4 covers how to interface the dc naming and
knowledge models.

3.1 dc Model

The DC model is designed to facilitate 'grass-roots' deployment of
LDAP, i.e. deployment which is not globally centrally managed or
coordinated. Therefore, when you deploy servers using the DC
model, you should exercise discipline in actually assigning DNS
names to your LDAP servers. That will allow the following
algorithm for server location to work without central
coordination, and will make it easier for you to interoperate with
other LDAP servers.

3.1.1 Locating an LDAP server from a DC style DN

To locate an LDAP server from a DC style DN, convert the DC
components into the corresponding DNS name. Then use
[Discovery] to find the appropriate server.

This mapping can be done on either the client or server
side. If it is done on the client side, and the server is in
the correct location, the client can go directly to the
appropriate server without having to interact with any other
server. If it is done on the server side, the server is
responsible for doing the translation and referring the
client appropriately. Note that if this is done on the
server side, the server may have additional information
which allows it to determine the location of the target DN.

3.1.2 Naming your server

Your server should be named such that a client or server
following the above algorithm would be able to locate the
server. If there are multiple DC based naming contexts on
your server, your server should be locatable through the use
of any of those contexts.

Example: If you have a naming context of DC=foo, DC=bar,
DC=com on your LDAP server, that server should be reachable
through the SRVLOC record corresponding to
ldap.tcp.foo.bar.com. Similarly, if you also have a naming
context of DC=hoohoo, DC= bar2, DC=com, that server should
also be reachable through ldap.tcp.hoohoo.bar2.com.

3.1.3 Server requirements to support this plan

If you are responsible for deploying an entire subtree
distributed across several servers, you may wish to put
superior and subordinate references in for all servers which
are not rooted directly at a DN comprised solely of DC
components. For example, let's say that you had two servers
in your organization, one rooted at dc=foo, dc=com, and the
other one rooted at ou=marketing, dc=foo, dc=com. Obviously
the only way to locate the second server is to have a
subordinate reference to it on the parent server, as the
name translation algorithm listed above is only able to
handle dc components.

In addition, the server may wish to perform DC-based name
resolution for arbitrary DNs which end in a dc-based name
component. The question of whether such results are cached
by the server is not addressed by this document.

3.2 Knowledge Model

If a local server does not contain the information requested by a
client, the server may either reject the request, contact another
server to locate the required information, or may refer the client
to another server.  For one server to be able to contact another
using the knowledge model, it must first possess a knowledge
reference for the remote server.  A knowledge reference consists
of a server's address (i.e., IP address or domain name) and
possibly the DN of an entry in the portion of the directory
hierarchy held by the remote server.

Name resolution is the process by which the X.500 hierarchy is
traversed from the root of the tree down to the entry identified
by the X.500 name in question.  If the name resolution process
encounters a knowledge reference, the process continues onto the
server specified in the reference.

4 Interfacing the dc Naming and Knowledge Model
Infrastructures

This section describes how servers following the dc and knowledge models
of interconnection can refer queries to servers which follow the other
naming model.  This is done by configuring the superior reference of
servers following the DC model and top level references of servers
following the knowledge model to point to specialized servers known as
referral servers.  These referral servers act as a bridge between the
interconnection models, so that most LDAP servers need only have a minor
configuration choice made in order to allow clients to be able to reach
data on all other servers regardless of whether the interconnection
model these two servers support are the same.

4.1 Referral servers

A referral server is an LDAPv3 server whose primary purpose in
this application is to return referrals for clients to progress
particular requests. These requests are characterized as
operations in which the target or base entry uses a different
naming scheme than that of the server to which client first sent
the query.  Referral servers need not maintain any master or fully
replicated data on entries of interest to users, instead they
would contain knowledge references or CIP indexes.

There might be multiple referral servers in the Internet.  Any
referral server SHOULD have query routing algorithms which
implement at least two of the following interconnection models:

 - CIP index of LDAP servers
 - DNS
 - X.500
 - Another indexing system which supports LDAP queries

The algorithms for the first three models are discussed in the
following  sections 4.1.1 through 4.1.3.

Like all LDAPv3 servers, referral servers will return data about
themselves when the query is a base object search of the root.
These servers SHOULD be able to process a one level search of the
root.  These servers will likely return an error if the query is a
subtree search of the root, and MUST return an error if they
support either the DNS or X.500 algorithms.

4.1.1 Algorithm for CIP index of LDAP servers

This algorithm is used by referral server when it recognizes
the target or base entry DN of the client's query, or a
superior of that DN, is the  base of a CIP index supported
by the referral server.  In this case, the referral server
SHOULD use the specification defined in [CIP for LDAP] to
return to the client either a result message (possibly
containing a referral) or a set of continuation references.
This will usually refer the client to the servers more
likely to hold the requested data.

This algorithm is also used if the base entry DN of the
client's query is superior to the base of a CIP index and
the base of the CIP index is in the scope of the query.  If
however the base of the CIP index is not in the scope of the
query, then the algorithms in section 4.1.2 or 4.1.3 would
typically be used instead.

4.1.2 Algorithm for DNS

This algorithm is used when the most significant RDN
component of the target or base entry DN of the client's
query consists of a single AVA of the 'dc' attribute type,
and the target or base object DN is not recognized as being
at or below the base of a CIP index supported by the
referral server.

In this case, the referral server SHOULD use the DNS to
resolve as many components of the DN as possible which have
the 'dc' attribute type using the algorithm defined in [DC
Naming] and [SRV].

4.1.3 Algorithm for X.500

This algorithm is used when the most significant RDN
component of the target or base entry DN is not an AVA of
the 'dc' attribute type, and it is not recognized at or the
base of a CIP index supported by the referral server.

In this case, the referral server SHOULD refer the operation
to one of the 'first level DSA' servers, which is a server
that is not part of the DNS interconnection model and which
holds a naming context consisting of a single RDN.  The
referral server SHOULD choose to refer to the servers which
hold an entry at or superior to the target or base entry
requested by the client, should the information of
relationships between naming contexts and servers be
available to the referral server.

Administrators should note that as there may be in the
Internet multiple distinct hierarchies using X.500
interconnection models, any particular referral server may
not be able to reach all the servers using X.500
interconnection.

4.1.4 Advertising first level information to X.500

A referral server which supports both the DNS and X.500
algorithms SHOULD advertise to the X.500 interconnection
model servers that it contacts knowledge information for the
DNS, so that these servers can in return referrals to the
referral server.

The referral server SHOULD advertise that it is a master or
shadow server for each entry whose name is the 'dc' form of
a top level DNS domain.

The list of all Top Level DNS domains is currently
maintained by the InterNIC, operated by Network Solutions,
at the URL [Top level DNS domains].

This contents and maintainer of this list is likely subject
to change, and this document or a successor will be revised
when this occurs.

The mechanism by which the referral server provides this
information to the X.500 server MAY be one of the following:

 [Ed. Note: *** To be Provided ***]

4.1.5 Advertising the referral server in DNS

A record for a referral server SHOULD be present in the DNS
with a SRV record pointing to it.  This will allow the DNS
name of the SRV record to be easily communicated and allow
the number and location of the referral servers themselves
with that DNS name to be changed by the referral server's

administrators without significantly disrupting the
configuration of other servers on the Internet.

4.2 Configuration of servers holding dc names

A server which holds a naming context based on a 'dc' style name
SHOULD support the interconnection model described in section 3.1.
In addition, if the server holds a naming context immediately
subordinate to the root or the server does not have a superior
reference to server(s) which hold a superior naming context, then
the server SHOULD have a superior reference to a referral server.

The format of the superior reference is defined in section 5.2 of
[Referrals].

The mechanism by which the administrator of the server locates and
chooses an appropriate referral server for use as a superior
reference is not defined in this document.

4.3 Configuration of servers holding non-first-level X.500 names

A server which holds a naming context based on a naming scheme
other than one ending in a 'dc' based name where that naming
context is not immediately subordinate to the root SHOULD support
the interconnection model described in section 3.2.  No additional
configuration need be done by these server administrators to
support referral servers.

4.4 Configuration of servers holding first level X.500 names

A 'first level DSA', as defined in section 4.1.3, SHOULD have
knowledge references corresponding to every top level DNS domain.
It would typically have received this knowledge information from
one or more referral servers, as described in section 4.1.4.
These knowledge references held in a first level DSA need not
necessarily point at the same referral server, however there
SHOULD be a reference to at least one referral server for each top
level domain in the DNS.   The mechanism by which the
administrator chooses the appropriate referral servers is not
defined in this document.

5 Recommendations

[Ed. Note: Do we need this section?]

6 Security

This memo describes how LDAP servers can be named and interconnected.
Servers should ensure that an appropriate security policy is maintained.

An enterprise is not restricted in the information which it may store in
DNS or LDAP servers.  A client which contacts an untrusted server may
have incorrect or misleading information returned (e.g. an
organization's server may claim to hold naming contexts representing
domain names which have not been delegated to that organization).

7 Internationalization

[Ed.Note: To be provided]

8 References

[CIP for LDAP] Roland Hedberg "LDAPv2 client Vs the Index Mesh", draft-
ietf-find-cip-ldapv2-01.txt, January 1997.

[DC Naming] S. Kille, M. Wahl, A. Grimstad, R. Huber, "Using Domains in
LDAP/X.500 Distinguished Names", RFC 2247, January 98.

[Discovery] R. Moats, M. Hamilton, P. Leach, "Finding Stuff (How to
discover services)", draft-ietf-srvloc-discovery-05.txt, October 97.

[Referrals] Tim Howes, Mark Wahl, "Referrals and Knowledge References in
LDAP Directories", draft-ietf-ldapext-referral-00.txt, March 98.

[SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location of
services (DNS SRV)," RFC 2052, October 1996.

[Top level DNS domains] [Ed. Note: To be provided]

[X.500] ITU-T X.500 Series of Recommendations, "The Directory",  1993.

9 Author's Addresses

        Anne R. Brown
        Nortel Technology
        P.O. Box 3511, Station C
        Ottawa, ON  K1Y 4H7
        Canada
        Voice: +1 613 765 5274
        Email: arbrown@nortel.com

        Chris Weider
        Microsoft Corp.
        1 Microsoft Way
        Redmond, WA 98052
        USA
        Voice: +1 425 703 2947
        Email: cweider@microsoft.com

        Mark Wahl
        Innosoft
        4815 W. Braker Lane #502-385
        Austin, TX 79759
        USA
        Voice: +1 512 372 3160
        Email: M.Wahl@Critical-Angle.com