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

Reminder

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

upgrade

NE40E-M2 V800R010C10SPC500 Feature Description - User Access 01

This is NE40E-M2 V800R010C10SPC500 Feature Description - User Access
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).
PPPoE User Login Process

PPPoE User Login Process

The PPPoE user login process involves two stages: PPPoE negotiation and 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.

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 6-1 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 6-1 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 6-1 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 6-2 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 6-1. 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 6-1 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 6-2 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 6-3 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.
      NOTE:

      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 6-3 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 6-4 shows the CHAP authentication process.
    1. The authenticator initiates an authentication request by sending a Challenge packet that carries the local user name to the peer.
    2. After receiving the Challenge packet, the peer checks whether a CHAP password is configured on the local interface that received the packet.
      • If a CHAP password is configured, the peer uses the MD5 algorithm to encrypt the Challenge packet ID and configured password to generate a key, and responds with a Response packet carrying the generated key 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 packet. Then the peer uses the MD5 algorithm to encrypt the Challenge packet ID and password corresponding to the user name to generate a key, and responds with a Response packet carrying the generated key and the peer's user name.
    3. After receiving the Response packet, the authenticator uses the MD5 algorithm to encrypt the Challenge packet ID and the peer's password saved to generate a key. Then the authenticator compares the key with the one it has received. If the two keys are the same, the authentication is successful. If the two keys are different, the authentication fails.
    Figure 6-4 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 6-5 shows the NCP negotiation process.

    Figure 6-5 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 two 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 6-6 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 6-6 PPPoE networking 1
  • When a PPPoE session is established between a host and a device, it is needed for each host. Each host is a PPPoE client, and a carrier network device is the PPPoE server. Figure 6-7 shows the networking of this mode. Each host has an account for access control and accounting. Each host must have the PPPoE client dialup software installed to function as a PPPoE client. This networking applies to campuses and residential areas.
    Figure 6-7 PPPoE networking 2
Download
Updated: 2019-01-02

Document ID: EDOC1100058415

Views: 13544

Downloads: 9

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