version: A version number indicating the version of the protocol to be used in this protocol session. This document describes version 3 of the LDAP protocol. Note that there is no version negotiation, and the client just sets this parameter to the version it desires. If the client requests protocol version 2, a server that supports the version 2 protocol as described in [2] will not return any v3-specific protocol fields. (Note that not all LDAP servers will support protocol version 2, since they may be unable to generate the attribute syntaxes associated with version 2.)

name: The name (DN) of the directory object that the client wishes to bind as. This field may take on a null value (a zero length string) for the purposes of anonymous binds, when authentication has been performed at a lower layer, or when using SASL credentials with a mechanism that includes the DN in the credentials.

Upon receipt of a Bind Request, a DSA will authenticate the requesting client (DUA), if necessary. The DSA will then return a Bind Response to the DUA indicating the status of the Authentication.

Authorization is the use of this Authentication information when performing operations. Authorization MAY be affected by factors outside of the LDAP Bind request, such as lower layer security services.

RFC 4511 (section 4.2.1) states that bind operations cannot be processed on a connection that has any other outstanding operations. In particular "Before processing a Bind Request, all uncompleted operations MUST either complete or be "abandoned" and "After sending a Bind Request, clients MUST NOT send further LDAPPDUs until receiving the Bind Response."

This is because a bind operation is used to change the authentication state of a connection (and in some cases may also include negotiating a communication security layer). It is dangerous to have other types of operations in progress on the connection while a bind is being processed because the bind processing may change the nature of the response to the client.