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

Fat AP and Cloud AP V200R008C00 CLI-based Configuration Guide

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).
Principles

Principles

This section describes the implementation of PPPoE.

PPP Link Establishment Process

The following figure shows the PPP link establishment process.

Figure 8-1  PPP link establishment process

The PPP link establishment process is as follows:

  1. Two communicating devices enter the Establish phase if one of them initiates a PPP connection request.

  2. In the Establish phase, the two devices perform an LCP negotiation to negotiate the following items: working mode (SP or MP), MRU (Maximum Receive Unit), authentication mode, and magic number (SP is short for single-link PPP and MP is short for MultiLink PPP). If the LCP negotiation succeeds, LCP turns Opened, which indicates that a lower-layer link has been established.

  3. If authentication is configured, the two devices enter the Authenticate phase and perform CHAP or PAP authentication. If no authentication is configured, the two devices enter the Network phase.

  4. In the Authentication phase, if CHAP or PAP authentication fails, the devices enter the Terminate phase. The link is removed and LCP turns Down. If CHAP or PAP authentication succeeds, the devices enter the Network phase and LCP remains Opened.

  5. In the Network phase, the two devices perform an NCP negotiation to select and configure a network protocol and to negotiate network-layer parameters. After the two devices succeed in negotiating a network protocol, packets can be sent over this PPP link using the network protocol.

    Various control protocols such as IPCP and Multiprotocol Label Switching Control Protocol (MPLSCP) can be used in NCP negotiation. IPCP mainly negotiates the IP addresses of the two devices.

  6. After NCP negotiation succeeds, packets can be sent over the PPP link. If the PPP connection is interrupted during PPP operation, the two devices enter the Termination phase, the physical link is disconnected, the PPP authentication fails, or the negotiation timer expires.

  7. In the Termination phase, the two devices enter the Dead phase after all resources are released. The two devices remain in the Dead phase until a new PPP connection is established between them.

The following describes the phases involved in PPP negotiation.

Dead Phase

The physical layer is unavailable during the Dead phase. A PPP link begins and ends with this phase.

When two communicating devices detect that the physical link between them is activated (for example, carrier signals are detected on the physical link), PPP enters the Establish phase from the Dead phase.

After the link is terminated, PPP enters the Dead phase.

Establish Phase

In the Establish phase, the two devices perform an LCP negotiation to negotiate the following items: working mode (SP or MP), MRU, authentication mode, and magic number. After the LCP negotiation is complete, PPP enters the next phase.

In the Establish phase, the LCP status changes as follows:

  • When the link is unavailable (in the Dead phase), LCP is in the Initial or Starting state. When detecting that the link is available, the physical layer sends an Up event to the link layer. After receiving the Up event, the link layer changes the LCP status to Request-Sent. Then the devices at both ends send Configure-Request packets to configure a data link.

  • If the local device first receives a Configure-Ack packet from the peer, the LCP status changes from Request-Sent to Ack-Received. After the local device sends a Configure-Ack packet to the peer, the LCP status changes from Ack-Received to Opened.

  • If the local device first sends a Configure-Ack packet to the peer, the LCP status changes from Request-Sent to Ack-Sent. After the local device receives a Configure-Ack packet from the peer, the LCP status changes from Ack-Sent to Opened.

  • After LCP enters the Opened state, PPP enters the next phase.

The next phase is the Authentication or Network phase, depending on whether authentication is required.

Authentication Phase

The Authentication phase is optional. By default, PPP does not perform authentication during PPP link establishment. If authentication is required, the authentication protocol must be specified in the Establish phase.

PPP authentication is performed on links between hosts and devices that are connected through PPP network servers, switched circuits or dial-up lines, or on dedicated links.

PPP provides two password authentication modes: PAP authentication and CHAP authentication.

Two CHAP authentication modes are available: unidirectional CHAP authentication and bidirectional CHAP authentication. In unidirectional CHAP authentication, the device on one end functions as the authenticating device, and the device on the other end functions as the authenticated device. In bidirectional CHAP authentication, each device functions as both the authenticating device and authenticated device. In practice, only unidirectional CHAP authentication is used.
NOTE:
An AP supports only one-way authentication and serves only as an authenticated device.

PAP Authentication Process

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

Figure 8-2 shows the PAP authentication process.

Figure 8-2  PAP authentication process

  • The authenticated device sends the local user name and password to the authenticating device.

  • The authenticating device checks whether the received user name is in the local user table.
    • If the received user name is in the local user table, the authenticating device checks whether the received password is correct. If so, the authentication succeeds. If not, the authentication fails.
    • If the received user name is not in the local user table, the authentication fails.

CHAP Authentication Process

CHAP is a three-way handshake authentication protocol. CHAP transmits only user names but not passwords, so it is more secure than PAP.

Figure 8-3 shows the CHAP authentication process.

Figure 8-3  CHAP authentication process

Unidirectional CHAP authentication is applicable to two scenarios:
  • The authenticating device is configured with a user name.
  • The authenticating device is not configured with a user name.
It is recommended that the authenticating device be configured with a user name.
  • When the authenticating device is configured with a user name:

    • The authenticating device initiates an authentication request by sending a Challenge packet that carries the local user name to the authenticated device.

    • After receiving the Challenge packet at an interface, the authenticated device checks whether the ppp chap password command is used on the interface. If this command is used, the authenticated device encrypts the Challenge packet with the packet ID and password configured by the command using the Message Digest 5 (MD5) algorithm. Then the authenticated device sends a Response packet carrying the generated cipher text and local user name to the authenticating device. If the ppp chap password command is not configured, the authenticated device searches the local user table for the password matching the user name of the authenticating device in the received Challenge packet, and encrypts the Challenge packet with the packet ID and user password using the MD5 algorithm. Then the authenticated device sends a Response packet carrying the generated cipher text and local user name to the authenticating device.

    • The authenticating device encrypts the Challenge packet with the saved password of the authenticated device using the MD5 algorithm. Then the authenticating device compares the generated cipher text with that carried in the received Response packet, and returns a response based on the result of the check.

  • When the authenticating device is not configured with a user name:

    • The authenticating device initiates an authentication request by sending a Challenge packet.
    • After receiving the Challenge packet, the authenticated device encrypts the Challenge packet with the packet ID and password configured by the ppp chap password command using the MD5 algorithm. Then the authenticated device sends a Response packet carrying the generated cipher text and local user name to the authenticating device.
    • The authenticating device encrypts the Challenge packet with the saved password of the authenticated device using the MD5 algorithm. Then the authenticating device compares the generated cipher text with that carried in the received Response packet, and returns a response based on the result of the check.
Comparison Between CHAP and PAP Authentication Processes
  • In PAP authentication, passwords are sent over links in plain text. After a PPP link is established, the authenticated device repeatedly sends the user name and password until 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 authenticated device sends only the user name to the authenticating device. Compared with PAP, CHAP features higher security because passwords are not transmitted. On networks requiring high security, CHAP authentication is used to establish a PPP connection.

Network Phase

In the Network phase, NCP negotiation is performed to select and configure a network protocol and to negotiate network-layer parameters. Each NCP may be in Opened or Closed state at any time. After an NCP enters the Opened state, network-layer data can be transmitted over the PPP link.

Termination Phase

PPP can terminate a link at any time. A link can be terminated manually by an administrator, or be terminated due to the loss of carrier, an authentication failure, or other causes.

PPPoE Typical Networking

PPPoE uses the client/server model. A PPPoE client sends a connection request to the PPPoE server, and the PPPoE server provides access control and authentication functions for the PPPoE client.

Device Functioning as a PPPoE Client

As shown in Figure 8-4, AP functions as a PPPoE client and connects to users on the downstream LAN. Router is a carrier's device. All hosts in the LAN do not have the PPPoE client dial-up software installed, share the same account, and establish PPPoE sessions with Router through AP.

Figure 8-4  Device functioning as a PPPoE client

PPPoE Dial-up Implementation

During PPPoE dial-up, a PPPoE session is established between a PPPoE client and a PPPoE server, as shown in Figure 8-5.

Figure 8-5  PPPoE dial-up process

The PPPoE dial-up process includes three stages: Discovery, Session, and Terminate.

Discovery Stage

The Discovery stage consists of the following steps:

  1. A PPPoE client broadcasts a PPPoE Active Discovery Initial (PADI) packet that contains service type 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 unicast PPPoE Active Discovery Offer (PADO) packets to the PPPoE client.

  3. The PPPoE client receives PADO packets from more than one PPPoE server. The PPPoE client selects the PPPoE server from which the first PADO packet is received and unicasts a PPPoE Active Discovery Request (PADR) packet to the selected PPPoE server.

  4. The PPPoE server generates a unique session ID to identify the PPPoE session with the PPPoE client, and then sends a PPPoE Active Discovery Session-confirmation (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 established, 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

The PPPoE Session stage involves PPP negotiation and PPP packet transmission.

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

  1. In the LCP phase, the PPPoE server and PPPoE client establish and configure a data link, and verify the data link status.

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

  3. When authentication succeeds, PPP enters the Network Control Protocol (NCP) phase. NCP is a protocol suite used to configure network–layer protocols. A commonly used network-layer protocol is IP Control Protocol (IPCP), which is responsible for configuring IP addresses for users and the domain name server (DNS).

When PPP negotiation succeeds, PPP data packets can be forwarded.

At the PPPoE Session Stage, the PPPoE server and PPPoE client unicast all Ethernet data packets.

Terminate Stage

The PPPoE server and client use PPP to terminate the PPPoE session. If PPP cannot be used, the server and client can use PPPoE Active Discovery Terminate (PADT) packets to terminate the PPPoE session.

After a PPPoE session is established, the PPPoE client or the PPPoE server can unicast a PADT packet to terminate the PPPoE session at any time. After transmitting or receiving the PADT packet, the PPPoE server and PPPoE client are not allowed to use this session to send any PPP traffic.

Translation
Download
Updated: 2019-01-11

Document ID: EDOC1000176006

Views: 117771

Downloads: 309

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