1.3 Protocol Overview (Synopsis)

The Callback Control Protocol (CBCP) enables dial-up peers to negotiate callback settings such as callback type, callback number, and delay before callback.

The PPP enables two endpoints of a point-to-point link to negotiate link characteristics, authentication, and the network configuration. It typically involves a network access client (NAC) connecting to a network access server (NAS) in order to access the NAS and the network beyond the NAS. For dial-up links, since the NAC will be dialing to the NAS, the NAC will take the role of the caller and the NAS will be the answerer.

The NAC establishes the dial-up connectivity to the NAS. Over the link established, the PPP is used to transfer data of various protocols. The typical PPP negotiation comprises the Link Establishment Phase, occurring first, during which the Link Control Protocol (LCP), as specified in [RFC1570], establishes the data-link specific parameters for the session. After this, the authentication phase occurs, through which the authentication of the peer involved in the PPP session takes place using any of the PPP-based authentication protocols (like EAP as specified in [RFC2284], MS-CHAPv2 as specified in [RFC2759], and so on). The Network Layer protocol phase commences after the authentication phase, which negotiates the network layer protocol configurations through the Network Control Protocol (NCP), as specified in [RFC1570] -- for example, IPv4 configuration is negotiated through IP Configuration Protocol (IPCP) (see [RFC1332]) and IPv6 configuration is negotiated through IPv6 Configuration Protocol (IPv6CP) (see [RFC2472]).

The CBCP enables the negotiation of callback settings. Based on the negotiated callback settings, the NAS can even play the role of the caller and the NAC can play the role of the answerer. The primary advantage of this setup is that the NAS is responsible for the toll charges involved with the connectivity.

[RFC1570] defines the Callback configuration option (0x0D) LCP extension, which allows the callback information to be exchanged. This callback configuration negotiation occurs before the authentication phase is complete. The answerer has to agree or disagree to do the callback before authenticating the caller. This has security implications and also might not be feasible since the callback information is typically policy-based.

The alternate callback method is through negotiating the use of CBCP. The callback settings are negotiated after the authentication phase is complete (by which time the policy decision based on user authentication would be available). This also enables interoperability since the NAC and NAS have to agree to use the CBCP beforehand, and the answerer (NAS) drives the negotiation of the supported callback settings.

The CBCP comprises three message exchanges. The answerer initiates the negotiation with a Callback Request message with the possible callback options. The caller responds back with the Callback Response message having the preferred option, along with additional configuration information (like the callback number or delay before callback). The answerer confirms the settings through the Callback Acknowledgment message. The reception of the Callback Acknowledgment message indicates that the answerer has accepted the callback settings. The CBCP protocol negotiation is complete at this point.

Subsequently, the caller terminates the PPP session if it has negotiated to be called back. The answerer waits for a specific period of time (requested by the caller as a part of the CBCP) and initiates the dial-up connection callback to the caller. The PPP negotiation happens between the peers as usual between the NAC and the NAS, but without the CBCP being negotiated as a part of the LCP phase (as the callback has already been done).

If 'No callback' has been negotiated as part of CBCP, the NAC and NAS will proceed to the NCP phase to negotiate the network settings.

Figure 1: Callback message exchanges