No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


S12700 V200R011C10 Configuration Guide - User Access and Authentication

This document describes the working mechanisms, configuration procedures, and configuration examples of User Access and Authentication features, such as AAA, DAA, NAC, PPPoE, Policy Association, and IP session.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Understanding PPPoE

Understanding PPPoE

Based on the client/server model, PPPoE encapsulates PPP packets in Ethernet frames, and provides point-to-point connections on the Ethernet.

The PPPoE session establishment process includes three stages: Discovery, Session, and Terminate.

Figure 7-1 shows the process of establishing a PPPoE session.

Figure 7-1  PPPoE session establishment process

Discovery Stage

Figure 7-2 shows the Discovery stage implements PPPoE authentication and negotiation, including the following steps:
Figure 7-2  PPPoE negotiation process

  1. A PPPoE client broadcasts a PADI packet that contains service information required by the PPPoE client.

  2. After receiving the PADI packet, all PPPoE servers compare the requested service with the services they can provide. The PPPoE servers that can provide the requested service sends PADO packets to the PPPoE client in unicast mode.

  3. The PPPoE client receives PADO packets from more than one PPPoE server. The PPPoE client selects one from these PPPoE servers and sends a PADR packet to the selected PPPoE server in unicast mode.

  4. The PPPoE server generates a unique session ID to identify the PPPoE session with the PPPoE client, and then sends a PADS packet containing this session ID to the PPPoE client. When the PPPoE session is established, the PPPoE server and PPPoE client enter the PPPoE Session stage.

After the PPPoE session is complete, the PPPoE server and client learn the session ID and the peer Ethernet address. Therefore, the PPPoE server has a unique PPPoE session with the client.

Session Stage

In the Discovery stage, the client and server sets up a session. In the Session stage, they start PPPoE authentication and negotiation, and transmit PPP packets.

PPP negotiation process at the PPPoE Session stage is the same as common PPP negotiation process, which includes the LCP, authentication, and NCP phases.

  • LCP negotiation

    In the LCP phase, the PPPoE server and client establish and configure a data link, and verify the data link status. The LCP negotiation process is as follows: The server and client exchange a Config-Request packet and check the negotiation options in the packet. Then they respond a packet depending on whether they accept the options. If both ends respond with a Config-ACK packet, the LCP link is set up successfully; otherwise, the two ends continue to send Config-Request packets till both of them respond with Config-ACK.
    Figure 7-3  LCP negotiation process

  • Authentication

    When LCP negotiation is complete, authentication starts. The authentication protocol can be Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP), which depends on the LCP negotiation result.

    PAP authentication

    The PAP is a two-way handshake authentication protocol that transmits passwords in plain text.

    Figure 7-4 shows the PAP authentication process.

    Figure 7-4  PAP authentication process

    • The PPPoE client sends the local user name and password to the PPPoE server.

    • The PPPoE server checks whether the user name exists in the local user table.
      • If the user name exists, the PPPoE server checks whether the password is correct. If the password is correct, the authentication is successful; otherwise, the authentication fails.
      • If the user name does not exist, the authentication fails.

    CHAP authentication

    CHAP is a three-way handshake authentication protocol. It transmits encrypted passwords, so it is more secure than PAP.

    Figure 7-5 shows the CHAP authentication process.

    Figure 7-5  CHAP authentication process

    • The PPPoE server sends an authentication request (a Challenge packet randomly generated by the server) to the PPPoE client.
    • The PPPoE client encrypts the authentication request packet by using the packet ID, CHAP password, and MD5 checksum, and then returns the encrypted packet and its own user name (Response) to the server.
    • The PPPoE server encrypts the random packet by using the client's password saved locally and MD5 checksum and compare the encrypted packet with the packet returned by the client. If the packets are the same, the authentication is successful; otherwise, the authentication fails.
    Comparison between CHAP and PAP authentications
    • In a PAP authentication, passwords are sent over links in plain text. After a PPP link is established, the client repeatedly sends the user name and password until the authentication finishes. This mode cannot ensure high security, so it is used on networks that do not require high security.

    • CHAP is a three-way handshake authentication protocol. In CHAP authentication, the client sends only the user name on the network. Compared with PAP, CHAP features higher security because passwords are not transmitted. The CHAP authentication can be selected for networks.

  • NCP

    After the authentication is successful, PPP enters the NCP phase. The NCP phase implements network parameter negotiation, including IP addresses, DNS server addresses, WINS server addresses.

    NCP negotiation supports multiple protocols, for example IPCP and BCP. IPCP is most widely used. IPCP allows PPPoE clients to obtain IP addresses or IP address segment for network access.

    IPCP negotiation is based on PPP state machine. The server and client exchange Configure-Request, Configure-ACK, and Configure-Rej packets during the negotiation. When both the server and client have sent and received Configure-ACK packets, the PPP status can change from Initial (or Closed) to Opened.

    An IPCP negotiation packet carries multiple options, namely, parameters. Whether the options are accepted or rejected does not affect the IPCP negotiation result. The IPCP negotiation can be Up even if no option is used. The options include IP address, gateway, and mask. The devices of some vendors require that the IP address option must be accepted; however, the devices of most vendors allow this option to be empty.

    The NCP negotiation is similar to LCP negotiation. In NCP negotiation, the server and client exchange NCP packets. When the two ends respond with ACK packets, NCP negotiation is successful. Users can go online and access networks.

    Figure 7-6 shows the NCP negotiation process.

    Figure 7-6  NCP negotiation process

When PPP negotiation succeeds, PPP data packets can be forwarded over the established PPP link. At the PPPoE Session Stage, the PPPoE server and client send all Ethernet data packets in unicast mode.

Terminate Stage

The PPPoE server and client use PPP protocol packets to terminate the PPPoE session. When PPP cannot be used, the server and client can use PADT packets to terminate the PPPoE session.

In the Session stage, the client and server exchange PADT packets to close the PPPoE connection. The PADT packets can be sent anytime after a session is established to indicate that the session has been terminated. When a PADT packet is received, no further PPP traffic can be sent using this session.

User Group Authorization

The device can authorize users based on the user group. After users are authenticated, the authentication server groups users together. Each user group is bound to an ACL so that users in the same user group share an ACL.

Updated: 2019-10-21

Document ID: EDOC1000178117

Views: 120044

Downloads: 55

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Previous Next