PPPoE Negotiation

PPPoE negotiation is a process in which the Device assigns a session ID for PPPoE user access. The session ID identifies a PPPoE virtual link between a user and the Device. Figure 19-58 shows the PPPoE negotiation process.

1. The user broadcasts a PPPoE Active Discovery Initiation (PADI) packet carrying the service that it is requesting.

2. After receiving the PADI packet, all access concentrators (ACs) on the Ethernet network compare the requested service against the services they can offer. Then the ACs that can provide the requested service reply with a PPPoE Active Discovery Offer (PADO) packet. In this example, the Device in Figure 19-58 is an AC.

3. As the PADI packet is broadcast, the user may receive more than one PADO packet. The user looks through the PADO packets it receives and selects one meeting specified conditions. Then the user sends a PPPoE Active Discovery Request (PADR) packet carrying the service that it is requesting to the selected Device.

4. When the Device receives a PADR packet, it prepares to enter a PPP session. The Device generates a unique session ID for the PPPoE session and replies to the user with a PPPoE Active Discovery Session-confirmation (PADS) packet carrying the session ID. If no error occurs during this process, the Device enters the PPP session. The user enters the PPP session after receiving the PADS packet.

Figure 19-58 PPPoE negotiation process

PPP Negotiation

PPP negotiation includes Link Control Protocol (LCP) negotiation, Password Authentication Protocol (PAP)/Challenge Handshake Authentication Protocol (CHAP) authentication, and Network Control Protocol (NCP) negotiation.

• LCP negotiation

  After the PPP session is established, LCP negotiation starts. Figure 19-59 shows how LCP negotiation is implemented.

  1. The user and Device exchange LCP Configure-Request packets.
  2. Upon receipt of LCP Configure-Request packets, the user and Device send appropriate responses based on the Configuration Options in the packets. For details on response packet types, see Table 19-6. If both ends reply with a Configure-Ack packet, the LCP link is established. Before this occurs, both ends keep sending LCP Configure-Request packets.
     • If both ends reply with a Configure-Ack packet before the timer for the negotiation times expires, the LCP link is established.
     • If no Configure-Ack packet is received before the timer for the negotiation times expires, LCP negotiation is terminated.
  3. After an LCP link has been established, the Device sends LCP Echo-Request packets to the user at fixed intervals and expects an Echo-Reply packet from the user. This process helps detect whether the LCP link is working normally.

  Table 19-6 LCP response packet types

  LCP Response Packet Type	Description
  Configure-Ack	If the Configuration Options received in a Configure-Request packet are supported and all values are acceptable, the receive end replies with a Configure-Ack packet that carries the same Configuration Options as those in the Configure-Request packet.
  Configure-Nak	If the Configuration Options received in a Configure-Request packet are supported but some values are not acceptable, the receive end replies with a Configure-Nak packet that carries the values it expects. For example, if the Configure-Request packet carries an MRU value 1500, but the receive end expects an MRU value 1492, the receive end fills the MRU value 1492 in the Configure-Nak packet.
  Configure-Reject	If some Configuration Options received in a Configure-Request packet are not supported, the receive end replies with a Configure-Reject packet that carries the unsupported Configuration Options.

  Figure 19-59 LCP negotiation process
  
  

• Authentication stage

  After LCP negotiation is completed, the PPP authentication stage starts. PPP supports two authentication modes: PAP and CHAP.

  PAP authentication

  PAP uses a 2-way handshake to verify the identity of the peer on a P2P link. It transmits a user name and password pair in plaintext, and therefore is applicable to environments with low security requirements. Figure 19-60 shows the PAP authentication process.

  1. The peer sends a user name and password pair to the authenticator.
  2. The authenticator checks whether the user name exists in the local user table.
     • If the user name exists, the authenticator further checks whether the password is correct.
       • If the password is correct, the authenticator sends an Authenticate-Ack packet to the peer, notifying the peer that it is allowed to enter the NCP stage.
       • If the password is incorrect, the authenticator sends an Authenticate-Nak packet to the peer, notifying it of an authentication failure.
     • If the user name does not exist, the authentication fails.

     The link is not immediately terminated after a failed authentication. The authenticator terminates the link only after the number of failed authentication attempts reaches a limit.

  Figure 19-60 PAP authentication process
  

  CHAP authentication

  CHAP uses a 3-way handshake to verify the identity of the peer. CHAP transmits user names but not passwords, and is more secure than PAP. Figure 19-61 shows the CHAP authentication process.

  1. The authenticator initiates an authentication request by sending a Challenge message that carries a random number and the username to the peer.
  2. After receiving the Challenge message, the peer checks whether a CHAP password is configured on the local interface that received the message.
     • If a CHAP password is configured, the peer uses the hash algorithm to calculate the hash value based on the Challenge message ID, configured password, and random number. The peer then sends the authenticator a Response message carrying the hash value and the peer's user name.
     • If no CHAP password is configured, the peer searches the local user table for the password corresponding to the authenticator's user name carried in the Challenge message. The peer uses the hash algorithm to calculate the hash value based on the Challenge message ID, user password, and random number, and then sends the authenticator a Response message carrying the generated hash value and the peer's username.
  3. After receiving the Response message, the authenticator uses the hash algorithm to calculate the hash value based on the locally saved password of the peer and the random number in the Challenge message. The authenticator then compares the calculated hash value with the hash value in the Response message. If they are the same, the authentication succeeds. If not, the authentication fails.

  Figure 19-61 CHAP authentication process
  

• NCP negotiation

  NCP negotiates network-layer parameters in PPP packets. NCP includes the IP Control Protocol (IPCP) and IPv6 Control Protocol (IPv6CP). PPPoE users use IPCP to obtain IP addresses or IP address segments for network access.

  The NCP process is similar to the LCP process. NCP negotiation is successful after the user and Device exchange Configure-Request packets and respond to each other with Configure-Ack packets. The user can access the network after successful NCP negotiation. Figure 19-62 shows the NCP negotiation process.

  Figure 19-62 NCP negotiation process
  

  The following describes IPCP and IPv6CP, which are commonly used in NCP negotiation:

  • IPCP

    IPCP negotiation is implemented based on the PPP state machine. IPCP changes from the Initial or Closed state to the Opened state after both ends complete exchanging configuration information through Configure-Request, Configure-Ack, and Configure-Nak packets. IPCP enters the Opened state only after Configure-Ack packets are sent and received on both ends.

    IPCP negotiation packets can contain multiple options that carry different parameters, such as the IP address, gateway address, and mask. IPCP negotiation can be successful irrespective of whether any option is rejected or fails to be acknowledged. In addition, IPCP supports negotiation by exchanging packets that do not carry any options.

  • IPv6CP

    IPv6CP is a network control protocol that configures, enables, and disables the IPv6 protocol modules on both ends of a point-to-point link. IPv6CP defines two negotiable parameters: interface ID and IPv6 datagram compression protocol. IPv6CP uses the same packet exchange mechanism as LCP. IPv6CP packets can be exchanged only after PPP reaches the network-layer protocol phase. IPv6CP packets that are received before this phase is reached are discarded.

    Currently, only interface IDs can be negotiated on the Device.

    On an IPv6 network, neighbor discovery (ND) or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) must be used to allocate global unicast addresses and configurations to PPP and IPoE users, and the DHCPv6 Identity Association for Prefix Delegation (IA_PD) option must be used to allocate an IPv6 prefix to a routed LAN interface on customer premises equipment (CPE).

A PPPoE session can be established either between devices or between a host and a device.

• When a PPPoE session is established between devices, all hosts transmit data over the same PPP session, without the need to install PPPoE client dialup software. Generally, all users in an enterprise share an account. Figure 19-63 shows the networking of this mode. The CPE is a PPPoE client and located within an enterprise, and a carrier network device is the PPPoE server.

  Figure 19-63 PPPoE networking (1)
  
• When a PPPoE session is established between a host and a device, the session is needed for each host. Each host is a PPPoE client, and a carrier network device is the PPPoE server. Figure 19-64 shows the networking of this mode. Each host has an account for access control and accounting. Each host must have PPPoE client dialup software installed to function as a PPPoE client. This networking applies to campuses and residential areas.

  Figure 19-64 PPPoE networking (2)