Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
Extracted elements (29)
A server-controlled flow mechanism (CRP) was defined so the server can inform clients how often to send refresh requests, allowing operators to tune the trade-off between refresh traffic overhead and directory freshness.
Creator-owned meetings are naturally supported by the dynamic extensions: the meeting creator owns the entry TTL, non-creators may modify meeting attributes but cannot refresh the entry, and the meeting disappears when the creator goes offline.
Dynamic information changes very frequently and disk-based databases used for static directory services are likely inappropriate. The spec recommends storing dynamic entries in memory sufficient to avoid paging, though this is not a hard requirement.
Clients should be prepared for Refresh operations to fail with protocolError even after successful Add and prior Refresh requests, which can occur if a proxy that does not support the Refresh extended operation is inserted between client and server.
The Refresh request is permitted over connectionless (UDP) transport. On connection-oriented transport, there is no requirement that the Refresh operation use the same connection as other operations.
When a dynamic entry is replicated, the entryTtl (expressed as seconds remaining) will be offset by the replication delay, so replicated copies of dynamic entries may have inaccurate TTL values.
X.500/DAP servers can map Refresh request and response operations onto the X.500/DAP Modify(97) operation, enabling interoperability between LDAP dynamic extensions and X.500 DSPs.
A non-dynamic entry cannot be added subordinate to a dynamic entry; the server must return an appropriate update or service error if this is attempted.
All dynamic entries must have the dynamicObject value in their objectClass attribute, and the server must ensure the entryTtl operational attribute is present in every dynamic entry.
Clients must check the dynamicSubtrees operational attribute in the root DSE to determine if dynamic extensions are supported on a specific subtree, since servers may restrict support to only part of the DIT.
Clients must not expect a dynamic entry to be present after timeout, but must not require immediate removal; if the client needs to ensure an entry does not exist, it should issue a RemoveRequest.
Clients must not issue the Refresh request for dynamic entries which they have not created. A server is permitted to return insufficientAccessRights (50) if an unauthorized client attempts to refresh an entry.
If the server does not implement this extension, it must return an ExtendedResponse containing only the standardResponse element (responseName and response absent) with a protocolError result code.
Servers implementing the dynamic extensions must have the extension OID (1.3.6.1.4.1.1466.101.119.1) present in supportedExtension in the root DSE, and must publish the schema definitions in attributeTypes and objectClasses of their subschema subentries.
Since the LDAP AddRequest does not return CRP information, a client must issue a Refresh extended operation immediately after an Add that created a dynamic entry; the Refresh Response returns the CRP (responseTtl) to the client.
The requestTtl field in a Refresh request must be between 1 and 31557600 seconds. Servers are not required to honor this value and may return a different TTL; clients must be able to use the server-dictated value as their Client Refresh Period (CRP).
The responseTtl must not be smaller than the client-requested TTL, but servers may shorten it down to a minimum of 86400 seconds (one day) to maintain directory accuracy and prevent abuse.
There is no way to change a static entry into a dynamic one or vice-versa. If a client uses Modify with objectClass dynamicObject on a static entry, the server must return objectClassModsProhibited or objectClassViolation.
A dynamic entry is an LDAP directory entry with a time-to-live (TTL) that decrements automatically. If not refreshed before the TTL expires, the entry disappears from the directory as if deleted by an LDAP delete operation.
The dynamicObject auxiliary object class (OID 1.3.6.1.4.1.1466.101.119.2, SUP top AUXILIARY) must be included in an entry's objectClass to make it dynamic. It has no mandatory attributes; the server provides entryTtl if the client does not.
The dynamicSubtrees operational attribute (OID 1.3.6.1.4.1.1466.101.119.4, NO-USER-MODIFICATION) is present in the Root DSE and lists the subtrees for which the server supports dynamic extensions. It may be absent if the server supports dynamic entries in all naming contexts.
The entryTtl operational attribute (OID 1.3.6.1.4.1.1466.101.119.3, SYNTAX Integer, SINGLE-VALUE, NO-USER-MODIFICATION) indicates the seconds remaining before a dynamic entry disappears. It is maintained by the server and can only be changed via the Refresh operation.
The Refresh extended operation (OID 1.3.6.1.4.1.1466.101.119.1) allows a client to reset the TTL of a dynamic entry. The request carries an entryName (LDAPDN) and a requestTtl (INTEGER, seconds) inside a DER-encoded SEQUENCE.
This document registers LDAP extended operation OID 1.3.6.1.4.1.1466.101.119.1 (Refresh), object class OID 1.3.6.1.4.1.1466.101.119.2 (dynamicObject), attribute type OID 1.3.6.1.4.1.1466.101.119.3 (entryTtl), and attribute type OID 1.3.6.1.4.1.1466.101.119.4 (dynamicSubtrees) under the LDAP OID arc.
Information obtained from a dynamic directory may be out of date. For example, IP addresses obtained from the directory may have been reassigned after the original host disconnected, so relying on dynamic directory data for authorization or routing decisions requires caution.
Servers may permit anonymous clients to refresh entries they did not create, which is a potential for abuse. To mitigate this, servers may require clients to bind before issuing a RefreshRequest, enforced via ACLs on the entryTtl attribute returning insufficientAccessRights (50).
A dynamic entry transitions through: Created (Add with dynamicObject) → Active (refreshed within TTL window) → Expired/Removed (TTL reaches 0, server removes entry). Clients may also explicitly trigger Deleted via the LDAP delete operation.
The Refresh Request value is a DER-encoded SEQUENCE { entryName [0] LDAPDN, requestTtl [1] INTEGER }, carried in the requestValue OCTET STRING of an LDAP ExtendedRequest with requestName '1.3.6.1.4.1.1466.101.119.1'.
The Refresh Response value is a DER-encoded SEQUENCE { responseTtl [1] INTEGER }, carried in the response OCTET STRING of an LDAP ExtendedResponse. On error, responseTtl is 0.