CX600 - Feature Description - User Access

HUAWEI CX600 Metro Services Platform
V600R002
Feature Description - User
Access
Issue 01
Date 2010-06-25
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2010. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Huawei Proprietary and Confidential

Issue 01 (2010-06-25) i
Copyright © Huawei Technologies Co., Ltd.
Feature Description - User Access About This Document
About This Document
Intended Audience
This document describes the User access feature in terms of its overview, principle, and
applications.
This document together with other types of document helps intended readers get a deep
understanding of the User access feature.
This document is intended for:
Network planning engineers
Commissioning engineers
Data configuration engineers
System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not
avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk,

which if not avoided, could result in minor or moderate
injury.
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save
time.
Provides additional information to emphasize or
supplement important points of the main text.
Issue 01 (2010-06-25) Huawei Proprietary and Confidential iii

About This Document Feature Description - User Access
Change History
Updates between document issues are cumulative. Therefore, the latest document issue
contains all updates made in previous issues.
None.
Changes in Issue 01 (2010-06-25)

Initial field trial release.
iv Huawei Proprietary and Confidential Issue 01 (2010-06-25)

Feature Description - User Access Contents
Contents
About This Document ................................................................................................................... iii

1 AAA and User Management ....................................................................................................1-1
1.1 Introduction to AAA and User Management ................................................................................................. 1-1
1.2 References ..................................................................................................................................................... 1-3
1.3 Availability .................................................................................................................................................... 1-4
1.4 Enhancement ................................................................................................................................................. 1-4
1.5 Principles ....................................................................................................................................................... 1-4
1.5.1 AAA ..................................................................................................................................................... 1-4
1.5.2 RADIUS............................................................................................................................................... 1-7
1.5.3 HWTACACS ..................................................................................................................................... 1-10
1.5.4 User management ............................................................................................................................... 1-11
1.6 Applications................................................................................................................................................. 1-16
1.6.1 RADIUS Authentication and Accounting .......................................................................................... 1-16
1.6.2 HWTACACS Authentication, Accounting, and Authorization .......................................................... 1-16
1.7 Impact.......................................................................................................................................................... 1-17
1.7.1 On the System Performance ............................................................................................................... 1-17
1.7.2 On Other Features .............................................................................................................................. 1-17
1.7.3 Defects ............................................................................................................................................... 1-17
1.8 Terms and Abbreviations ............................................................................................................................. 1-17
2 Plug-and-Play ..............................................................................................................................2-1
2.1 Introduction to Plug-and-Play ....................................................................................................................... 2-1
2.2 References ..................................................................................................................................................... 2-2
2.3 Availability .................................................................................................................................................... 2-2
2.4 Principles ....................................................................................................................................................... 2-2
2.4.1 Principle of DHCP ............................................................................................................................... 2-2
2.4.2 Operation Principle of a DHCP Client ................................................................................................. 2-3
2.4.3 Operation Process of PnP ..................................................................................................................... 2-4
2.5 Applications................................................................................................................................................... 2-6
2.6 Impact............................................................................................................................................................ 2-6
2.6.1 Impact on the System Performance ...................................................................................................... 2-6
2.6.2 Impact on Other Features ..................................................................................................................... 2-6
2.6.3 Defects ................................................................................................................................................. 2-7
Issue 01 (2010-06-25) Huawei Proprietary and Confidential v

Contents Feature Description - User Access
2.7 Terms and Abbreviations ............................................................................................................................... 2-7
3 L2TP Access .................................................................................................................................3-1

3.1 Introduction ................................................................................................................................................... 3-1
3.2 References ..................................................................................................................................................... 3-4
3.3 Availability .................................................................................................................................................... 3-5
3.4 Enhancement ................................................................................................................................................. 3-5
3.5 Principles ....................................................................................................................................................... 3-5
3.5.1 L2TP Protocol Structure....................................................................................................................... 3-6
3.5.2 L2TP Header ........................................................................................................................................ 3-6
3.6 Applications................................................................................................................................................. 3-16
3.7 Impact.......................................................................................................................................................... 3-19
3.7.3 Defects ............................................................................................................................................... 3-19
4 IPoEv4 ...........................................................................................................................................4-1
4.1 Introduction to IPoE ...................................................................................................................................... 4-1
4.2 References ..................................................................................................................................................... 4-2
4.3 Availability .................................................................................................................................................... 4-2
4.4 Feature Enhancement .................................................................................................................................... 4-2
4.5 Principles ....................................................................................................................................................... 4-2
4.5.1 Basic Principle of IPoEv4 .................................................................................................................... 4-3
4.5.2 Basic Principle of DHCP ..................................................................................................................... 4-5
4.6 Applications................................................................................................................................................. 4-11
4.7 Impact.......................................................................................................................................................... 4-18
4.7.1 Impact on the System Performance .................................................................................................... 4-18
4.7.2 Impact on Other Features ................................................................................................................... 4-18
4.7.3 Defects ............................................................................................................................................... 4-18
5 IPoEv6 ...........................................................................................................................................5-1
5.1 Introduction to IPoEv6 .................................................................................................................................. 5-1
5.2 References ..................................................................................................................................................... 5-2
5.3 Availability .................................................................................................................................................... 5-2
5.4 Enhancement ................................................................................................................................................. 5-3
5.5 Principles ....................................................................................................................................................... 5-3
5.5.1 Principles of Stateless Address Autoconfiguration............................................................................... 5-3
5.5.2 Principles of DHCPv6 Access .............................................................................................................. 5-4
5.5.3 Principles of IPoEv6 Access ................................................................................................................ 5-8
5.5.4 ND Proxy ............................................................................................................................................. 5-9
5.6 Applications................................................................................................................................................. 5-10
5.7 Impact.......................................................................................................................................................... 5-16
vi Huawei Proprietary and Confidential Issue 01 (2010-06-25)

Feature Description - User Access Contents

5.7.3 Defects ............................................................................................................................................... 5-16
6 PPPoE Access ..............................................................................................................................6-1

6.1 Introduction ................................................................................................................................................... 6-1
6.2 References ..................................................................................................................................................... 6-3
6.3 Availability .................................................................................................................................................... 6-3
6.4 Principles ....................................................................................................................................................... 6-4
6.4.1 Process of a PPPoE User Going Online ............................................................................................... 6-4
6.4.2 PPP State Machine ............................................................................................................................... 6-9
6.4.3 PPP Packet Format ............................................................................................................................. 6-12
6.5 Applications................................................................................................................................................. 6-15
6.6 Impact.......................................................................................................................................................... 6-18
6.6.3 Other Defects ..................................................................................................................................... 6-19
7 802.1x Access ...............................................................................................................................7-1

7.1 Introduction to 802.1x Access ....................................................................................................................... 7-1
7.2 References ..................................................................................................................................................... 7-2
7.3 Availability .................................................................................................................................................... 7-2
7.4 Feature Enhancement .................................................................................................................................... 7-2
7.5 Principle ........................................................................................................................................................ 7-3
7.5.1 Basic Principle of 802.1x Access ......................................................................................................... 7-3
7.5.2 Authentication Initiation and User Logoff ........................................................................................... 7-4
7.5.3 EAP Packet Relaying and Termination ................................................................................................ 7-5
7.5.4 Basic Process of the IEEE 802.1x Authentication System ................................................................... 7-5
7.5.5 Basic Process of EAP-PEAP Authentication for Secure and Encrypted WLAN Access Through WPA
...................................................................................................................................................................... 7-7
7.6 Applications................................................................................................................................................... 7-8
7.7 Impact.......................................................................................................................................................... 7-10
7.7.1 Impact on the System Performance .................................................................................................... 7-10
7.7.2 Impact on Other Features ................................................................................................................... 7-10
7.7.3 Defects ............................................................................................................................................... 7-10
8 WLAN ...........................................................................................................................................8-1
8.1 Introduction to WLAN .................................................................................................................................. 8-1
8.2 References ..................................................................................................................................................... 8-7
8.3 Availability .................................................................................................................................................... 8-8
8.4 Principles ....................................................................................................................................................... 8-9
Issue 01 (2010-06-25) Huawei Proprietary and Confidential vii

Contents Feature Description - User Access
8.4.1 AP Management ................................................................................................................................... 8-9

8.4.2 RF Management ................................................................................................................................. 8-16
8.4.3 Service Set Management (ESS Profile) ............................................................................................. 8-20
8.4.4 Configuration Auto-Provisioning Management ................................................................................. 8-21
8.4.5 Centralized BSSID Management ....................................................................................................... 8-21
8.4.6 Load Balancing .................................................................................................................................. 8-22
8.4.7 WLAN STA Roaming ........................................................................................................................ 8-22
8.4.8 WLAN Access Security ..................................................................................................................... 8-25
8.4.9 QoS .................................................................................................................................................... 8-31
8.5 Applications................................................................................................................................................. 8-33
8.6 Impact.......................................................................................................................................................... 8-36
8.6.3 Defects ............................................................................................................................................... 8-37
viii Huawei Proprietary and Confidential Issue 01 (2010-06-25)

Feature Description - User Access Figures
Figures
Figure 1-1 Format of a RADIUS message ......................................................................................................... 1-7

Figure 1-2 Process of exchanging RADIUS messages between the RADIUS server and client........................ 1-8
Figure 1-3 Process of command-line authorization in HWTACACS ............................................................... 1-11

Figure 1-4 Network diagram of RADIUS authentication and accounting........................................................ 1-16
Figure 1-5 Networking diagram of HWTACACS authentication, accounting, and authorization ................... 1-17
Figure 2-1 Operation principle of a DHCP client ............................................................................................... 2-4
Figure 2-2 Operation process of PnP .................................................................................................................. 2-5
Figure 2-3 Network diagram of obtaining a management IP address and starting a management channel ........ 2-6
Figure 3-1 VPDN model based on L2TP ........................................................................................................... 3-2
Figure 3-2 L2TP protocol structure .................................................................................................................... 3-6
Figure 3-3 Format of an L2TP message header .................................................................................................. 3-6
Figure 3-4 Format of an L2TP data message ...................................................................................................... 3-8
Figure 3-5 Diagram of the three-way handshake during the establishment of a control connection .................. 3-9
Figure 3-6 Diagram of the process of establishing a session connection ......................................................... 3-10
Figure 3-7 Diagram of tearing down an L2TP session connection................................................................... 3-10

Figure 3-8 Diagram of tearing down an L2TP control connection ................................................................... 3-11
Figure 3-9 Networking diagram of an L2TP tunnel ......................................................................................... 3-12
Figure 3-10 Flowchart of establishing an L2TP tunnel call ............................................................................. 3-13

Figure 3-11 Networking diagram of L2TP tunnel switching ............................................................................ 3-15
Figure 3-12 Two typical L2TP tunnel modes ................................................................................................... 3-16
Figure 3-13 Users accessing the LAC through a router.................................................................................... 3-17
Figure 3-14 Users accessing the LAC through a router.................................................................................... 3-18
Figure 3-15 Application of IPv6 network access through L2TP on the carrier's network ................................ 3-19
Figure 4-1 Structure of the IPoX protocol stack ................................................................................................. 4-5

Figure 4-2 DHCP packet exchange .................................................................................................................... 4-5
Figure 4-3 DHCP packet format ......................................................................................................................... 4-7
Issue 01 (2010-06-25) Huawei Proprietary and Confidential ix

Figures Feature Description - User Access
Figure 4-4 Networking diagram of local address allocation for Layer 2 access users ..................................... 4-12
Figure 4-5 Login process through a DHCP packet ........................................................................................... 4-12

Figure 4-6 Networking diagram of remote address allocation for a Layer 2 access user ................................. 4-14
Figure 4-7 Remote login of a DHCP user ........................................................................................................ 4-15
Figure 4-8 Networking diagram of Layer 3 access users adopting Web authentication ................................... 4-15
Figure 4-9 Networking diagram of Layer 3 DHCP users ................................................................................. 4-16
Figure 4-10 Networking diagram of Layer 2 leased line access ....................................................................... 4-17
Figure 4-11 Networking diagram of Layer 3 leased line access ....................................................................... 4-17
Figure 4-12 Networking diagram of Layer 2 VPN leased line access .............................................................. 4-18
Figure 5-1 Principle of ND proxy .................................................................................................................... 5-10
Figure 5-2 Networking diagram of IPv6oE user access ................................................................................... 5-11

Figure 5-3 Networking diagram for access of a Layer 2 IPv6 user running ND .............................................. 5-11
Figure 5-4 Networking diagram for access of an IPv4/IPv6 dual-stack user running DHCPv4 and ND ......... 5-12
Figure 5-5 Networking diagram for access of a Layer 2 IPv6 user running DHCPv6 ..................................... 5-13
Figure 5-6 Networking diagram for access of an IPv4/IPv6 dual-stack User running DHCPv4 and DHCPv65-13
Figure 5-7 Networking diagram for access of a Layer 3 IPv6 User Running DHCPv6 ................................... 5-14
Figure 5-8 Networking diagram for access of Layer 2 IPv6 users through a routed HG ................................. 5-14
Figure 5-9 Networking diagram for access of Layer 2 IPv4/IPv6 dual-stack users through a routed HG ....... 5-15
Figure 5-10 Schematic diagram of communication between users with the same prefix through the BRAS .. 5-16
Figure 6-1 PPP in the protocol stack .................................................................................................................. 6-2
Figure 6-2 PPPoE negotiation process ............................................................................................................... 6-4
Figure 6-3 LCP negotiation process ................................................................................................................... 6-5
Figure 6-4 PAP authentication process ............................................................................................................... 6-6
Figure 6-5 CHAP authentication process ........................................................................................................... 6-7
Figure 6-6 NCP negotiation process ................................................................................................................... 6-8
Figure 6-7 Access process of a PPP user ............................................................................................................ 6-8

Figure 6-8 State transition ................................................................................................................................ 6-11
Figure 6-9 Format of a PPP packet ................................................................................................................... 6-12
Figure 6-10 Typical networking model of PPPoE services .............................................................................. 6-16

Figure 6-11 Typical networking model of PPPoEoV services .......................................................................... 6-16
Figure 6-12 Typical networking model of PPPoEoQ services ......................................................................... 6-17
Figure 6-13 Typical networking model of PPPoA services .............................................................................. 6-17

Figure 6-14 Typical networking model of PPPoEoA services .......................................................................... 6-18
x Huawei Proprietary and Confidential Issue 01 (2010-06-25)

Feature Description - User Access Figures
Figure 6-15 Typical networking of PPPv6 user access ..................................................................................... 6-18
Figure 7-1 Architecture of the 802.1x authentication system ............................................................................. 7-3

Figure 7-2 Protocol structure of the 802.1x authentication system .................................................................... 7-4
Figure 7-3 Basic process of the IEEE 802.1x authentication system (1) ............................................................ 7-6
Figure 7-4 Basic process of the IEEE 802.1x authentication system (2) ............................................................ 7-7
Figure 7-5 Basic process of IEEE 802.1x EAP-PEAP authentication ................................................................ 7-8
Figure 7-6 Typical networking diagram for 802.1x access................................................................................. 7-9
Figure 7-7 Networking diagram for 802.1XoEoV access .................................................................................. 7-9

Figure 7-8 Networking diagram for 802.1XoEoQ access .................................................................................. 7-9
Figure 7-9 Networking diagram of WLAN access ........................................................................................... 7-10
Figure 8-1 Centralized WLAN architecture ....................................................................................................... 8-3

Figure 8-2 RF management process ................................................................................................................... 8-4
Figure 8-3 Quick WLAN STA roaming ............................................................................................................. 8-5
Figure 8-4 Flowchart of AC auto-discovery ..................................................................................................... 8-10
Figure 8-5 Topology of the AC and the AP ...................................................................................................... 8-10
Figure 8-6 Registration flowchart of the AP obtaining an AC IP address through the DHCP server ............... 8-11
Figure 8-7 Registration flowchart of the AP obtaining an AC IP address through the DNS server.................. 8-12
Figure 8-8 Channel forwarding mode .............................................................................................................. 8-15
Figure 8-9 Direct forwarding mode .................................................................................................................. 8-15
Figure 8-10 Principle of CAPWAP .................................................................................................................. 8-16
Figure 8-11 Power decrease.............................................................................................................................. 8-18
Figure 8-12 Power increase .............................................................................................................................. 8-19
Figure 8-13 4-way handshake during the AC's processing quick roaming ....................................................... 8-23
Figure 8-14 Fast roaming by a STA within a same AC .................................................................................... 8-24
Figure 8-15 Process of OPEN-SYS authentication .......................................................................................... 8-25
Figure 8-16 Process of shared key authentication ............................................................................................ 8-26

Figure 8-17 Process of WAPI authentication and encryption ........................................................................... 8-29
Figure 8-18 Process of 802.1x authentication based on EAP-TLS .................................................................. 8-31
Figure 8-19 WLAN access solution ................................................................................................................. 8-34

Figure 8-20 Networking diagram of the scheme of channel access across the Layer 2 network ..................... 8-35
Figure 8-21 Networking diagram of the scheme of direct access across the Layer 2 network ......................... 8-36
Issue 01 (2010-06-25) Huawei Proprietary and Confidential xi

Feature Description - User Access Tables
Tables
Table 1-1 Comparisons between HWTACACS and RADIUS ......................................................................... 1-10

Table 1-2 Default domains of the CX600 ......................................................................................................... 1-12
Table 3-1 Description of fields in an L2TP message header............................................................................... 3-6

Table 4-1 Usages of DHCP options .................................................................................................................. 4-10
Table 4-2 Default values of timers .................................................................................................................... 4-10
Table 6-1 Common protocol codes ................................................................................................................... 6-13
Table 6-2 Common code values........................................................................................................................ 6-14
Table 8-1 Description of parameters of service set management ..................................................................... 8-20
Table 8-2 Carrier ID ......................................................................................................................................... 8-21
Table 8-3 AC ID ............................................................................................................................................... 8-22
Table 8-4 Parameters of the WMM profile ....................................................................................................... 8-32
Table 8-5 Parameters of the traffic profile ........................................................................................................ 8-33
Issue 01 (2010-06-25) Huawei Proprietary and Confidential xiii

Feature Description - User Access 1 AAA and User Management
1 AAA and User Management
About This Chapter

1.1 Introduction to AAA and User Management
1.2 References
1.3 Availability
1.4 Enhancement
1.5 Principles
1.6 Applications
1.7 Impact
1.8 Terms and Abbreviations
1.1 Introduction to AAA and User Management

Definition
AAA, short for Authentication, Authorization, and Accounting, provides the following types
of security functions:
Authentication: determines the users who can access the network.
Authorization: authorizes users to use specific services.
Accounting: records the utilization of network resources.
The CX600 implements AAA through the Remote Authentication Dial in User Service
(RADIUS) protocol or the Huawei Terminal Access Controller Access Control System
(HWTACACS) protocol.
RADIUS
RADIUS is one of the most commonly used protocols to implement AAA. As an
application-layer protocol running between the CX600 and a RADIUS server, RADIUS
defines the procedure for transmitting user information and accounting information
between theCX600 and the RADIUS server and the format of packets exchanged
between them.
Issue 01 (2010-06-25) Huawei Proprietary and Confidential 1-1

1 AAA and User Management Feature Description - User Access
HWTACACS
AAA can also be implemented through HWTACACS. HWTACACS is the enhancement
of TACACS that is an access control protocol defined in RFC 1492. Similar to RADIUS,
HWTACACS adopts the client/server model to communicate with the HWTACACS
server, thus implementing AAA for various users, including Point-to-Point Protocol (PPP)
users, Virtual Private Dial Network (VPDN) users, and login users.
User management
A broadband remote access server (BRAS) is used to manage access users. Currently, the
BRAS manages users in the following modes:
− Domain-based user management
All users belong to a same domain. By default, users are added to a default domain.
The BRAS manages users by configuring service attributes for a domain. Thus, the
users in the same domain have the same service attributes.
− User account-based user management
User accounts and related service attributes are configured on an AAA server such as
the RADIUS server or the HWTACACS server, and are then delivered to users when
the users get online or dynamically delivered to users after the users get online.
In actual applications (except the applications of non-authentication and non-accounting) on
the CX600, all user accounts must be configured on an AAA server, and all the domains to
which the user accounts belong must be configured on the CX600. The CX600 supports the
configuration and management of local user accounts.
Commonly, the service attributes configured in a domain have a lower priority than the
service attributes delivered by an AAA server. Therefore, when service attributes are
configured in a domain and are also delivered by an AAA server, the CX600 adopts the
service attributes that are delivered by the AAA server. The service attributes configured in a
domain take effect only when the AAA server does not support or deliver the service
attributes.
Purpose
The CX600 implements AAA through either RADIUS or HWTACACS.
The CX600 supports domain-based or user account-based user management and supports
multiple authentication and accounting policies.
By authorizing and managing user attributes, the CX600 implements the enhanced the user
management function, including user bandwidth control, access authority control, and QoS
attribute control.
Benefits
This feature brings the following benefits to operators:
Access users are identified to guarantee legal service access.
Authorities of access users are controlled through domain-based or user account-based
user management.
The reliability of access user accounting is ensured through the RADIUS or
HWTACACS accounting protocol and the local accounting function in case of the
remote accounting failure.
1-2 Huawei Proprietary and Confidential Issue 01 (2010-06-25)

1.2 References
Document Description
RFC 2903 Generic AAA Architecture
RFC 2904 AAA Authorization Framework
RFC 2905 AAA Authorization Application Examples
RFC 2906 AAA Authorization Requirements
RFC 2989 Criteria for Evaluating AAA Protocols for Network Access
RFC 3539 Authentication, Authorization and Accounting (AAA)
RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS
RFC 2865 Remote Authentication Dial In User Service (RADIUS) (June
2000)
RFC 2866 RADIUS Accounting (June 2000)
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support
RFC 2868 RADIUS Attributes for Tunnel Protocol Support
RFC 2869 RADIUS Extensions (June 2000)
RFC 2882 Network Access Servers Requirements: Extended RADIUS
Practices
RFC 3162 RADIUS and IPv6
RFC 3575 IANA Considerations for RADIUS (Remote Authentication Dial
In User Service)
RFC 3579 RADIUS (Remote Authentication Dial In User Service) Support
For Extensible Authentication Protocol (EAP)
RFC 3580 IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines
RFC 4014 Remote Authentication Dial-In User Service (RADIUS) Attributes
Suboption for the Dynamic Host Configuration Protocol (DHCP)
Relay Agent Information Option
RFC 0927 TACACS user identification Telnet option
RFC 1492 An Access Control Protocol, Sometimes Called TACACS (July
1993)

1.3 Availability
Involved Network Element
None.
License Support
None.
Version Support
Product Version
CX600 V600R002
Feature Dependency
None.
1.4 Enhancement
Version Feature Enhancement
V600R002 PPPoE access and L2TP access are added.
1.5 Principles
1.5.1 AAA
1.5.2 RADIUS
1.5.3 HWTACACS
1.5.4 User management
1.5.1 AAA
Authentication
The CX600 supports the following authentication modes. The three modes can be used in
combination.
Non-authentication
In this mode, users are completely trusted without the check on their validity. This mode
is rarely used.

Local authentication
In this mode, user information, including the user name, password, and attributes, is
configured on the CX600. This mode features fast processing speed and low operation
costs. The major limitation is that the information storage capacity is subject to the
capacity of device hardware.
Remote authentication
In this mode, user information, including the user name, password, and attributes, is
configured on an authentication server. The CX600 supports remote authentication
through RADIUS or HWTACACS. As a client, the CX600 communicates with the
RADIUS or HWTACACS server. The RADIUS protocol can be either a standard
RADIUS protocol or an extended RADIUS protocol of Huawei, that is, RADIUS+V1.0
or RADIUS+V1.1.
First local authentication and later remote authentication
It is a local-authentication-preferred policy. That is, remote authentication is performed
only after local authentication fails.
First remote authentication and later local authentication
It is a remote-authentication-preferred policy. That is, local authentication is performed
only after the AAA server gives no response.
First remote authentication and later non-authentication
It is also a remote-authentication-preferred policy. That is, non-authentication is
performed only after the AAA server gives no response.
Authorization
The CX600 supports user authorization during user login as well as dynamic authorization for
online users. During user login, the CX600 supports various types of authorization schemes.
Authorization during user login
The CX600 supports the following authorization modes during user login:
− Direct authorization
In this mode, users are completely trusted and directly authorized.
− Local authorization
In this mode, users are authorized based on the attributes of local user accounts
configured on the CX600.
− HWTACACS authorization
In this mode, users are authorized through a HWTACACS server.
− If-authenticated authorization
In this mode, users pass the authorization after passing authentication (not in
non-authentication mode).
− RADIUS authorization
RADIUS integrates authentication and authorization. Therefore, RADIUS
authorization cannot be performed independently.
Authorization for online users
The CX600 supports dynamic authorization for online users.
In dynamic authorization, attributes such as the user group, committed access rate (CAR),
and policy name, are re-configured on the AAA server. The AAA server then delivers the
attributes to the AAA module through Change of Authorization (CoA) packets and the

AAA module dynamically updates the users' authorization information. For description
about CoA packets, refer to RFC 3576.
Accounting
Accounting mode
AAA supports the following accounting modes:
− Non-accounting
Free services are provided.
− Remote accounting
The CX600 supports remote accounting through an AAA server.
− Local accounting protection
The CX600 supports the local accounting protection function to avoid bill loss or
error bills when a link fault occurs (for example, the AAA server is disconnected).
When the AAA server fails to charge users, user bills are saved locally. Later, when
the AAA server recovers, the CX600 uploads the locally saved bills to the accounting
server through the Trivial File Transfer Protocol (TFTP).
There must be a local bill pool before you can implement the local accounting
protection function on the CX600. The local accounting protection function does not
take effect in the absence of a local bill pool. You can create or delete a local bill pool
through commands. Note that after the local bill pool is deleted, the locally saved
bills are also deleted correspondingly and the CX600 cannot automatically back up
the bills to a bill server.
− Real-time accounting
During real-time accounting for online users, the CX600 periodically generates
accounting packets and then sends them to a remote accounting server. Real-time
accounting is also a bill protection measure. It furthest reduces error bills and ensures
accuracy of accounting information in case of a link failure.
Working together with an AAA server, the CX600 also supports the time-based
pre-paid service and traffic-based pre-paid service. It also supports charge rate
switching and charge discounting functions. Then, users are accounted at different
charge rates based on their access types.
Accounting failure policy
The CX600 supports the configuration of a remote accounting failure policy. Remote
accounting failure policies include:
− Policy for start-accounting failures
When start-accounting fails,
− If the policy is set to "offline", the user cannot go online.
− If the policy is set to "online", the user remains online but no real-time accounting
packets can be exchanged between the user and the AAA server, even though the
AAA server gives a response again. The user still needs to send an accounting packet
to the AAA server for going offline. If the AAA server fails to charge the user, the
user bill is saved locally.
− Policy for real-time accounting failures
When real-time accounting fails,
− If the policy is set to “offline”, the CX600 terminates user access and saves the
offline bills locally.

− If the policy is set to "online", the user remains online and sends real-time accounting
packets to the AAA server. If the user needs to go offline, it sends an accounting
packet to the AAA server. When the AAA server fails to charge the user, the user bill
is saved locally.
− Policy for remote offline-accounting failures
When a user goes offline and the AAA server fails in accounting, the user bill is
saved locally; if the local bill pool is full, the bill is lost.
Accounting packet copy
Accounting packet copy indicates that during accounting, accounting packets are sent to
two AAA servers synchronously for separate accounting. This function is used when the
original accounting information need be saved on multiple devices, for example, in the
scenario of the multi-operator networking. In this case, the accounting packets are sent to
two AAA servers and are used as original accounting information in subsequent bill
accounting.
There are the following accounting packet copy modes:
− Physical accounting
For physical accounting, an accounting copy server is configured on the BAS
interface for user access. After the user logs in, the CX600 searches for the
accounting copy server based on the user access interface and VLAN information and
then copies the accounting packets to this accounting server.
− Two-level accounting
For two-level accounting, a main accounting server and an accounting copy server
are configured for a domain. During accounting, the main accounting server copies
the accounting packets to the accounting copy server.
1.5.2 RADIUS
Format of a RADIUS Message
Figure 1-1 shows the format of a RADIUS message.
Figure 1-1 Format of a RADIUS message
0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7

1 Code Identifier Length
2
3
Authenticator
4
5
6 Attribute
The meaning of each field is described as follows:

Code: indicates the message type, such as the access request, access permission, and
accounting request.
Identifier: is a string of numbers in ascending order for matching the request and
response packets.

Length: indicates the total length of all fields.

Authenticator: is used for checking the validity of a RADIUS message.
Attribute: indicates the contents of a message, describing user attributes.
Process of Exchanging RADIUS Messages

The RADIUS server builds a unique database to store user names and passwords that are
required for authentication. To obtain the right to access certain networks or to use certain
network resources, a user needs to set up a connection with the CX600 through a device. In
this case, the CX600 functions in authenticating the user and connecting the user and the
device.
The CX600 is responsible for sending AAA information about the user to the RADIUS server.
RADIUS prescribes how to transmit user information and accounting information between the
CX600 and the RADIUS server. The RADIUS server receives connection requests from users,
authenticates users, and then sends the required configuration information back to the CX600.
The authentication information between the CX600 and the RADIUS server is transmitted
with a key. This protects the user password from theft on an insecure network. Figure 1-2
shows the process of exchanging RADIUS messages between the RADIUS server and client.
Figure 1-2 Process of exchanging RADIUS messages between the RADIUS server and client
1.User name
password 2.Request
3.Response
User CX600 RADIUS sever
1. A user initiates authentication and sends a user name and password to the CX600.
2. After the RADIUS client configured on the CX600 receives the user name and password,
it sends an authentication request to the RADIUS server.
3. If the request is valid, the RADIUS server completes the authentication and sends the
required authorization information back to the RADIUS client.
Authentication information is encrypted before being transmitted between the RADIUS client
and RADIUS server. This prevents theft of information on an insecure network.
The process of exchanging accounting messages is similar to that of exchanging
authentication or authorization messages.
Features of RADIUS
RADIUS adopts the server/client model and has the following characteristics:
RADIUS features excellent real-time performance by using the User Datagram Protocol
(UDP) as the transmission protocol.
RADIUS possesses high reliability owing to the retransmission mechanism and backup
server mechanism.
RADIUS is easy to implement and is applicable to the multi-threaded server in the case
of a large number of users.

Versions of RADIUS
The CX600 supports standard RADIUS, RADIUS+V1.0, and RADIUS+V1.1.
RADIUS+V1.1 and RADIUS+V1.0, derived from the standard RADIUS protocol, are private
protocols defined by Huawei. With these protocols, the RADIUS server works more
effectively in flow control, charge rate switching, and control over the BRAS. The two
protocols are both applicable to IPHotel and Portal services though they are different in
expansion.
RADIUS+V1.0
In RADIUS+V1.0, a private attribute set is suffixed to the standard attribute set. That is,
the private attributes are simply added to the standard attribute set. Such an extension
may conflict with the subsequent extension of the standard RADIUS protocol.
RADIUS+V1.1
In RADIUS+V1.1, all private attributes are considered a subset to be contained in the
vendor-specific attribute defined in RFC 2865. This ensures the interworking and
controllability between extended RADIUS+V1.1 of Huawei and the extended RADIUS
protocols defined by other vendors, and avoids the conflict between extended
RADIUS+v1.1 of Huawei and the subsequent extension of the standard RADIUS
protocol.
For Huawei private RADIUS attributes, refer to "Appendix A RADIUS Attributes" in the
HUAWEICX600 Multiservice Control Gateway Configuration Guide – BRAS Service.
Implementation of RADIUS on the CX600

As a RADIUS client, the CX600 implements the following functions:
Actively detects the status of the RADIUS server.
After receiving an AAA authentication or accounting message, the CX600 enables the
server detection process if the server is Down. The CX600 then transforms the message
into a packet and sends the packet to the current server to detect the server. If a response
packet is received from the RADIUS server, the CX600 considers the server available.
Caches the accounting-stop packets locally and retransmits them.
If the number of retransmission failures exceeds the set value, the accounting-stop
packets are saved to the buffer queue. The system periodically scans the queue, extracts
the packets, sends them to the specific server, and enables the waiting timer. If the
transmission fails or no response packet is received from the server within the timeout
period, the packets are put to the buffer queue again.
Automatically switches to another RADIUS server in the server group.
If the current server does not work or the number of retransmission events exceeds the
set maximum number, the CX600 selects another server in the server group to transmit
packets.
Performs load balancing between RADIUS servers.
Enabled with load balancing, the CX600 selects the RADIUS server in the Up state
according to the costs of the RADIUS servers. Commonly, the higher the priority, the
higher the possibility that the RADIUS server is selected.
Switches RADIUS attributes.
The CX600 supports the RADIUS attribute switching function. When the RADIUS
attribute switching function is enabled and then configured, the CX600 encapsulates or
parses the original attribute value in accordance with the post-switching attribute format

during the transmission of RADIUS messages. In this manner, the CX600 can interwork
with other devices.
Carries CAR in the class attribute
In the standard RADIUS protocol, the client is required to add the class attribute carried
in the authentication message received from the RADIUS server to the accounting packet,
and send the accounting packet to the accounting server without changing the class
attribute. The CX600 extends the standard RADIUS protocol by adding CAR to the class
attribute.
1.5.3 HWTACACS
Format of an HWTACACS message
The process of transmitting HWTACACS messages is similar to that of transmitting RADIUS
messages.
Features of HWTACACS
Compared with RADIUS, HWTACACS is more reliable in transmission and encryption and
thus is more suitable for security control. Table 1-1 shows comparisons between
HWTACACS and RADIUS.
Table 1-1 Comparisons between HWTACACS and RADIUS
HWTACACS RADIUS
Uses the Transmission Control Protocol Uses UDP.
(TCP) to provide reliable transmission.
Encrypts the main structure of a packet Encrypts only the password field in the
except the standard HWTACACS header. authentication packet.
Separates authorization from Performs authentication together with
authentication. authorization.
Is suitable for security control. Is suitable for accounting.
Authorizes the commands executed by Does not authorize the commands executed by
administrative users. administrative users.
In HWTACACS, authentication is separated from authorization. Therefore, you can use

RADIUS for authentication and HWTACACS for authorization. In such a case, though
RADIUS authorization is performed, only HWTACACS authorization takes effects.
Command-Line Authorization in HWTACACS

HWTACACS supports command-line authorization for the users with specific levels in a
specified domain or a specified Secure Shell (SSH) user.
In command-line authorization mode, after a user logs in to the router through Telnet or SSH,
every command input by the user needs to be authorized by the HWTACACS server. The
command can be run only after command-line authorization is passed. Otherwise, the

HWTACACS server displays a message to inform the user that command-line authorization
fails and the command cannot be run.
If the router does not receive any authorization response from the HWTACACS server within
the timeout period set by the user, it considers that the command-line authorization times out,
and thus the command cannot be run.
Figure 1-3 shows the process of command-line authorization in HWTACACS.
Figure 1-3 Process of command-line authorization in HWTACACS
1.command 2.author-cmd REQ
3.author-cmd ACK
User CX600 TACACS
Server
1. The user enters a command on the CX600.

2. The CX600 sends a command-line authorization request to the TACACS server.
3. The TACACS server returns the authorization result to the CX600. If authorization
succeeds, the user can run the command of the corresponding level; otherwise, the user
cannot run the command.
1.5.4 User management

Overview
The BRAS is used to manage access users. Currently, the BRAS manages users in the
following modes:
Domain-based user management
All users belong to a same domain. By default, users are added to the default domain.
The BRAS manages users by configuring service attributes in a domain. Thus, the users
in the same domain have the same service attributes.
User account-based user management
User accounts and related service attributes are configured on an AAA server such as the
RADIUS server or the HWTACACS server, and are then delivered to users when the
users get online, or dynamically delivered to users after the users get online.
In practical applications (except in non-authentication and non-accounting modes) on the
CX600, all user accounts must be configured on an AAA server, and the domain to which the
user accounts belong must be configured on the CX600. The CX600 supports the
configuration and management of local user accounts.
The service attributes configured for a domain have a lower priority than the service attributes
delivered by an AAA server. Therefore, when service attributes are both configured for a
domain and delivered by an AAA server, the CX600 adopts the service attributes that are
delivered by the AAA server. The service attributes configured for a domain take effect only
when the AAA server does not support or deliver the service attributes.

Overview of a Domain
The CX600 supports a user account in the format of username@domain or
domain@username. Here, @ is a domain name delimiter. The positions of the domain name
and the user name can be exchanged. If the user account that is input when a user accesses the
CX600 does not contain a domain name, it indicates that the user belongs to the default
domain of the system.
Default domain
A default domain is fixed in the system. The service attributes of the default domain can
be modified rather than deleted.
The CX600 has three default domains: default0, default1, and default_admin, as shown
in Table 1-2.
Table 1-2 Default domains of the CX600
Name Description Default

Attributes
default0 It is a domain to which a user belongs before Non-authenticatio
authentication. When a user access the CX600 and is n
not authenticated, the CX600 does not know the Non-accounting
domain of the user, and thus by default considers that
the user belongs to default0.
default1 It is a domain to which a user belongs during RADIUS
authentication. During authentication, if a user inputs authentication
a user account that does not contain a domain name, RADIUS
the CX600 by default considers that the user belongs accounting
to default1.
default_admin It is a domain to which an operation user belongs. In RADIUS
the case that an operation user logs in to the CX600 authentication
through Telnet or SSH, if the operation user inputs a Non-accounting
user account that does not contain a domain name
during authentication, the CX600 by default
considers that the operation user belongs to
default_admin.
Domain type
The CX600 supports the following types of domains:
− Default-domain pre-authentication
− Default-domain authentication
− Default-domain authentication force
− Default-domain authentication replace
− Authentication domain
− Roam-domain
− Permit-domain
The following describes the functions of each type of domain:
− Default-domain pre-authentication

This domain is used for only Web authentication users to obtain IP addresses. A user
binds the user name to this domain and then obtains an IP address after passing Web
authentication. Then, the user obtains corresponding rights according to the user
group name in this domain. After passing the Web authentication in this domain,
the users can access only the Web authentication server and the DNS. (The access
rights are controlled through the UCL-group and ACLs.)
If the default-domain pre-authentication is not configured on a BAS interface,
default0 is adopted as the default-domain pre-authentication.
− Default-domain authentication
If a user inputs a user account that does not contain a domain name during
authentication, the user adopts the authentication scheme, accounting scheme, and
RADIUS server that are configured in the default-domain authentication.
If the default-domain authentication is not configured on a BAS interface, default1 is
adopted as the default-domain authentication.
− Default-domain authentication force
A user adopts the authentication scheme, accounting scheme, and RADIUS server
that are configured in this domain, regardless of whether a domain name is contained
in the input user account or what the domain name is. If a domain name is contained
in the user account, the domain name remains unchanged during authentication; if no
domain name is contained, the default-domain authentication force is added to the
user account.
− Default-domain authentication replace
A user adopts the authentication scheme, accounting scheme, and RADIUS server
that are configured in this domain, regardless of whether a domain name is contained
in the input user account or what the domain name is. If a domain name is contained
in the user account, the domain name is replaced with the default-domain
authentication replace during authentication; if no domain name is contained, the
default-domain authentication replace is added to the user account.
− Authentication domain
It is a domain name that is contained in the user account input by a user. When a user
inputs a normal user account (a domain name is contained and is configured on the
CX600, and the BAS interface is not configured with the default-domain
authentication force or default-domain authentication replace), the user adopts the
authentication scheme, accounting scheme, and RADIUS server that are configured
in the input domain name.
− Roam-domain
A user must input a user account containing a domain name; otherwise, the user
cannot adopt the roam-domain policy. If the domain name is not configured on the
CX600, the user adopts the authentication scheme, accounting scheme, and RADIUS
server that are configured in the roam-domain. The user account remains unchanged
during authentication.
If the roam-domain is not configured on a BAS interface, default1 is adopted as the
roam domain.
− Permit-domain
It is a domain that is allowed to access when users are getting online through a BAS
interface.
Domain application
− Users getting online with a domain name
Assume that a user inputs a user account, namely, user@A.

− The BAS interface that accesses the user is not configured with the default-domain
authentication. If domain A is configured on the CX600, the user adopts the
authentication and accounting schemes that are configured in domain A, and the user
account for authentication is user@A. If domain A is not configured on the CX600,
and the roam-domain is disabled, the user authentication fails. If the roam-domain is
enabled, the user adopts the authentication and accounting schemes that are
configured in the roam-domain.
− The BAS interface that accesses the user is configured with domain B as the
default-domain authentication. If domain A is configured on the CX600, the user
adopts the authentication and accounting schemes that are configured in domain A,
and the user account for authentication is user@A. If domain A is not configured on
the CX600, and the roam-domain is disabled, the user authentication fails. If the
roam-domain is enabled, the user adopts the authentication and accounting schemes
that are configured in the roam-domain.
− The BAS interface that accesses the user is configured with domain E as the
roam-domain. If domain A is not configured on the CX600, the user adopts the
authentication and accounting schemes that are configured in domain E. If domain A
is configured on the CX600, the user adopts the authentication and accounting
schemes that are configured in domain A, and the user account for authentication is
user@A.
− The BAS interface that accesses the user is configured with domain F as the
default-domain authentication force. In this case, the user adopts the authentication
and accounting schemes that are configured in domain F (regardless of whether
domain A is configured on the CX600 or whether a roam-domain is configured), and
the user account for authentication is still user@A.
− The BAS interface that accesses the user is configured with domain G as the
default-domain authentication replace. In this case, the user adopts the authentication
and accounting schemes that are configured in domain G (regardless of whether
domain A is configured on the CX600 or whether a roam-domain is configured), and
the user account for authentication is changed into user@G.
− Users getting online without a domain name
Assume that a user inputs a user account, namely, user.
− If the BAS interface that accesses the user is not configured with the default-domain
authentication, the user adopts the authentication and accounting schemes that are
configured in default1, and the user account for authentication is user@default1.
− If the BAS interface that accesses the user is configured with domain B as the
default-domain authentication, the user adopts the authentication and accounting
schemes that are configured in domain B (domain B here is a default domain), and
the user account for authentication is user@B.
− If the BAS interface that accesses the user is configured with domain H as the
default-domain authentication force, the user adopts the authentication and
accounting schemes that are configured in domain H, and the user account for
authentication is user@H.
− If the BAS interface that accesses the user is configured with domain J as the
default-domain authentication replace, the user adopts the authentication and
accounting schemes that are configured in domain J, and the user account for
authentication is user@J.
No matter a user gets online with or without a domain name, after confirming the
authentication domain of the user, the CX600 still has to determine whether the
authentication domain is allowed to access the BAS interface on which a permit-domain
is configured.

The user account mentioned above is not the one that is sent to an AAA server. Instead, whether the user
account sent to the AAA server contains a domain name depends on whether the device is configured to
send a domain name to the AAA server.
Domain Management
A domain or an AAA server manages users by configuring service attributes for the users.
Domain management includes access management and service management.
Access management
In a domain, you can configure the authorization, authentication, and accounting
schemes and corresponding server that are used when a user accesses the BAS interface;
configure the authentication mode used in user authentication; specify the IP address
pool and the DNS server that are used to assign an IP address to a user; and control the
user access by setting a limit on access number and setting the alarm threshold of IP
addresses.
The following functions are highlighted:
− Time period control
In a specified time period, a domain automatically enters the blocked state. At this
time, the users in the domain cannot get online, and the online users are forced to get
offline. When the time period expires, the domain is activated and users in the
domain can get online. Four time periods can be set in a domain, and all of them can
take effect independent of each other.
− Mandatory PPP authentication
Generally, the authentication mode (PAP/CHAP/MSCHAP) for PPP users is
determined through the negotiation between the PPP client and the virtual template
(VT) interface. After an authentication mode is configured in a domain for PPP users,
the PPP users are authenticated according to the configured authentication mode.
− IP address alarm
After the upper threshold (in percentage) of IP addresses is set, the CX600 sends a
trap to the NMS when the IP address utilization exceeds the upper threshold. If the
threshold of IP addresses is not set, the CX600 does not generate any alarm no matter
how the IP addresses in the domain are used.
− Mandatory Web authentication
Mandatory Web authentication: If the user that requires Web authentication or fast
authentication attempts to access an unauthorized address before authentication, the
CX600 redirects the access request to the mandatory Web authentication server for
the user to be authenticated.
Service management
After a user gets online, the user can be managed through a domain in terms of basic
access services (such as access the Internet) or the right, bandwidth, and QoS of the
value-added services.
The involved service attributes include: QoS profile, user priority, captive portal,
multicast group, time period, traffic statistics, accounting packet copy, and idle-cut. The
following functions are described:
− Captive portal
Captive portal means that when a user accesses the external network for the first time
after passing the authentication, the CX600 forcibly redirects the access request to a
certain server, which is usually the portal server of a carrier. In this manner, a service

provided by the carrier is immediately accessed after the user is connected to the
Internet.
− Idle-cut
Idle-cut means that when the traffic from a user is smaller than the lower threshold in
a certain time period, the CX600 considers that the user is idle, and thus cut off the
connection with the user. In the configuration of the idle-cut function, you need to
specify two parameters, namely, the time period and the traffic.
− Traffic statistics collection
This function can be classified into two categories: function of collecting total traffic
in a domain and function of collecting the upstream and downstream traffic of a user.
1.6 Applications
1.6.1 RADIUS Authentication and Accounting
1.6.2 HWTACACS Authentication, Accounting, and Authorization
1.6.1 RADIUS Authentication and Accounting

User 1, user 2, and user 3 access the Internet through the CX600. The users send
authentication packets to the RADIUS server for authentication and authorization. When the
master server goes Down, the packets are switched to the backup server for authentication or
accounting. After the authentication succeeds, the RADIUS server delivers corresponding
rights to the users, and thus the users can access the Internet.
Figure 1-4 Network diagram of RADIUS authentication and accounting
RADIUS RADIUS
(master) (backup)
129.7.66.66 129.7.66.67
user1@isp1
Internet
user2@isp2
CX600
user3@isp3
1.6.2 HWTACACS Authentication, Accounting, and

Authorization
User 1, user 2, and user 3 access the Internet through the CX600. The users send
authentication packets to the HWTACACS server for authentication and authorization. When
the master server goes Down, the packets are switched to the backup server for authentication
or accounting. After the authentication succeeds, the HWTACACS server delivers

corresponding rights to the users, and then the users can access the Internet. The accounting
bills can also be copied to the bill server the same time they are being sent to the
HWTACACS server.
Figure 1-5 Networking diagram of HWTACACS authentication, accounting, and authorization
HWTACACS HWTACACS
(master) (backup)
130.7.66.66 130.7.66.67
user1@isp1
Internet
user2@isp2
CX600
Bill sever
user3@isp3 10.10.10.1
1.7 Impact
1.7.1 On the System Performance
1.7.2 On Other Features
1.7.3 Defects

None.

None.
1.7.3 Defects
None.

Abbreviation Full Spelling
AAA Authentication Authorization Accounting
RADIUS Remote Authentication Dial In User Service


HWTACACS HUAWEI Terminal Access Controller Access Control
System

Feature Description - User Access 2 Plug-and-Play
2 Plug-and-Play
About This Chapter

2.1 Introduction to Plug-and-Play
2.2 References
2.3 Availability
2.4 Principles
2.5 Applications
2.6 Impact
2.1 Introduction to Plug-and-Play

Definition
Plug-and-Play (PnP) is a reference to the ability of a network management system (NMS) to
automatically configure a device added to the network through the Dynamic Host
Configuration Protocol (DHCP). Through PnP, you can commission remote devices in a
centralized manner.
Purpose
A great number of devices need to access the mobile bearer network; therefore, the CapEx of
project deployment, especially of on-site commissioning of devices on the mobile bearer
network is high and the profit of the carrier is greatly affected. In this situation, Huawei
launches a PnP solution for mobile bearer networking schemes to address this problem.
Benefits
This feature bring the following benefits to operators:
PnP can greatly reduce time taken for on-site commissioning of devices and prevent device
commissioning engineers from working in atrocious outdoor environments. In this manner,
PnP can accelerate progress and improve quality of the project.

2 Plug-and-Play Feature Description - User Access
2.2 References
The following table lists the references of this document.
RFC 2131 Dynamic Host Configuration Protocol
RFC 2132 DHCP Options and BOOTP Vendor Extensions
RFC 3046 DHCP Relay Agent Information Option
2.3 Availability
NMS that allocates IP addresses to UPEs
NPEs
UPEs
License Support
You can apply the PnP feature on the device only after obtaining a license.
Version Support
Product Version
CX600 V600R002
2.4 Principles
2.4.1 Principle of DHCP
2.4.2 Operation Principle of a DHCP Client
2.4.3 Operation Process of PnP
2.4.1 Principle of DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for transmitting
configuration information to hosts on a TCP/IP network. DHCP, based on the Bootstrap
Protocol (BOOTP), adds the capability of automatically allocating reusable network addresses
and adds additional configuration options to DHCP packets.
DHCP packets can be classified into eight types. A DHCP server and a DHCP client
communicate with each other by exchanging these DHCP packets.

DHCPDISCOVER: It is the first packet used to search for a DHCP server when a DHCP
client accesses the network for the first time.
DHCPOFFER: It is sent by a DHCP server to respond to a DHCPDISCOVER packet. A
DHCPOFFER packet carries various configuration information.
DHCPREQUEST: The DHCP client sends a DHCPREQUEST packet to the DHCP
server in any of the following situations.
− After being initialized, the DHCP client broadcasts a DHCPREQUEST packet to
respond to the DHCPOFFER packet sent from the DHCP server.
− After being restarted, the DHCP client broadcasts a DHCPREQUEST packet to
confirm the correctness of the configurations, such as the previously allocated IP
address.
− After being bound to an IP address, the DHCP client sends a unicast
DHCPREQUEST packet to extend the lease of the IP address.
DHCPACK: It is sent by a DHCP server to acknowledge the DHCPREQUEST packet
sent from a DHCP client. After receiving a DHCPACK packet, the DHCP client obtains
the configuration information, including the IP address.
DHCPNAK: It is sent by a DHCP server to refuse the DHCPREQUEST message from a
DHCP client. For example, the IP address that is assigned by the DHCP server to the
DHCP client expires, or the DHCP client moves to another network.
DHCPDECLINE: It is sent by a DHCP client to notify the DHCP server that the
assigned IP address conflicts with the other IP addresses. Then, the DHCP client applies
to the DHCP server for another IP address.
DHCPRELEASE: It is sent by a DHCP client to ask the DHCP server to release the
network address and cancel the remaining lease.
DHCPINFORM: It is sent by a DHCP client to the DHCP server to ask for configuration
parameters after the DHCP client obtains an IP address.
2.4.2 Operation Principle of a DHCP Client

Figure 2-1 shows the operation principle of a DHCP client.

Figure 2-1 Operation principle of a DHCP client
DHCP Client DHCP Server
1.DHCP Discover
2.DHCP Offer
3.DHCP Request
4.DHCP ACK
1. The DHCP client sends a DHCPDISCOVER packet to the DHCP server and enters the
selecting state. Then, the DHCP client creates a timer for waiting DHCPOFFER packets
from the DHCP server.
− If the DHCP client receives a non-DHCPOFFER packet, it discards the packet.
− If the DHCP client receives no DHCPOFFER packet before the timer expires, the
DHCP client is initialized and sends another request for an IP address.
2. After receiving an DHCPOFFER packet, the DHCP client deletes the timer and sends a
DHCP request. Then, the DHCP client creates a timer for waiting a DHCPACK packet.
− If the DHCP client receives a packet that is not a DHCPACK or DHCPNAK packet,
it discards the packet.
− If the DHCP client receives a DHCPNAK packet, it sends another request for an
address.
− If the DHCP client has not received a DHCPACK or DHCPNAK packet before the
timer expires, it sends four DHCP requests within one minute. If no response is
received, the DHCP client is initialized and sends another request for an IP address.
3. After being allocated an IP address, the DHCP client sends a gratuitous ARP packet to
check whether the allocated address is already in use. If the address is in use, the DHCP
client sends a DHCPDECLINE packet to the DHCP server and returns to the initial state.
2.4.3 Operation Process of PnP

A underlayer PE (UPE) must function as a DHCP client to support the PnP feature. That is,
the UPE must be able to obtain an IP address by exchanging DHCP packets with the DHCP
server as described in Figure 2-2. The Network Management System (NMS) delivers
configuration files and startup files to the UPE. Then, the UPE can use the PnP feature after
restarting with the new configuration files.

Figure 2-2 Operation process of PnP
9.UPE obtains IP address and starts

defaultmanagement
7. Reply with a DHCP ACK, which

8. Reply with
carries allocated address
DHCP ACK.
5. Send Request 6.Insert Option 82 and

forward DHCP Offer
4. Reply with 3. Reply with
DHCP Offer DHCP Offer
2. Insert Option 82 and
1. Send Discover forward Discover
IP/MPLS
UPE(DHCP
DHCPRelay NMS(DHCP
Client)
Server)
10.The NMS sends configuration and start files to UPE and

deliver restart conmand.
11. The device is usable after
restart
The operation process of PnP is as follows:

1. After being powered on, the UPE starts the PnP process automatically. First, the UPE
sends a DHCP Discover broadcast packet that carries the Vendor Class Identifier (VCI)
in the Option 60 field.
2. The DHCP relay agent receives the DHCP Discover packet and appends the Option 82
field to the packet. Then, the DHCP relay agent unicasts the packet to the DHCP server,
which functions as the NMS.
3. The DHCP server searches the database for a fixed IP address according to the Option 60
and Option 82 fields carried in the packet. The DHCP server allocates a fixed IP address
and responds to the DHCP relay agent with a DHCP Offer packet.
4. The DHCP relay agent receives the DHCP Offer packet and then sends it to the UPE.
5. The UPE broadcasts a DHCP request.
6. The DHCP relay agent receives the DHCP request and appends the Option 82 field to the
packet. Then, the DHCP relay agent unicasts the packet to the DHCP server, which
functions as the NMS.
7. The DHCP server checks information in the received packet and acknowledges the
address allocation for the UPE. In addition, the DHCP server responds to the DHCP
relay agent with a DHCP ACK packet.
8. The DHCP relay agent receives the DHCP ACK packet and sends it to the UPE.
9. After receiving the DHCP ACK packet, the UPE sends gratuitous ARP packets and
checks whether the allocated address is already in use.

If the UPE finds that the allocated address is not in use, the UPE obtains information
such as the IP address (yiaddr), mask (option 1), and gateway (option 3) from the DHCP
ACK packet and generates a route. Meanwhile, the IP address X.X.X.X dynamic
command is automatically executed; Telnet, AAA administrative user, FTP, and SNMP
are configured on the UPE. Finally, the DHCP client function is disabled on the UPE,
and the UPE cannot send or handle DHCP packets any longer.
10. The NMS delivers configuration files, startup files, and a restart command to the UPE.
11. The UPE restarts and can use the PnP feature. That is, the PnP process is complete.
2.5 Applications
As shown in Figure 2-3, the UPE obtains a management IP address through DHCP and starts
a management channel through automatic configuration. The NMS delivers configuration
files and startup files through the management channel.
Figure 2-3 Network diagram of obtaining a management IP address and starting a management
channel
UPE PE-AGG NMS
IP/MPLS
DHCPClient DHCPRelay
DHCPServer
2.6 Impact
2.6.1 Impact on the System Performance
2.6.2 Impact on Other Features
2.6.3 Defects

None.

None.

2.6.3 Defects
None.

Terms
Term Definition
Plug-and-Play Plug-and-Play (PnP) is a reference to the ability of an NMS to
automatically configure a device added to the network
through DHCP. Through PnP, you can commission remote
devices in a centralized manner.
Acronyms
Acronym Full Spelling
PNP Plug-and-Play
DHCP Dynamic Host Configuration Protocol

Feature Description - User Access 3 L2TP Access
3 L2TP Access
About This Chapter

3.1 Introduction
3.2 References
3.3 Availability
3.4 Enhancement
3.5 Principles
3.6 Applications
3.7 Impact
3.1 Introduction
Definition
Virtual Private Dial Network (VPDN) is a virtual private network implemented through the
dial-in function of a public network such as an Integrated Services Digital Network (ISDN)
and a Public Switched Telephone Network (PSTN) and access networks. This technology is
often used to provide remote access for enterprises, small Internet Service Providers (ISPs),
mobile staff.
Adopting a special encryption communication protocol, the VPDN sets up safe virtual private
networks over a public network for enterprises. In this manner, oversea organizations of
enterprises and staff traveling on business can access the headquarters across the public
network through an encrypted virtual tunnel. Users on the public network, however, cannot
access the resources inside the enterprise network through this virtual tunnel.
Among multiple protocols used by VPDN tunnels, the most popular protocol is the Layer 2
Tunneling Protocol (L2TP).
PPP defines an encapsulation mechanism for transmitting multi-protocol packets across Layer
2 point-to-point links. Therefore, it needs to be run on the connections between users and
Network Access Servers (NASs).

3 L2TP Access Feature Description - User Access
L2TP supports the tunneling of PPP-encapsulated packets. It extends the PPP model by
allowing the Layer 2 and PPP endpoints to reside on different devices interconnected through
the packet switching technology.
With L2TP, a user can set up an end-to-end PPP session on a non-point-to-point network.
L2TP combines advantages of the Layer 2 Forwarding (L2F) and Point-to-Point Tunneling
protocol (PPTP), and therefore is standardized by the IETF.
L2TP involves the following concepts:
Users
In an L2TP networking, users are devices (such as PCs) to access a private network. The
access modes and locations of VPDN users are always changing. In this situation, VPDN
users can set up connections with an L2TP Access Concentrator (LAC) through the
PSTN or ISDN or directly accesses the Internet to communicate with the server of the
headquarters.
A user is always the initiator of a PPP negotiation. Therefore, the user is both a Layer 2
PPP link end and a PPP session end.
LAC
An L2TP Access Concentrator (LAC) is a device on the switched network, with the
capability of terminating PPP packets and performing L2TP functions. Usually, the LAC
is an access device of the local ISP, such as the NAS, which provides access services for
users through the PSTN or ISDN.
The LAC tunnels individual PPP packets to the NAS through L2TP tunnels and PPP
sessions. An LAC can provide services not only for a specified VPN but also for multiple
VPNs.
The LAC sits between the L2TP Network Server (LNS) and a remote system (remote
subscribers and branches), as shown in Figure 3-1.
Figure 3-1 VPDN model based on L2TP
Remote LAC LNS

subscriber
PSTN/
ISDN
L2TP tunnel
NAS
Remote
branch
Internal
server
The LAC exchanges packets between the LNS and the remote system. It sends packets
from the remote system to the LNS after the L2TP encapsulation process, and sends
packets from the LNS to the remote system after the decapsulation process.
The LAC and the remote system can be connected through local links or PPP links.
Usually, PPP links are used between VPDN users and the LAC. The LAC is both an end
to responds to users' requests and a PPP link end.
LNS

An L2TP Network Server (LNS) is a PPP session end. Users that pass the authentication
on the LNS can access the private network. The LNS acts as one side of an L2TP tunnel
endpoint and is a peer to the LAC. It is the logical termination point of a PPP session that
is being tunneled from the remote system by the LAC.
The LNS sits at the boundary between the private and public networks, and is usually a
gateway device. The gateway provides the network access and LNS functions. If
necessary, the LNS can provide the Network Address Translation (NAT) function to
translate private IP addresses on the enterprise network into IP addresses on the public
network.
Two types of messages utilized by L2TP
− Control messages are used in the establishment, maintenance, and teardown of
tunnels and sessions. In addition, control messages are used in transmission control.
The L2TP tunnel applies mechanisms (such as packet retransmission and periodical
detection of the tunnel connectivity) to guarantee the reliable transmission of control
messages. In addition, the L2TP tunnel supports the traffic and congestion control
over the control messages.
− Data messages encapsulate PPP frames and are transmitted over the tunnel. Data
messages are not retransmitted if message loss occurs. The L2TP tunnel does not
support the traffic and congestion control over data messages.
AVP
Parameters in control messages are identified by Attribute Value Pairs (AVPs). This can
increase the interoperability and scalability of L2TP. Control messages contain multiple
AVPs.
Control connections and session connections
L2TP is connection-oriented. There are two types of connections between a pair of LNS
and LAC:
− A control connection that defines a pair of LNS and LAC and controls the
establishment, maintenance and teardown of tunnels and sessions. The procedures for
establishing a control connection involve the exchange of information about identity
protection, L2TP version, frame type, and parameters of the physical links.
− A session connection is a PPP session multiplexed on the tunnel connections.
Multiple L2TP tunnels can be set up between a pair of LNS and LAC. A tunnel consists of a
control connection and one or more session connections. A session connection can be set up
only after a control connection is set up. Each session corresponds to a PPP data flow
transmitted between the LAC and LNS.
Control messages and data messages (PPP messages) are transmitted through tunnels.
Purpose
Advantages L2TP are as follows:
Flexible authentication mechanism and high security
− L2TP itself cannot guarantee the connection security. It utilizes an authentication
mechanism (such as CHAP and PAP) provided by PPP and thus possesses all PPP
security features.
− L2TP can work together with IPSec to better protect data transmitted through L2TP
from being attacked.
− L2TP can be applied with encryption technologies (such as tunnel encryption,
end-to-end data encryption, and link layer data encryption) as required to increase the
security.

Multi-protocol transmission
L2TP transmits PPP packets. PPP itself supports the transmission of multi-protocol
packets. Therefore, multi-protocol packets (even packets of link layer protocols, such as
Ethernet packets) can be encapsulated in PPP packets and are transmitted by L2TP.
RADIUS authentication
An LAC sends a user name and password to a RADIUS server for authentication.
Private address allocation
An LNS can be placed behind the firewall of the enterprise network to perform the
dynamic address allocation and management.
Flexible network accounting
Both the ISP (LAC) and the gateway of the enterprise network (LNS) can perform the
accounting function. L2TP provides accounting information, such as the number of
transmitted packets, number of bytes, start and end point of the connection, and ending
time.
Reliability
L2TP sets up the backup LNS. When the master LNS becomes unavailable, the backup
LNS sets up a connection with the LAC, thus enhancing the reliability and fault
tolerance ability of the VPN services.
Benefits
L2TP brings remarkable benefits to operators:
Provides an authenticatable and a manageable tunnel transmission mechanism.
Provides a flexible mode for batch transmission. In this mode, L2TP services can be
authenticated and charged by both the carrier and the ISP.
3.2 References
The following table lists the references of this document:
Document Description Remarks

RFC 2661 Layer Two Tunneling Protocol "L2TP"
RFC 1918 Address Allocation for Private Internets
RFC 2809 Implementation of L2TP Compulsory Tunneling
via RADIUS
RFC 2888 Secure Remote Access with L2TP
draft-ietf-l2tpe PPP over L2TP Tunnel Switching
xt-tunnel-switc
hing-07

3.3 Availability
Two devices must act as the LAC and LNS at the two ends of an L2TP tunnel.
Devices support IP forwarding.
License Support
L2TP services are available only after the corresponding license is obtained.
Version Support
Product Version
CX600 V600R002
Dependency
Not involved.
Hardware Support
At present, boards supporting L2TP are:
On the CX device, the LPUF-10, LPUF-21, and LPUF-40 support LAC. The LPUF-10
supports LAC only in the case of PPPoEoA or PPPoA access.
On the CX device, the LPUF-21 and LPUF-40 support LNS. The LPUF-21/LPUF-40
supports distributed L2TP.
Others Features
Not involved.
3.4 Enhancement
Version Enhancement
V600R002 L2TP supports the access of IPv6 users and
dual-stack users.
3.5 Principles
3.5.1 L2TP Protocol Structure

3.5.2 L2TP Header
3.5.1 L2TP Protocol Structure

Figure 3-2 L2TP protocol structure
PPP frame
L2TP data message L2TP control message
L2TP data channel (unreliable) L2TP control channel (reliable)
Packet transmission network (UDP, ...)
Figure 3-2 depicts the relationship of PPP frames and control messages over the L2TP control
and data channels. PPP frames are passed through an unreliable data channel; control
messages are sent over a reliable L2TP control channel.
Both L2TP data and control messages are transmitted in UDP packets. Data messages are not
retransmitted in the case of transmission failures and therefore the transmission is unreliable;
the transmission of control messages, however, is controlled by the traffic control and
retransmission mechanisms and therefore is reliable. L2TP uses the registered UDP port 1701
and this port is used only during the initial establishment of an L2TP tunnel. The initiator of
an L2TP tunnel picks a free source UDP port (which may or may not be 1701), and sends
packets to port 1701 of the receiver. Upon receiving the packets, the receiver also picks a free
port on its own system (which may or may not be 1701), and sends a reply to the initiator's
UDP port. Once the source and destination ports and addresses are specified, they must
remain unchanged as long as the tunnel is connective.
3.5.2 L2TP Header

Headers of L2TP control messages and L2TP data messages are the same.
Figure 3-3 Format of an L2TP message header
0 7 12 16 31
T L x x S x O P x x x x Ver Length (opt)
Tunnel ID Session ID
Ns (opt) Nr (opt)
offset size (opt) offset padding (opt)
In the L2TP message header, "opt" following a field indicates that the field is optional in a
data message but is mandatory in a control message.
Table 3-1 Description of fields in an L2TP message header

Field Meaning Remarks
T Indicates the type of a message: The value must be 1 in a control
0: indicates a data message. message.
1: indicates a control message.

Field Meaning Remarks

L Indicates the Length bit. The value 1 The value must be 1 in a control
indicates that a message header contains message.
the Length field.
x Indicates a reserved bit. -
S Indicates the Sequence bit. The value 1 The value must be 1 in a control
indicates that a message header contains message.
the Ns field and the Nr field.
O Indicates the Offset size bit. The value The value must be 0 in a control
1 indicates that a message header message.
contains the Offset size field.
P Indicates the priority. This field exists The value must be 0 in a control
only in a data message. message.
Ver Indicates the version number of the The value is 2 if L2TPv2 is
L2TP protocol. enabled.
Length Indicates the total length of a message, -
in bytes.
Tunnel ID Indicates the tunnel ID, which is only The value must be 0 in a Hello
locally valid. control message because the
Hello control message is globally
valid.
Session ID Indicates the session ID, which is only -
locally valid.
Ns Indicates the sequence number of the -
current message.
Nr Indicates the sequence number of the It is a reserved field in data
next message expected to be received. messages.
offset size Indicates the origin position of the -
payload.
offset Indicates the padding bit. -
padding
The tunnel ID and session ID contained in an L2TP message header are allocated by the peer
along an L2TP tunnel to identify a tunnel and a session, respectively. Messages with the same
tunnel ID and different session IDs are multiplexed on one L2TP tunnel.
Structure of an L2TP Data Message

A user PPP packet (already encapsulated with a source IP header and a PPP header) is
encapsulated with the following protocol headers when being transmitted as an IP packet over
a public network:
A 16-byte L2TP header

An 8-byte UDP header

A 20-byte IP header, indicating the source and destination addresses of an L2TP tunnel
Figure 3-4 shows the format of an L2TP data message.
Figure 3-4 Format of an L2TP data message
20 bytes 8 bytes 16 bytes 2 bytes 20 bytes
New IP UDP header L2TP header PPP Original Data

header header header
The LAC encapsulates a PPP packet as follows:

1. Encapsulates the packet with an L2TP header.
2. Encapsulates the packet with a UDP header.
3. Encapsulates the packet with a new IP header and then sends the packet through a public
network interface. The destination address in the new IP header is the IP address of the
destination of the L2TP tunnel.
L2TP has no data fragmentation function. After an L2TP message is encapsulated with an IP header, the
IP packet can be fragmented as required. To ensure that no packet needs to be fragmented, the size of the
encapsulated IP packet cannot be greater than the value of the MTU of the physical interface.
After receiving the packet on the interface connected to the public network, the LNS handles
the packet as follows:
1. Decapsulates the IP header and the UDP header and then sends the packet to the L2TP
module.
2. Decapsulates the L2TP header and the PPP header to restore the original user IP packet,
and then sends the IP packet to the server inside the private network.
Process of Establishing a Control Connection and a Session Connection

Messages
On the CX600, during the process of establishing a control connection and a session
connection, the following messages are used:
Start-Control-Connection-Request (SCCRQ) message: is a request sent to the remote end
for establishing a control connection.
SCCRP (Start-Control-Connection-Reply) message: is a reply to the remote end to notify
that the SCCRQ message is received and the control connection can be established.
Start-Control-Connection-Connected (SCCCN) message: is a reply to the remote end to
indicate that the SCCRP message is received and the L2TP tunnel has been established
on the local end.
Stop-Control-Connection-Notification (StopCCN) message: informs the remote end that
all session connections are torn down on the local end and the tunnel interface is to be
shut down. A StopCCN message carries the reason for tearing down the control
connection on the local end.
Incoming-Call-Request (ICRQ) message: is sent only by the LAC. Each time detecting a
call request sent by a user, the LAC sends an ICRQ message to the LNS to request the
establishment of a session connection. The ICRQ message carries session parameters.

Incoming-Call-Reply (ICRP) message: is sent only by the LNS to reply to the ICRQ
message sent by the LAC, indicating that a session connection can be established.
Incoming-Call-Connected (ICCN) message: is sent only by the LAC to reply to the ICRP
message sent by the LNS, indicating that a reply to the call request is sent and the session
connection needs to be established on the LNS.
Call-Disconnect-Notify (CDN) message: is sent to the peer to notify the disconnection of
the session and the reason for the disconnection.
Hello message: detects connectivity of an L2TP tunnel.
Zero-Length Body (ZLB) message: is sent to the remote end when no messages in the
queue of the local end are to be sent. In addition, during the teardown of the session
connection and the control connection, sending a ZLB message indicates that a StopCCN
or CDN message is received. The ZLB message only contains an L2TP header and has
no payload.
The process of establishing and tearing down a control connection is as follows:
1. Establishing a control connection
A session connection can be established only after a control connection is set up. Figure
3-5 shows the process of establishing an L2TP control connection.
Figure 3-5 Diagram of the three-way handshake during the establishment of a control connection
LAC LNS
SCCRQ
SCCRP
SCCCN
ZLB No messages waiting in queue
− After routes between the LAC and the LNS are reachable, the corresponding
Attribute Value Pairs (AVP) are set on the LAC. The LAC then sends an SCCRQ
message carrying the AVPs to the LNS to request for the establishment of a control
connection.
− The LNS receives the SCCRQ message from the LAC. According to the AVPs carried
in the message, if the request is accepted, the LNS sends an SCCRP message to the
LAC.
− After receiving the SCCRP message, the LAC checks the message and extracts the
tunnel information, and then sends an SCCCN message to the LNS, indicating that
the control connection is successfully set up.
− When no messages exist in the queue of the LNS, the LNS sends a ZLB message to
the LAC.
On the device, you can run the command to view the control connections that are
successfully established.
2. Establishing a session connection

After a control connection is successfully established, a request for the establishment of a

session connection is sent when a user call is detected. Different from a control
connection, a session connection is unidirectional. On the CX600, the request for the
establishment of a session connection is initiated by the LAC. Figure 3-6 shows the
process of establishing a session connection.
Figure 3-6 Diagram of the process of establishing a session connection
LAC LNS
Call Detected ICRQ
ICRP
ICCN
ZLB ACK No messages waiting in queue
The establishment of an L2TP session connection is triggered through PPP.

On the device, you can run the command to view the session connections that are
successfully established.
3. Maintaining a control connection
L2TP uses Hello messages to detect connectivity of a tunnel. The LAC and the LNS
periodically send Hello messages to each other. If no replies to the Hello messages are
received within a specified period, Hello messages are resent. If Hello messages are
resent for three times, the L2TP tunnel is regarded as disconnected, and the PPP session
is thus deleted. In this case, a new L2TP tunnel needs to be established.
The interval for sending Hello messages can be manually set. By default, the interval for
sending Hello messages is 60 seconds. The intervals for sending Hello messages set on
the LNS and the LAC can be different.
4. Teardown of a session connection
Either the LAC or the LNS can initiate the teardown of a session connection. The
initiator sends a CDN message to inform the remote end to tear down the session
connection. The remote end replies the received CDN message with a ZLB ACK
message. Figure 3-7 shows the process of tearing down a session connection on the
LAC.
Figure 3-7 Diagram of tearing down an L2TP session connection
LAC LNS
CDN
ZLB ACK

5. Teardown of a control connection

Both the LNS and the LAC can initiate the teardown of a control connection. The
initiator sends a StopCCN message to inform the remote end to tear down the control
connection. The remote end replies the received StopCCN message with a ZLB ACK
message. The remote end, however, maintains the control connection for a certain period
to avoid the loss of the ZLB ACK message. Figure 3-8 shows the process of tearing
down a control connection on the LAC.
Figure 3-8 Diagram of tearing down an L2TP control connection
LAC LNS
StopCCN
ZLB ACK
Process of Tunnel Authentication

Tunnel authentication is performed in parallel with the establishment of a tunnel.
The process of tunnel authentication is as follows:
1. The LAC sends an SCCRQ message to the LNS, carrying a randomly-generated
character string as the local CHAP Challenge.
2. After receiving the SCCRQ message, the LNS uses the carried CHAP Challenge and the
locally-configured password to generate a new character string and then calculates a
16-byte Response through the MD5 algorithm. In addition, a character string is randomly
generated as the LNS Challenge. Then, the LNS sends an SCCRP message carrying the
Response and the LNS Challenge to the LAC.
3. After receiving the SCCRP message, the LAC authenticates information sent by the LNS
as follows:
− Uses the local CHAP Challenge, locally configured password, and information
carried in the SCCRP message to generate a new character string.
− Calculates a 16-byte character string through the MD5 algorithm.
− Compares the string with the CHAP Response carried in the SCCRP message sent by
the LNS. If the information is the same, tunnel authentication succeeds; otherwise,
tunnel authentication fails, and the tunnel is disconnected.
4. If tunnel authentication is successful, the LAC sends an SCCCN message carrying the
local CHAP Response to the LNS.
5. After receiving the SCCCN message, the LNS authenticates information sent by the
LAC as follows:
− Uses the local CHAP Challenge, locally configured password, and information
carried in the SCCCN message to generate a new character string.
− Calculates a 16-byte character string through the MD5 algorithm.
− Compares the string with the CHAP Response carried in the SCCCN message sent by
the LAC. If the information is the same, tunnel authentication succeeds; otherwise,
tunnel authentication fails, and the tunnel is disconnected.

Process of Establishing an L2TP Tunnel

Figure 3-9 shows the typical networking diagram of an L2TP tunnel.
Figure 3-9 Networking diagram of an L2TP tunnel
RADIUS RADIUS RADIUS

Server Server Server
IP IP IP
Network Network Network
PSTN/ WAN WAN

ISDN Tunnel1 Tunnel2
PC LAC LNS' LAC' LNS Headquarter
CX-A CX-B(LTS) CX-C
Figure 3-10 shows the flowchart of establishing an L2TP call for tunnel authentication.

Figure 3-10 Flowchart of establishing an L2TP tunnel call
LAC RADIUS
PC LNS LNS
Server
(1) call setup

(2) PPP LCP setup
(3) PAP or CHAP
authentication
(4) access request
(5) access accept
(6) tunnel establish
(7) PAP or CHAP authentication
(challenge/response)
(8) authentication passes
(9) user CHAP response, PPP
negotiation parameter (10) access request
(11) access accept
(12) CHAP authentication twice(challenge/response)
(13) access request
(14) access accept
(15) authentication passes
1. The PC initiates a request for establishing a call.

2. The PPP LCP negotiation is performed between the PC and the LAC (Router A).
3. The LAC authenticates the user information sent by the PC through PAP or CHAP.
4. The LAC sends the user information (including the user name and password) to a
RADIUS server for authentication.
5. The RADIUS server authenticates the user information. If authentication succeeds, the
LNS address corresponding to the user is sent and the LAC is to initiate a request for
establishing a tunnel connection.
6. The LAC sends a request for establishing a tunnel connection to the specified LNS.
7. The LAC sends a CHAP Challenge message to the specified LNS. The LNS replies to
the CHAP Challenge message with a CHAP Response message and sends a CHAP
Challenge message to the LAC. Then, the LAC replies to the CHAP Challenge message
with a CHAP Response message.
8. Tunnel authentication succeeds.
9. The LAC sends the user CHAP Response message, identifier of the Response message,
and negotiated PPP parameters to the LNS.
10. The LNS sends the request for access to the RADIUS server for authentication.
11. The RADIUS server authenticates the request. If authentication succeeds, the RADIUS
server sends a response message.

12. If the user configures forcible CHAP authentication on the LNS, the LNS authenticates
the user information and sends a CHAP Challenge message to the user. The user then
replies the LNS with a CHAP Response message.
13. The LNS sends the request for access again to the RADIUS server for authentication.
14. The RADIUS server authenticates the request. If authentication succeeds, the RADIUS
server sends a response message.
15. After authentication succeeds, the user can access resources of the Intranet.
User Authentication Modes on the LNS

The LNS can authenticate a user twice. The first authentication is performed on the LAC and
the second authentication is performed on the LNS. The second authentication is not
performed on the LNS only in the scenario where the authentication mode is not configured
on an associated virtual template (VT) after the LCP renegotiation is enabled. In other
situations, the second authentication must be performed. Note that “none” is also an
authentication mode.
On the LNS, the user can be authenticated in proxy mode, forcible CHAP mode, or forcible
LCP renegotiation mode.
LCP renegotiation
If authentication required on the LNS is more strictly than that on the LAC, or if the LNS
needs to obtain information directly from a user (in the scenario where the LNS and the
LAC are of different vendors), the LCP renegotiation between the LNS and the user can
be configured. During the renegotiation, the authentication mode configured on the
corresponding VT is adopted. In this case, information for proxy authentication on the
NAS is ignored.
Forcible CHAP authentication
If only forcible CHAP authentication is configured, the LNS authenticates the user
information through CHAP. If authentication fails, no session can be established.
Proxy authentication
If the LCP renegotiation and forcible CHAP authentication are not configured, the LNS
authenticates the user information through proxy.
Proxy authentication refers to that the LAC sends all information about a user and the
locally-configured authentication mode to the LNS, and then the LNS authenticates a
user based on received information.
When an NAS initiates a request for NAS-Initialized VPN services, a user needs to
negotiate parameters of a PPP session with the NAS. If the negotiation is successful, the
NAS initializes an L2TP tunnel connection and sends the user information to the LNS.
The LNS then authenticates the user information.
In the case that the LNS adopts proxy authentication, if the VT is configured with CHAP
authentication and the LAC is configured with PAP authentication, authentication on the
LNS fails and the session cannot be established, because the priority of CHAP
authentication on the LNS is higher that the priority of PAP authentication on the LAC.
If the LAC is configured with AAA authentication in none mode, AAA authentication is
not performed no matter whether the LAC is configured with PAP or CHAP
authentication. After the authentication mode is sent to the LNS, the LNS authenticates
the user information through AAA (in local, RADIUS or none mode).
The relationships between proxy authentication and the authentication mode configured
in a VT are as follows:

− The authentication mode configured in the VT cannot be more complicated than the
authentication mode configured on the LAC. If PAP authentication is configured on
the LAC, whereas CHAP authentication is configured on a VT of the LNS,
authentication on the LNS fails.
− In other situations, the LNS adopts the authentication mode sent by the LAC rather
than the authentication mode on a VT.
L2TP Tunnel Switching

Applicable environment
VPDN applications are more flexible in a diversity of networking schemes. In certain
networking scenarios, a session may travel multiple tunnels before reaching the destination.
The tunnel switching technology is thus introduced.
Figure 3-11 Networking diagram of L2TP tunnel switching
RADIUS RADIUS RADIUS

Server Server Server
IP IP IP
Network Network Network
PSTN/ WAN WAN

ISDN Tunnel1 Tunnel2
PC LAC LNS' LAC' LNS Headquarter
CX-A CX-B(LTS) CX-C
As shown in Figure 3-11, TUNLSW (CX- B) is deployed between the LAC and the LNS.
Principles of tunnel switching
PC1 accesses PC2 in the following process:
1. PC1 sends a request to the LAC for the establishment of a tunnel destined for TUNLSW
rather than the LNS (CX- C). A tunnel and then a session are established between the
LAC and TUNLSW.
2. Detecting that the endpoint of the session is the LNS, TUNLSW sends a request to the
LNS for the establishment of a tunnel.
3. TUNLSW switches the session along the tunnel between TUNLSW and the LAC to the
tunnel destined for the LNS.
4. When the session reaches the LNS, the session is terminated and a PPP connection is
established. In this manner, PC1 can access PC2.
In this process, TUNLSW switches the session from the tunnel between the LAC and
TUNLSW to the tunnel between TUNLSW and the LNS. That is, TUNLSW performs
the session switching over tunnels. Like a passenger transferring between buses, the
preceding session needs to be switched to another tunnel to reach the destination.
TUNLSW is such a transfer device for a session and can switch the session through the

tunnel switching technology. Figure 3-11 shows a simple networking scheme, whereas in
practice, the session may be switched for multiple times before reaching the LNS.
TUNLSW needs to be configured with two L2TP groups. One L2TP group, functioning
as the LNS, receives the request initiated by the LAC for establishing a tunnel; the other
L2TP group, functioning as the LAC, initiates a request for establishing a tunnel to
another TUNLSW or LNS.
Multiple protocols, including L2TP, can implement tunnel switching. Tunnel switching
implemented through L2TP is also called multi-hop L2TP.
3.6 Applications
Two Typical L2TP Tunnel Modes
Figure 3-12 shows the mode of the tunnel between the remote system or the LAC client (the
host running L2TP) and the LNS.
Figure 3-12 Two typical L2TP tunnel modes
LAC client
LAC Internet
LNS
PSTN/
Internal server
ISDN
wan
LAC
Remote
system LNS
Internal server
Connections can be set up in either of the following modes:

NAS-initialized mode
A remote user initiates a connection, and the remote system dials in to the LAC over the
PSTN/ISDN. Then, the LAC sends a request over the Internet to the LNS for setting up a
tunnel. The LNS is responsible for assigning an address to the dial-in user. Either the
LNS or the agent at the LAC side can authenticate the remote dial-in user and account
the services of the user.
The NAS-initialized mode features the following:
− Users must access the Internet in PPP mode (for example, through PPPoE).
− The carrier's access device (mainly referring to the BAS) needs to be configured with
the VPN service. Users need to apply to the carrier for the VPN service.

− An L2TP tunnel is set up between the LAC and the LNS, and an L2TP tunnel can
bear multiple sessions.
In NAS-initialized mode, as shown in Figure 3-12, LAN users are connected to a switch;
the switch is connected to a router (or multiple users are directly connected to a router);
the router is connected to the LAC through PPP or PPPoE.
Figure 3-13 Users accessing the LAC through a router
user
LAN
Switch
Internal
server
Router LAC LNS
Internet
user l2tp tunnel
PPP
/PPPoE
user
Client-initialized mode
An LAC client that supports L2TP directly initiates a connection. The client needs to
know the IP address of the LNS. The LAC client can directly send a request to the LNS
for setting up a tunnel without the LAC. After receiving the request, the LNS
authenticates the LAC client according to the user name and password. If the LAC client
passes the authentication, the LNS assigns a private IP address to the LAC client.
The client-initialized mode features the following:
− Users need to install the L2TP dial-in software. Users can also dial in through the
VPN dial-in software of the Windows operating system.
− There is no limitations of how and where users access the network, and no ISP is
required.
− An L2TP tunnel is set up between the client and the LNS, and an L2TP tunnel can
bear only one L2TP session.
− Users can choose a security protocol according to their requirements for data
transmission security. If data to be transmitted needs high security, users can use
IPSec.
Generally, both the NAS-initialized mode and the client-initialized mode can be used on
a network. On certain networks, only the client-initialized mode is adopted. Such
networks have strict requirements for the number of tunnels set up on the LNS because
in client-initialized mode, an L2TP tunnel bears only one L2TP session.
L3VPN Access Through L2TP

Traveling users accessing MPLS VPNs
VPN services over the Multi-Protocol Label Switching (MPLS) backbone network are
high-quality services for users. Therefore, the MPLS VPN technology is the mainstream
VPN technology preferred by carriers. The MPLS VPN requires that the Customer Edge
(CE) be directly connected to the Provider Edge (PE) on the MPLS backbone network
(the interface attribute of the PE identifies the VPN to which the CE belongs).
It is impossible for traveling users to directly access the PE on the MPLS backbone
network at any time. Thus, the users cannot directly access the sites inside the MPLS

VPN through the Internet or the IP backbone network. L2TP can address this problem.
This technology is also called L3VPN access through L2TP.
Carriers need to provide a shared LNS (equivalent to a PE device of an enterprise) for
enterprises on the MPLS VPN to allow traveling users of an enterprise to access the
enterprise Intranet in different places. As the LNS is shared by multiple enterprises, the
carrier needs to ensure that the LNS can make users of different enterprises on the LNS
access corresponding enterprise Intranets.
Figure 3-14 Users accessing the LAC through a router
access
PC1 network WAN CX-B
CX-A
user1@isp1 vrf1 isp1
L2TP Tunnel
Headquarter01
L2TP Tunnel vrf2
access LAC LNS
PC2
network
Headquarter02
isp2
user1@isp2
Users in a VPN accessing other VPNs

You can use a multi-role host to help a VPN user access another VPN. The multi-role
host is not suitable for the scenario where there are multiple VPNs and each VPN has
multiple users that need to access other VPNs.
VPN access through L2TP can address this problem. For example, users in VPN1 dial in
to a PE through L2TP, and the PE assigns IP addresses of VPN2 to the users and adds the
addresses to the routing table of VPN2. In this manner, users in VPN1 can access servers
in VPN2. If the users attempt to access VPN3, the users can dial in by using the VPN3
user name to obtain IP addresses of VPN3. Then, the users can access VPN3.
Multi-hop L2TP
If no L2TP tunnel can be directly set up between the user and the LNS, and a PPP session
needs to traverse multiple tunnels to reach the LNS, you can use L2TP tunnel switching,
which is also called multi-hop L2TP.
L2TP Complex Networking

The device using the CX600 as the platform can function as the LAC and the LNS at the same
time. In addition, such a device can provide the access service for multiple users. If the
memory and the line permit, the device can receive and initiate multiple calls through L2TP.
You can jointly use the above mentioned applications to meet such complex networking
requirements.
IPv6 User Access Through L2TP

With the wide application of IPv6 networks, remote access users also require to access IPv6
networks. Serving as the PE on an IPv6 network, the LNS needs to be capable of assigning

IPv6 addresses to remote access users to allow them to access the IPv6 network, with the
L2TP tunnel set up between the LAC and the LNS being still over an IPv4 network.
For users that need to access both IPv4 and IPv6 networks, the LNS must be capable of
assigning both IPv4 and IPv6 addresses to the users and then connecting the users to IPv4 and
IPv6 networks separately.
Figure 3-15 Application of IPv6 network access through L2TP on the carrier's network
DNS AAA
Server Server
IPV4
IPv4
network
IPV4/IPV6 access
network
L2TP Tunnel
PPPoX (IPv4)
LAC LNS
IPV6 IPv6
network
DNS AAA
Server Server
3.7 Impact
3.7.3 Defects

Not involved.

On the BSUF-21, BSUF-40, LPUF-21, and LPUF-40, L2TP cannot function together with
lawful interception and NetStream.
3.7.3 Defects
Reassembly of L2TP packets is supported only on the TSU.
On the BSUF-21, BSUF-40, LPUF-21, and LPUF-40, the L2TP forwarding capability can
reach only half of the total forwarding capabilities of the board.


Terms and Abbreviations
NAS Network Access Server
VPDN Virtual Private Dial Network
L2TP Layer 2 Tunneling Protocol
LAC L2TP Access Concentrator
LNS L2TP Network Server

Feature Description - User Access 4 IPoEv4
4 IPoEv4
About This Chapter

4.1 Introduction to IPoE
4.2 References
4.3 Availability
4.4 Feature Enhancement
4.5 Principles
4.6 Applications
4.7 Impact
4.1 Introduction to IPoE

Definition
IP over Ethernet (IPoE) is a method of accessing a router by sending Dynamic Host
Configuration Protocol (DHCP) packets, Address Resolution Protocol (ARP) packets, or
Internet Protocol (IP) packets. With this technology, users can access the Internet without
having to install the client dial-in software on their PCs.
Purpose
Compared with Point-to-Point over Ethernet (PPPoE), IPoE is easy to use and does not need
any client dial-in software. In addition, IPoE works better with multicast services.
Benefits
IPoE brings the following benefits to operators:
IPoE is a simple method of accessing the Internet.
IPoE is an access method that facilitates the deployment of multicast services.

4 IPoEv4 Feature Description - User Access
4.2 References

RFC 1541 Dynamic Host Configuration Protocol -
RFC 2131 Dynamic Host Configuration Protocol -
RFC 2132 DHCP Options and BOOTP Vendor Extensions -
RFC 3046 DHCP Relay Agent Information Option -
4.3 Availability
Version Support
Product Version
CX600 V600R002
Feature Dependency
The relation between IPoE and other protocols is as follows:
IPoE and DHCP snooping are mutually exclusive.

Hardware Support
When the LPUF-10 supports IPoEoA user access, the CX600 does not provide network-side
functions.
Only the LPUF-21 supports IPoE user access.
4.5 Principles
4.5.1 Basic Principle of IPoEv4
4.5.2 Basic Principle of DHCP

4.5.1 Basic Principle of IPoEv4

IPoE is a method of accessing a broadband remote access server (BRAS) by sending DHCP,
ARP, or IP packets. Users can use any of several types of media for broadband access:
telephone lines for Asymmetric Digital Subscriber Line (ADSL) access, Category 5 twisted
pair cables for Ethernet access, and wireless signals for wireless local area network (WLAN)
access. These broadband access media are physically visible to users. When a user selects any
of these types of media for broadband access, the user does not directly access an interface on
a BRAS. Instead, the user accesses an interface on an access device such as a Digital
Subscriber Line Access Multiplexer (DSLAM), a local area network (LAN) switch, or an
access point (AP) and the access device is connected to an interface on the BRAS. In this
manner, differences in broadband access users are eliminated by access devices and BRASs
can ignore users' broadband access modes. A BRAS can distinguish users through the
protocols stacks in the packets received from users. In addition, a BRAS can authenticate user
names and passwords through Web authentication, fast authentication, or bind authentication
for identifying users, and controlling and managing users including IP address allocation, IP
address management, and user accounting.
You can statically configure an IP address for an IPoE access user on a client or allocate a
static or dynamic IP address to the IPoE access user through DHCP. The static address is a
fixed address whereas the dynamic address has a valid period (also called a lease).
DHCP and ARP do not support the functions such as user authentication, link establishment,
and link monitoring. Therefore, IPoE adopt some extension function to support these
functions.
Authentication: Unlike PPP packets, DHCP or ARP packets cannot carry authentication
information such as user names or passwords. Hence, IPoE adopts bind authentication,
Web authentication, or fast authentication. Bind authentication refers to the
authentication mode in which a user is authenticated according to physical information
about the user connection. When this mode is adopted, users do not need to enter the user
names or passwords. Instead, the BRAS generates user names according to the Option 82
value, MAC address, and IP address and sends the user names together with the default
passwords configured on the BRAS to the authentication server. Only the users who pass
authentication are considered legal and are assigned IP addresses. Web authentication
refers to the authentication mode in which a user who has obtained an IP address through
DHCP or static configuration accesses the authentication page of a web server and enters
the user name and password for authentication. Fast authentication refers to the
authentication mode in which a user accesses the authentication page of a web server and
submits an authentication request without entering the user name or password. Fast
authentication is a combination of Web authentication and bind authentication.
Link establishment: Forwarding entries are created for IPoE access users. Only the traffic
of a user who passes authentication and obtains an IP address can be forwarded.
Link monitoring: The system detects the link of an IPoE access user through ARP probes.
If the system detects that the number of link failures exceeds the pre-set number, the
system considers that the user has gone offline. In this case, the system takes back the IP
address from the user and deletes the forwarding entry.
According to actual networking situations and service processing, IPoE access has the
following modes:
Common IPoE access
A user PC accesses an Ethernet interface on a BRAS through a Layer 2 device (hub or
LAN switch). The Layer 2 device does not encapsulate or change the IPoE packets from
the user. The IP packets sent from the user are encapsulated into IPoE packets when
passing through the Ethernet interface of the user PC. Then, the packets are forwarded to

the BRAS through the Layer 2 device. Therefore, the packets received on the BRAS are
IPoE packets.
Common IPoEoVLAN access
A user PC accesses an Ethernet interface on a BRAS through an 802.1Q-supporting
switch. The IP packets sent from the user are encapsulated into IPoE packets when
passing through the Ethernet interface of the user PC. Then, the LAN switch adds VLAN
tags to the IPoE packets and changes them into IPoEoVLAN packets. Finally, the
packets are forwarded to the BRAS. Therefore, the packets received on the BRAS are
IPoEoVLAN packets.
Common IPoEoQ access
A user PC accesses an Ethernet interface on a BRAS through two 802.1Q-supporting
switches and QinQ is configured on an interface on the switch close to the BRAS. The IP
packets sent from the user are encapsulated into IPoE packets when passing through the
Ethernet interface of the user PC. The switch close to the user PC adds a VLAN tag to
each IPoE packet and changes them into IPoEoVLAN packets before forwarding the
packets. When the IPoEoVLAN packets reach the switch close to the BRAS, this switch
adds another VLAN tag to each IPoEoVLAN packet before forwarding them. Therefore,
each packet finally received on the BRAS is an IP packet with two VLAN tags, that is,
an IPoEoQ packet.
Common IPoEoA access
A user PC is connected to an ATM Adaptation Layer 5(AAL5) encapsulation-supporting
ADSL modem through a network cable, the ADSL modem is connected to a DSLAM
through a telephone line, and the DSLAM is connected to an ATM interface on a BRAS
through an ATM line. In this case, the ADSL modem is set to the 1483B bridging mode
to perform Layer 2 bridging transparent transmission. The IP packets sent from the user
are encapsulated into IPoE packets when passing through the Ethernet interface of the
user PC. Then, the IPoE packets are encapsulated into IPoEoA packets when passing
through the ADSL modem. Finally, the IPoEoA packets are forwarded to the BRAS by
the DSLAM. As a result, the packets that the BRAS receives are IPoEoA packets.
Layer 2 leased line access
The networking mode for Layer 2 leased line access is the same as that for common
IPoX access, and the packets that reach the BRAS are of three types: IPoE, IPoEoVLAN,
and IPoEoQ. The only difference is that the BRAS handles the Layer 2 leased line
service in a different manner.
Layer 3 leased line access
A user PC is connected to an Ethernet interface on the BRAS or a VLAN or a PVC on
the ATM interface of the BRAS through a router or a Layer 3 switch. The packets that
reach the BRAS are of three types: IPoE, IPoEoVLAN, and IPoEoQ.
Figure 4-1 shows the structures of the protocol stacks for IPoE, IPoEoVLAN, IPoEoQ, and
IPoEoA packets.

Figure 4-1 Structure of the IPoX protocol stack
TCP/UDP
TCP/UDP TCP/UDP TCP/UDP IP
IP IP IP ETH
ETH ETH Q ETH Q Q AAL5
IPoE IPoEoVLAN IPoEoQ IPoEoA
4.5.2 Basic Principle of DHCP

A DHCP server is responsible for assigning IP addresses to clients. A DHCP client sends a
packet to the server to apply for configurations such as the IP address, subnet mask, and
default gateway. After receiving the request, the server replies with a packet that carries
required configuration information according to policies. Both DHCP Request packets and
Response packets are encapsulated through UDP. The DHCP client listens to packets through
port 68; the DHCP server listens to packets through port 67.
Figure 4-2 DHCP packet exchange
DHCP DHCP DHCP

Client Relay Server
1. DHCP Discover (broadcast)

1.DHCP Discover (unicast)
2.DHCP Offer
2.DHCP Offer
3.DHCP Request (broadcast)
3. DHCP Request (unicast)
4.DHCPACK
Obtain IP 4.DHCPACK
address
Extend address
lease 5. DHCP Request (unicast)
1/2 of lease
6.DHCPACK
7.DHCP Request( broadcast)
3/4 of lease
7.DHCP Request(unicast)
8.DHCPACK
8.DHCPACK
The DHCP client communicates with the DHCP server in any of three modes.

To obtain a valid dynamic IP address, the DHCP client communicates with the DHCP
server in any of the following modes in different phases:
1. The DHCP client accesses the network for the first time.
− When the DHCP client accesses the network for the first time, the DHCP client
undergoes the following stages to set up a connection with the DHCP server:
− Discover stage: The DHCP client searches for the DHCP server. The DHCP client
broadcasts a DHCP Discover packet, and only DHCP servers reply the Discover
packet.
− Offer stage: The DHCP servers offer IP addresses to the DHCP client. After receiving
the DHCP Discover packet from the client, DHCP servers select available IP
addresses from their IP address pools, and then send DHCP Offer packets carrying
the leased IP addresses and other settings to the DHCP client.
− Select stage: The DHCP client selects an IP address. If multiple DHCP servers send
DHCP Offer packets to the client, the DHCP client accepts only the DHCP Offer
packet that arrives first, and then broadcasts a DHCP Request packet to all the DHCP
servers. The Request packet contains the IP address that the client requires the
selected DHCP server to offer.
− Acknowledge stage: The DHCP server acknowledges IP address offering. After
receiving the DHCP Request packet from the DHCP client, the selected DHCP server
sends a DHCP ACK packet to the client. The DHCP ACK packet contains the offered
IP address and other settings. Then, the DHCP client binds its TCP/IP protocol
components to the network interface card (NIC).
− IP addresses offered by the other DHCP servers are available for the other clients.
2. The DHCP client accesses the network for the second time.
− When the DHCP client accesses the network for the second time, the DHCP client
undergoes the following stages to set up a connection with the DHCP server:
− If the DHCP client has correctly accessed the network, it just needs to broadcast a
DHCP Request packet that carries the previously-assigned IP address when it
accesses the network again. The DHCP client does not need to send a DHCP
Discover packet.
− After receiving the DHCP Request packet, the DHCP server sends a DHCP ACK
packet, instructing the DHCP client to continue to use the original IP address if the IP
address is not assigned to another DHCP client.
− If the IP address cannot be assigned to the DHCP client (for example, it has been
assigned to another client), the DHCP server responds with a DHCP NAK packet.
After receiving the DHCP NAK packet, the DHCP client sends a DHCP Discover
packet to apply for a new IP address.
3. The DHCP client extends the IP address lease.
− Generally, there is a validity period (also called a lease) for the IP address
dynamically assigned to the client. The DHCP server calls back the IP address after
the lease expires. If the DHCP client intends to continue to use this IP address, it
needs to extend the IP address lease.
− In practice, the DHCP client sends a DHCP Request packet to the DHCP server
automatically to update the IP address lease when the DHCP client starts or there is
only half of the lease duration left. If the IP address is valid, the server replies with a
DHCP ACK packet to inform the client of the new IP address lease.

Figure 4-3 DHCP packet format
op(1) htype(1) hlen(1) hops(1)

xid(4)
secs(2) flags(2)
ciaddr(4)
yiaddr(4)
siaddr(4)
giaddr(4)
chaddr(16)
sname(64)
file(128)
options(variable)
The description of each of the fields in a DHCP packet is as follows:

− op: indicates the message type. The value 1 indicates the Request packet and the
value 2 indicates the Reply packet.
− htype: indicates the hardware address type. The value 1 indicates the hardware
address of the 10 Mbit/s ethernet.
− hlen: indicates the hardware address length. In an Ethernet, the value of this field is 6.
− hops: indicates the number of hops. On the client, the value of this field must be set to
0. It can be set on a relay agent optionally.
− xid: indicates the transaction ID. The value is a random number chosen by the client
and used by the client and the server to associate requests and responses. It is chosen
by the client and returned by the server. The value is a 32-digit integer.
− secs: indicates the seconds elapsed since the client starts applying for an IP address or
extends the IP address lease. This field is filled by the client.
− flags: indicates the flags. This field contains 16 bits and only the leftmost bit is useful.
If the bit is 0, it indicates unicast; if the bit is 1, it indicates broadcast.
− ciaddr: indicates the client IP address. This field is filled in only when the client is in
the state of Bound, Renew, or Rebinding and can reply with an ARP Request.
− yiaddr: indicates 'your' (client) IP address.
− siaddr: indicates the IP address of the next server to be used in the next phase of
DHCP.
− giaddr: indicates the IP address of the DHCP relay agent.
− chaddr: indicates the client hardware address. The client must set its hardware
address. The Ethernet frame header in a UDP packet also contains this field. It is
difficult or even impossible to obtain the value of this field by viewing a UDP packet.
If this field is set in a UDP-bearing DHCP packet, the user process can easily obtain
the value of this field.
− sname: indicates the optional server host name. The value of this field is a null
terminated string. This field is to be filled by the DHCP server.
− file: indicates the boot file name. The value of this field is a null terminated string. In
a DHCP Discover packet, this field is a "generic" name or null whereas in a DHCP
Offer packet, this field is a fully qualified directory-path name.
− options: indicates the optional parameters field, which is in the format of
"code+length+data."

The DHCP client reports an address conflict.

After receiving a DHCP ACK packet from the DHCP server, the DHCP client checks the
IP address allocated by the DHCP server through duplicate address detection (DAD). If
the DHCP client finds an address conflict or that the allocated address is unusable for a
certain reason, the DHCP client sends a DHCP DECLINE packet to the DHCP server
informing that the allocated IP address is unusable.
The DHCP client releases the allocated IP address.
If the DHCP client does not need to use the allocated IP address any longer, the DHCP
client sends a DHCP RELEASE packet to the DHCP server informing that it does not
need to use the allocated IP address any longer. In this case, the DHCP server releases
the bound lease.
DHCP FORCERENEW
By sending a DHCP FORCERENEW packet, the DHCP server can trigger the dynamic
reconfiguration of a single host. The procedure is as follows:
1. The DHCP server unicasts a FORCERENEW packet to the DHCP client.
2. The DHCP client sets its own status to "renew" and sends a DHCP Request packet to the
DHCP server requesting for lease update.
3. If the DHCP server intends to allocate a new IP address to the DHCP client, the DHCP
server responds with a DHCP NAK packet.
4. The DHCP client returns to the original status and resends the DHCP Discover packet.
The format of a FORCERENEW packet is the same as that of the DHCP protocol packet.
To support DHCP FORCERENEW, a new packet type, DHCP FORCERENEW (9), is
introduced to DHCP Option 53 (DHCP message type). According to the DHCP protocol,
if the DHCP server receives no DHCP Request packet from the DHCP client because the
FORCERENEW packet is discarded, the DHCP server has to retransmit a
FORCERENEW packet. The delay is determined by the bandwidth between the DHCP
server and the DHCP client. With the increase in the number of failures, the delay grows
at an exponential rate.
Static and dynamic allocation of IP addresses
− Policies for IP address allocation
Different hosts may require different IP address leases. For a server, a fixed IP
address is required for a long term; for some hosts, IP addresses that are dynamically
assigned are needed for a long term; for some PCs, IP addresses are temporarily
assigned on demand.
To meet the preceding requirements, the DHCP server provides the following IP
address allocation policies:
− Manual allocation: An administrator assigns fixed IP addresses to a few specific hosts,
such as WWW servers.
− Automatic allocation: The server assigns fixed IP addresses to some hosts who are
connected to the network for the first time. These IP addresses can be used by the
hosts for a long time.
− Dynamic allocation: The server assigns IP addresses with leases to clients. The clients
need to reapply for IP addresses when the leases expire. This address allocation
policy is widely accepted by most clients.
− Sequence of IP address allocation
A DHCP server selects IP addresses in the following sequence and allocates an
available address to the client:
− IP address that is in the database of the DHCP sever and is statically bound to the
MAC address of the client.

− IP address assigned to the client before, that is, the IP address in the requested IP
Addr option of the DHCP Discover packet sent by the client.
− IP address first found when the server searches for available IP addresses in the
DHCP address pool.
− If no available IP address is found in the DHCP address pool, the DHCP server
searches expired IP addresses and conflict IP addresses in turn for an available IP
address. If an available address is found, the server allocates the IP address to the
client; otherwise, the server sends an error message.
− Method of preventing IP address reallocation
Before allocating an IP address to the DHCP client, the DHCP server needs to check
this IP address to avoid address conflicts.
You can run the ping command to detect an IP address to be allocated and check
whether a response is received in the specified period. If no response is received
within the specified period, the ping command is executed again until the number of
the sent ping packets reaches the maximum value. If there is still no response, it
indicates that the IP address is not in use within the network segment to which the IP
address belongs. This ensures that the IP address assigned to the client is unique.
By default, the DHCP server sends a maximum of two ping packets to the DHCP
client and waits a maximum of 500 ms for a response from the DHCP client.
− Pseudo DHCP server detection
If a private DHCP server exists on a network, clients cannot obtain correct IP
addresses and thus cannot go online because this private DHCP server interacts with
the DHCP clients during address application. Such a private DHCP server is called a
pseudo DHCP server. By running commands, you can detect pseudo DHCP servers.
− IP address reservation
DHCP supports IP address reservation for clients. Both the IP addresses in or outside
an address pool can be reserved. If an address in the address pool is reserved, the
address is no longer assignable. Addresses are usually reserved for DNS servers.
− User-defined options
The Options field in a DHCP packet is used to carry control information and
parameters that are not defined in certain protocols. If the DHCP server is configured
with options, when a DHCP client applies for an IP address, the client can obtain the
configuration information in the Options field of the DHCP REPLY packet from the
server. The value of a DHCP option ranges from 0 to 255. At present, the device
supports explicit configuration of the 10 common options of the DHCP server:
Option 1 (Subnet Mask), Option 3 (Router), Option 6 (DNS Server), Option 15
(Domain Name), Option 44 (NetBIOS name server), Option 46 (NetBIOS node type),
Option 51 (Lease), Option 58 (Renewal Time), Option 59 (Rebinding Time), and
Option 120 (SIP Server). In addition, the device supports user-defined options.
− Option resolution
The DHCP server supports resolution of certain options carried in a packet sent from
a DHCP client for client authentication and address allocation policies. At present, the
options that the device can resolute include: Option 12 (Host Name), Option 50
(Requested IP Address), Option 53 (DHCP Message Type), Option 55 (Parameter
Request List), Option 60 (Vendor class identifier), Option 61 (Client-identifier), and
Option 82 (DHCP Relay Agent Information Option).

Table 4-1 Usages of DHCP options
Option ID Usage
Option 60 When a certain terminal, for example, a set top box
(STB), accesses the network, the BRAS cannot assign an
IP address to it because the BRAS does not know the
user name and cannot know which domain the terminal
belongs to. If the terminal sends a DHCP Request
message that contains Option 60, the BRAS can assign
an IP address to the terminal according to the
information in Option 60 after receiving the DHCP
Request packet.
Option 82 When receiving a DHCP packet from a client, an
external DHCP or BOOTP server does not know the
physical location of the client. In this case, the DHCP or
BOOTP server cannot assign a required IP address to the
client but can allocate an IP address to the client from
the address pool in sequence. As a DHCP relay agent,
the BRAS can fill Option 82 with the physical location
of the client when relaying a DHCP packet from the
client. In this manner, the BRAS instructs the DHCP
server to allocate an IP address to the client according to
the information filled in Option 82.
− IP address lease
The DHCP server can specify different leases for addresses in different address pools.
The addresses in an address pool must be of the same lease.
Generally, there is a valid period for the IP address dynamically allocated to the client.
The DHCP server calls back the IP address after the valid period expires. If the client
intends to continue using this IP address, it needs to extend the IP address lease.
When obtaining an IP address, the DHCP client enters the binding state. The client
has three timers to control lease update, rebinding, and lease expiration. When
assigning an IP address to the client, the DHCP server can set the timers. If the DHCP
server does not set the values for the timers, the client uses the default values. Table
4-2 lists the default values of the timers.
Table 4-2 Default values of timers
Timer Default Value

Lease renewal timer 50% of the overall lease
Rebinding timer 87.5% of the overall lease
Lease expiration timer Overall lease
When the lease renewal timer expires, the DHCP client must renew its IP address
lease. The DHCP client automatically sends a DHCP Request packet to the DHCP
server that assigns the currently-used IP address to the DHCP client. If the IP address
is valid, the DHCP server replies with a DHCP ACK packet to inform the client of a

new lease, and then the client re-enters the binding state. If the DHCP client receives
a DHCP NAK packet from the server, it enters the initializing state.
After the DHCP client sends a DHCP Request packet for extending the lease, the
client remains in the updating state and waits for a response. If the client does not
receive a response from the server after the rebinding timer expires, the client
considers that the original DHCP server is unavailable and starts to broadcast a
DHCP Request packet.
Any DHCP server on the network can reply to this request with a DHCP ACK or
DHCP NAK packet.
If receiving a DHCP ACK packet, the client returns to the binding state and re-sets
the lease renewal timer and binding timer; if all the received packets are DHCP NAK
packets, the client goes back to the initializing state. At this time, the client must stop
using this IP address immediately, return to the initializing state, and request a new IP
address.
If the client does not receive any response before the lease expiration timer expires,
the client must stop using the current IP address immediately and return to the
initializing state.
− Hot backup
If the router is installed with two MPUs or SRUs, the system backs up the DHCP data
on both MPUs or SRUs in a real-time manner. When a master/slave switchover
occurs, the DHCP server on the standby board still works normally.
− DHCP relay agent
The early DHCP protocol applies to only the situation that the DHCP client and
DHCP server are on the same network segment. Thus, it is necessary but
uneconomical to configure a DHCP server on each network segment. The DHCP
relay function is thus introduced to address this problem. Through a DHCP relay
agent, a DHCP client can communicate with the DHCP server on another network
segment and apply for a valid IP address. In this manner, DHCP clients on multiple
network segments can share one DHCP server. This saves costs and facilitates
centralized management. The DHCP relay agent forwards a DHCP broadcast packet
to the DHCP server that is in another network segment and fills the giaddr field of the
DHCP broadcast packet with the IP address of the relay interface to identify the
network segment to which the allocated address belongs. Both the DHCP relay agent
and the DHCP server listen to packets through port 67.
4.6 Applications
Typical Applications of IPoE
IPoE users include private users and leased-line users.
Private users are the users accessing a BRAS through Layer 2 devices, such as a LAN switch
or an IP DSLAM. A private user has independent service attributes, and a BRAS performs
separate authentication and charging for a private user. Private users can be categorized into
Layer 2 access users and Layer 3 access users.
A Layer 2 access user accesses a BRAS through an Ethernet device (such as a LAN switch) or
an ADSL device (such as a DSLAM). An access user can be allocated with a DHCP address
on a local BRAS or on a remote DHCP server. Figure 4-4 shows address allocation on a local
BRAS.

Figure 4-4 Networking diagram of local address allocation for Layer 2 access users
DHCP/IP/ARP
VLAN DNS Server AAA Server

1001
IPv4 user
IPv4
VLAN network
IPv4 user1002
LSW BRAS
WEB
VLAN
1003 Server
IPv4 user
A Layer 2 user can go online by sending a DHCP, IP, or ARP packet.

Figure 4-5 shows how a Layer 2 user goes online by sending a DHCP packet.
Figure 4-5 Login process through a DHCP packet
AAA
Client BRAS
Server
DHCPDiscover
Authenticationrequest
Authenticationresponse
DHCP Offer
DHCPRequest
DHCPACK
Usergoes
online
A DHCP client sends a DHCP Discover or DHCP Request packet to a BRAS. After receiving
the DHCP Discover or DHCP Request packet, the BRAS performs authentication,
authorization, address allocation, forwarding control, and accounting management. In addition,
the BRAS sends the IP address and parameters to the DHCP client by forwarding a DHCP
Offer or DHCP ACK packet. Only the user who successfully logs in to the BRAS can access
the Internet. The user cannot access the Internet through the BRAS by using an address that is
not allocated by the BRAS. IP addresses are locally managed. Therefore, the allocation,
release, and lease extension of IP addresses must be performed on the BRAS. If an IP address
with a validity period is allocated to the client, the client needs to apply for lease extension by
sending a DHCP Request packet to the BRAS at a certain time. If the lease is successfully
extended, the user can access the Internet during the extended lease. If the lease extension
fails, the BRAS sends a DHCP NAK packet to the client and logs the user off. In addition, the

BRAS takes back the allocated address and QoS resources for ensuring QoS. If the client does
not start lease extension or rebinding during a particular period, the BRAS logs the user off
and takes back the allocated address when the lease expires.
DHCP clients are allocated IP addresses locally through a local address pool. The addresses in
the local address poll are allocated in the following sequence:
IP address statically bound to the client MAC address
IP address previously assigned to the client, that is, the IP address in the requested IP Addr
option of the DHCP Discovery packet sent by the client
First available IP address found by the server in the DHCP address pool
If no available IP address is found in the DHCP address pool, the DHCP server searches
expired IP addresses and conflict IP addresses in turn for an available IP address. If an
available address is found, the server allocates the IP address to the client; otherwise, the
server sends an error message.
If one or several addresses in the IP address pool are not allowed to be used, you can provide
protection for this address pool in any of the following methods:
Locking the address pool
You can run a command to lock the address pool. Then, no address in this address pool
can be allocated. Commonly, this method applies to an address pool in which an address
is being used by an online user. After an address pool is locked, the addresses in the
address pool cannot be allocated any more. After all the online users go offline and IP
addresses in the address pool are released, you can delete this address pool.
IP address prohibition
If the network is rather complicated, you may need to prohibit certain IP addresses.
IP address recycling
When an IP address in an address pool is abnormal and cannot be used, for example, an
address that is actually not in use is in the state of being used, you can run a command to
forcibly take back this IP address.
To support VPN users, the device supports the configuration of VPN instances in an address
pool. Addresses of different VPN instances can overlap.
A DHCP user goes offline when any of the following situation exists:
A DHCP Release packet is sent to trigger user logoff; the remaining lease or traffic is
exhausted.
ARP detection fails.
The idle connection is cut off.
A management command is executed to cut off the client.
The first two situations are both normal situations. In either of these two situations, the user
can go online again only by sending DHCP packets. The other situations are abnormal
situations. In any of these abnormal situations, the DHCP user can go online again by sending
IP or ARP packets if the BRAS allows the user to go online by sending IP or ARP packets. If
the network fails temporarily or users have not accessed the Internet for a long time, to save
network resources, the BRAS logs the users off. The abnormal logoff of a user is not initiated
by the user. If the logoff of a user is triggered by a DHCP Release packet, the DHCP client
cannot detect the user logoff as a PPP client. Therefore, the user may continue network access.
In this case, you can enable the client to access the network by sending IP or ARP packets or
enable DHCP Forcerenew so that the BRAS instructs the client to send a DHCP Request

packet. After receiving the DHCP Request packet, the DHCP server responds with a DHCP
NAK packet to force the client to enter the initialized state. The DHCP client resends a DHCP
Discover packet to apply for login.
Both a static user and a user logged out abnormally can go online by sending IP or ARP
packets. A static user has been assigned a fixed IP address on the client and does not need to
be assigned an address on the BRAS. Therefore, the static user can go online only by sending
IP or ARP packets. After receiving an IP or ARP packet from a user, the BRAS resolutes
parameters such as the IP address and the MAC address and determines whether the user is
legal. Then, the BRAS performs binding authentication for the user. After passing the
authentication, the user can log in and access the network.
The device can log a static user off through ARP probes or idle cutoff.
Figure 4-6 Networking diagram of remote address allocation for a Layer 2 access user
DHCP/IP/ARP
VLAN DNS Server AAA Server

1001
IPv4 user
IPv4
VLAN network
IPv4 user1002
LSW BRAS
WEB
VLAN Server
1003 DHCP
IPv4 user Server
A DHCP access user can obtain an IP address from a remote DHCP server. In this case, the
BRAS performs only user authentication, authorization, accounting, and forwarding control
but does not manage IP addresses. The BRAS forwards the DHCP packet from a user to the
remote DHCP server and sends the reply from the DHCP server to the DHCP client. Figure
4-6 shows the address allocation process through a remote DHCP server.
Figure 4-7 shows the process of remote login of a DHCP user.

Figure 4-7 Remote login of a DHCP user
AAA DHCP
Client BRAS
Server Server
DHCPDiscover
Authentication
request
Authentication
reply
DHCPDiscover
DHCP Offer
DHCP Offer
DHCPRequest
DHCPRequest
DHCPACK
DHCPACK
Usergoes
online
By applying a remote address pool in a domain, the BRAS can enable the remote DHCP
server to allocate an address of an access user. A remote address pool does not contain any IP
addresses but indicates the corresponding DHCP server. When a remote address pool is used,
the BRAS replaces the user to send a DHCP Request packet to apply for an IP address from
the DHCP server or extend the address lease, or relays the DHCP Request packet from the
user.
A remote address pool can be bound with a DHCP server group, which contains a maximum
of two DHCP servers. The servers in a DHCP server group can work in active/standby or load
balancing mode. By default, the servers in a DHCP server group work in active/standby mode.
The server configured first acts as the active server. The active server takes priority of standby
servers in address allocation. When the servers in a DHCP server group work in load
balancing mode, a Layer 3 user accesses the BRAS through a Layer 3 device. A user can go
online by sending a DHCP packet or an IP packet.
Figure 4-8 Networking diagram of Layer 3 access users adopting Web authentication
RADIUS Server
Internet
user LSW Router BRAS
WEB Server

The BRAS does not know the MAC address of a user accessing the network through a Layer
3 device. Therefore, the BRAS does not allocate an IP address to a user who adopts Web
authentication. An RTA, a Layer 3 device, allocates an IP address to a user accessing the
network through a Layer 3 device. After receiving an IP packet from a Layer 3 user, the
BRAS checks whether it supports the Layer 3 user. If yes, the BRAS allows the user to
perform Web authentication. After the client visits the web page and submits the user name
and password, the Layer 3 user can access the network if it passes authentication.
In the situation that a user accesses the network through a Layer 3 device, a Layer 3 router
acts as a DHCP relay agent and relays the DHCP packet from the client to the BRAS. After
authenticating the user, the BRAS allocates an idle IP address to the user according to the
giaddr field. Alternatively, the RADIUS server can allocate an IP address to the user and send
the DHCP Response packet to the client. The address pool selection mode for Layer 3 access
is different from that for Layer 2 access. For a Layer 2 access user, the address pool searched
is in the domain to which the user belongs. For a Layer 3 access user, the address pool of the
same gateway IP address is searched according to the giaddr field in the DHCP packet. This
ensures that the allocated address is on the same network segment with the gateway IP
address.
Figure 4-9 Networking diagram of Layer 3 DHCP users
AAA Server
IPv4 user
Layer2
Internet
network
IPv4 user
Router BRAS
WEB
Server
IPv4 user
Leased line access refers to the access mode in which a certain Ethernet or ATM interface on
the BRAS or certain VLANs or PVCs on a certain interface of the BRAS are leased by a
group of users. Multiple users can access the network through one leased line, but the BRAS
considers all the users as a single user. The BRAS uniformly performs authentication,
accounting, bandwidth control, access right control, and QoS management for the users that
access the network through one leased line. According to the networking modes of leased line
access, leased lines can be classified into Layer 2 leased lines, Layer 3 leased lines, and Layer
2 VPN leased lines.
Layer 2 leased line
Layer 2 leased line access refers to the access mode in which a user accesses a certain
interface on the BRAS or a certain VLAN or PVC on a certain interface of the BRAS
through a LAN switch or a DSLAM. A Layer 2 leased line is connected to the network
when the protocol status on the interface is Up. A leased line user can access the network
through DHCP or ARP. A leased line user allocated with a dynamic IP address accesses
the network through DHCP; a leased line user allocated with a static IP address accesses
the network through ARP. The services of leased line users are controlled through the
service control policy of the leased line regardless of the access modes of users. All the

traffic passes through the leased line and the BRAS restricts the bandwidth of the leased
line in a unified manner. Figure 4-10 shows Layer 2 leased line access.
Figure 4-10 Networking diagram of Layer 2 leased line access
subscriber LSW
Internet
BRAS
subscriber DSLAM
Layer 3 leased line

Layer 3 leased line access refers to the access mode in which a user accesses a certain
interface on the BRAS or a certain VLAN or PVC on a certain interface of the BRAS
through a Layer 3 device such as a router. When this access mode is adopted, the BRAS
performs the forwarding function of a router. The access router is in charge of assigning
IP addresses to Layer 3 leased line users. The BRAS is in charge of only packet
forwarding and validity inspection. A Layer 3 leased line is connected to the network
when the protocol status on the interface is Up. Then, the users of the leased line can
access the network without accessing the router. The services of the users of the Layer 3
leased line are controlled through the service control policy of the leased line. All the
traffic passes through the leased line and the BRAS restricts the bandwidth of the leased
line in a unified manner.
Figure 4-11 Networking diagram of Layer 3 leased line access
Access
network
subscriber Router
Internet
BRAS
Access
network
ATM
subscriber
Switch
Layer 2 VPN leased line

The Layer 2 VPN leased line access mode is similar to the Layer 2 leased line access
mode except that in this mode, each access interface is bound to a Layer 2 VPN. When
the Layer 2 VPN leased line access mode is adopted, the BRAS functions as a UPE. A
Layer 2 VPN leased line is connected to the network when the protocol status on the

interface is Up. Then, the users of the leased line can access the network without
accessing the BRAS. The services of leased line users are controlled through the service
control policy of the leased line regardless of the access modes of users. All the traffic
passes through the leased line and the BRAS restricts the bandwidth of the leased line in
a unified manner.
Figure 4-12 Networking diagram of Layer 2 VPN leased line access
DNSserver RADIUSserver
VLAN1
VLAN2
......
VPN Internet
VLAN100 LAN
BRAS Router
Switch
4.7 Impact
4.7.3 Defects

None.

None.
4.7.3 Defects
None.


Term
Term Definition
ADSL Acronym for asymmetric digital subscriber line. Technology and
equipment allowing high-speed digital communications, including
video signals, across an ordinary twisted-pair copper phone line,
with speeds up to 8 Mbit/s downstream (to the customer) and up to
640 Kbit/s upstream. ADSL access to the Internet is offered by some
regional telephone companies, offering users faster connection than
those available through connections made over standard phone lines.
Access service The access service provides access services to the Internet for all
subscribers, including bandwidth purchase and user priority change.
Acronyms
Acronym Full Spelling
AAA Authentication, Authorization and
Accounting
ARP Address Resolution Protocol
BRAS Broadband Remote Access Server
DHCP Dynamic Host Configuration Protocol
DSLAM Digital Subscriber Line Access Multiplexer
IPoE IP over Ethernet
IPoEoA IP over Ethernet over AAL5
IPoEoQ IP over Ethernet over QinQ
IPoEoVLAN IP over Ethernet over VLAN
QoS Quality of Service
RADIUS Remote Authentication Dial-In User Service
UDP User Datagram Protocol
VPN Virtual Private Network

5 IPoEv6
About This Chapter

5.1 Introduction to IPoEv6
5.2 References
5.3 Availability
5.4 Enhancement
5.5 Principles
5.6 Applications
5.7 Impact
5.1 Introduction to IPoEv6

Definition
IPv6 over Ethernet (IPoEv6) access refers to the access mode in which users access a BRAS
by sending Dynamic Host Configuration Protocol for IPv6 (DHCPv6) packets, Neighbor
Discovery (ND) packets, or IPv6 packets. In IPoEv6 access mode, users can directly access
the Internet using Web browsers, without having to install client dial-in software on their PCs.
An IPoE dual-stack user can have both an IPv4 address and an IPv6 address. The IPoE
dual-stack access is the combination of the IPoE access and the IPoEv6 access. An IPoE
dual-stack user obtains an IPv4 address through IPoE and an IPv6 address through IPoEv6;
however, during this process, the user is authenticated only once.
IPv6, also called IP Next Generation (IPng), is the second-generation standard protocol of
network layer protocols. As a set of specifications defined by the Internet Engineering Task
Force (IETF), IPv6 is the upgraded version of IPv4. The most obvious difference between
IPv4 and IPv6 is that IPv4 addresses are of 32 bits whereas IPv6 addresses are of 128 bits.
IPv6 address autoconfiguration has two modes, stateful address autoconfiguration and
stateless address autoconfiguration. IPv4 has only one address assignment mode, the DHCP
mode.

In stateless address autoconfiguration mode, a user running ND sends a Router Solicitation

(RS) message to a neighboring router. After receiving the RS message, the router assigns an
IPv6 prefix to the user through a Router Advertisement (RA) message.
In stateful address autoconfiguration mode, a DHCPv6 client sends an Information-Request
message containing the IPv6 address and information about the DNS server to the DHCPv6
server. After receiving the message, the DHCP server replies with the required configuration
information according to the policy.
Purpose
With the development of the Internet, the shortage of IPv4 address spaces becomes
increasingly serious. IPv6 solves the problem of IP address exhaustion. With the development
of the IPv6 Internet, users need to obtain IPv6 addresses for accessing network resources.
5.2 References

RFC 2461 Neighbor Discovery for IP Version 6 (IPv6)
RFC 2462 IPv6 Stateless Address Autoconfiguration
RFC 3122 Extensions to IPv6 Neighbor Discovery
RFC 3315 Dynamic Host Configuration Protocol for IPv6
(DHCPv6)
RFC 3633 IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6
RFC 3646 DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)
RFC 3736 Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6
5.3 Availability
None.
License Support
None.

Version Support
Product Version
CX600 V600R002
Feature Dependency
None.
Hardware Support
Board Supporting IPoEv6 Board Supporting Access of IPv4/IPv6
Access Dual-Stack Users
LPUF-21 and LPUF-40 LPUF-21and LPUF-40
5.4 Enhancement
None.
5.5 Principles
Through Router Advertisement (RA) messages, routers can instruct clients how to perform
address autoconfiguration. For example, routers can specify stateful or stateless address
autoconfiguration for clients.
Generally, address autoconfiguration of network nodes has two modes: stateful address
autoconfiguration and stateless address autoconfiguration. Stateful address autoconfiguration
is mainly based on the Dynamic Host Configuration Protocol (DHCP). Therefore, in IPv6,
stateful address autoconfiguration is mainly based on DHCPv6. Stateless address
autoconfiguration is used to configure addresses for interfaces through the Neighbor
Discovery Protocol (NDP).
5.5.1 Principles of Stateless Address Autoconfiguration
5.5.2 Principles of DHCPv6 Access
5.5.3 Principles of IPoEv6 Access
5.5.4 ND Proxy
5.5.1 Principles of Stateless Address Autoconfiguration

The process of stateless address autoconfiguration is as follows:
1. After a client is started, a link-local address is generated for the client by prepending the
link-local prefix FE80::0 to the interface ID.

2. The client performs Duplicate Address Detection (DAD) on the link-local address by
sending a Neighbor Solicitation (NS) message in the broadcast domain. If the client
receives a Neighbor Advertisement (NA) message from another device, it indicates the
link-local address is a duplicate address. Therefore, another link-local address needs to
be generated for the client. After another link-local address is generated, the client still
needs to perform DAD on the link-local address until a unique link-local address is
obtained.
3. The client sends a Router Solicitation (RS) message.
4. The router replies with a Router Advertisement (RA) message, containing the following
information:
− Whether address autoconfiguration is adopted
− Supported address autoconfiguration modes (stateless or stateful)
− One or multiple link prefixes (Nodes on the local link can perform address
autoconfiguration by using these address prefixes)
− Lifetime of link prefixes
− Whether the router sending an RA message can be used as the default router
If the router can be used as the default router, the lifetime, expressed in seconds, of
the default router is also contained in the message.
− Other configuration information about the client, such as the hop limit and the MTU
of the packet initiated by the client
5. The client receives an RA message from the router. If address autoconfiguration is
specified in the RA message, and the RA message contains correct link prefixes, the link
prefixes together with interface IDs are used to generate global unicast addresses. Then,
DAD is performed on each address. If the RA message carries a flag, indicating that
other configuration information in addition to the IP address needs to be obtained in the
stateful manner, the client needs to send a DHCPv6 Information-Request message
containing the required configuration information. If stateful address autoconfiguration is
specified in the RA message, the client sends a DHCPv6 Solicit message to obtain an
address and other configuration information.
5.5.2 Principles of DHCPv6 Access

Principles of the DHCPv6 Server
DHCPv6 servers are responsible for assigning IPv6 addresses/prefixes and other
configuration information (such as configuration information about the DNS server) to clients.
Clients send Information-Request messages to a specific server to obtain required
configuration information. After receiving an Information-Request message, each server
replies with a Response message containing the configuration information required by the
client according to policies. Both the Request and Response messages are encapsulated in
UDP packets.
DHCP Unique Identifier (DUID) of a DHCPv6 device
During the interaction between a DHCPv6 client and a DHCPv6 server, each DHCPv6
client or DHCPv6 server is identified by a unique DUID. On a DHCPv6 server, the client
DUID identifies a DHCPv6 client and is used in the local address allocation policy. On a
DHCPv6 client, the server DUID is used to identify a DHCPv6 server. DUIDs can be
generated in the following modes:
− DUID Based on Link-layer Address Plus Time (DUID-LLT)
In DUID-LLT mode, DUIDs are generated for DHCPv6 devices based on link-layer
addresses and the time.

− DUID Assigned by Vendor Based on Enterprise Number (DUID-EN)

In DUID-EN mode, DUIDs are generated for DHCPv6 devices based on the
enterprise numbers registered with the Internet Assigned Numbers Authority (IANA).
− DUID Based on Link-layer Address (DUID-LL)
In DUID-LL mode, DUIDs are generated for DHCPv6 devices based on link-layer
addresses.
DHCPv6 multicast address
Similar to a DHCPv4 client, a DHCPv6 client does not need to be configured with the
IPv6 addresses of DHCPv6 servers. Instead, the DHCPv6 client sends a Solicit message
with a multicast destination address to locate DHCPv6 servers. When the DHCPv6 client
discovers multiple servers, the client selects a server according to a certain policy (such
as the Preference option). In DHCPv6, two multicast addresses are defined:
− All_DHCP_Relay_Agents_and_Servers (FF02::1:2)
This multicast address is used by all servers and relay agents in a broadcast domain.
When a client initiates DHCPv6 interaction, it interacts with all servers and relay
agents through this address.
− All_DHCP_Servers (FF05::1:3)
This multicast address is used by all servers in a broadcast domain. When a relay
agent needs to forward messages to all servers but it does not know the unicast
addresses of the servers, the relay agent can use this multicast address to forward
messages.
Interaction model between a DHCPv6 client and a DHCPv6 server
DHCPv6 adopts the client/server model for communications. A client sends an
Information-Request message to a specific server for a valid dynamic IPv6
address/prefix or other configuration information. After receiving the
Information-Request message, each server replies with a Response message containing
the configuration information for the client according to policies. At different stages,
DHCPv6 clients and servers exchange different information in different modes:
− Exchanging configuration information, involving two steps
− After a client obtains an IPv6 address/prefix in the stateless address configuration
manner, it multicasts a DHCPv6 Information-Request message.
− After a server receives the Information-Request message, it replies with a Response
message containing the configuration information for the client.
− Exchanging IPv6 addresses/prefixes and other configuration information, involving
two steps:
When a client accesses the network for the first time, it can obtain an IPv6
address/prefix and configuration information based on the following steps:
− When a client accesses the network for the first time, it multicasts a DHCPv6 Solicit
message containing the Rapid Commit option.
− After receiving the DHCPv6 Solicit message from the client, a DHCPv6 server
selects an unassigned IPv6 address/prefix from the IPv6 address/prefix pool and
assigns it to the client. If the server supports two-step interaction, it sends a DHCPv6
Response message containing the leased IPv6 address/prefix and other configuration
information. Otherwise, the server sends a DHCPv6 Advertise message.
− After receiving the Response message, the client uses the IPv6 address/prefix and
other configuration information in the Response message. If the client receives only a
DHCPv6 Advertise message within the specified period, the client undergoes four
stages to obtain the configuration information according to the configured policy.

This situation is applicable to the scenario where only one server exists on the network. Otherwise, IPv6
addresses/prefixes are wasted.
− Exchanging IPv6 addresses/prefixes and other configuration information, involving
four stages:
When a DHCPv6 client accesses the network for the first time, similar to a DHCPv4
client, the DHCPv6 client undergoes four stages to obtain an IPv6 address/prefix and
other configuration information:
− Discovering stage: indicates the stage at which the DHCPv6 client searches for a
DHCPv6 server. The client broadcasts a DHCPv6 Solicit message.
− Offering stage: indicates the stage at which the DHCPv6 server offers an IPv6
address/prefix to the DHCPv6 client. After receiving the DHCPv6 Solicit message
from the client, the DHCPv6 server selects an unassigned IPv6 address/prefix from
the IPv6 address/prefix pool, and then sends a DHCPv6 Advertise message
containing the leased IPv6 address/prefix and other configuration information to the
client.
− Selecting stage: indicates the stage at which the DHCPv6 client selects an IPv6
address/prefix. If multiple DHCPv6 servers send DHCPv6 Advertise messages to the
client, the client selects a server according to the configured policy. If the Advertise
message contains the Server Unicast option, and the client also supports this option,
the client unicasts a DHCPv6 Request message to each DHCPv6 server. Otherwise,
the client multicasts a DHCPv6 Request message containing information used to
instruct the selected DHCPv6 server to offer an IPv6 address/prefix.
− Acknowledging stage: indicates the stage at which the DHCPv6 server acknowledges
the IPv6 address/prefix to be offered. After receiving the DHCPv6 Request message
from the client, the DHCPv6 server sends a DHCPv6 Response message to the client.
The DHCPv6 Response message contains the offered IPv6 address/prefix and other
configuration information. After receiving the DHCPv6 Response message, the client
uses the offered IPv6 address/prefix and other configuration information.
Except the address offered by the DHCPv6 server selected by the DHCPv6 client, the unassigned IPv6
addresses/prefixes offered by other DHCPv6 servers are available for other DHCPv6 clients.
− The DHCPv6 client extends the IPv6 address/prefix lease.
When a DHCPv6 client assigns an IPv6 address/prefix to a client, the server sends a
message containing the preferred lifetime, valid lifetime, lease renew time, and
rebind time. The relationship between them is as follows: lease renew time < rebind
time < preferred lifetime < valid lifetime.
The preferred lifetime is used to limit the lease renew time and rebind time. By
default, the lease renew time and rebind time account for 50% and 80% respectively
of the preferred lifetime.
The valid lifetime is the lease set for the IPv6 address/prefix assigned to a client. The
server retrieves the IPv6 address/prefix after the valid lifetime expires. If the client
intends to continue to use this IPv6 address/prefix, it needs to extend the IPv6
address/prefix lease before the valid lifetime ends.
When the lease of the IPv6 address/prefix expires, the DHCPv6 client automatically
sends a DHCPv6 Renew message to the server. If the client and server support
unicast, the client unicasts a DHCPv6 Renew message. Otherwise, the client
broadcasts a DHCPv6 Renew message.
After the DHCPv6 server receives the DHCPv6 Renew message, if the contained
IPv6 address/prefix is valid and the lease can be renewed, the server replies with a
DHCPv6 Response message containing the new lease of the IPv6 address/prefix.

After receiving the DHCPv6 Response message from the server, the client renews the
lease of its IPv6 address/prefix.
When the rebind time expires, if the DHCPv6 client does not finish renewing the
lease of its IPv6 address/prefix, it broadcasts a DHCPv6 Rebind message to all
available servers.
After the DHCPv6 server receives the DHCPv6 Rebind message, if the contained
IPv6 address/prefix is valid and the lease can be renewed, the server replies with a
DHCPv6 Response message containing the new lease of the IPv6 address/prefix.
After receiving the DHCPv6 Response message from the server, the client renews the
lease of its IPv6 address/prefix.
− When the link to which the DHCPv6 client is connected changes, the client needs to
check whether its IPv6 address/prefix is still available.
When the link to which the DHCPv6 client is connected changes, for example, the
network cable is loosely connected, the client needs to send a DHCPv6 Confirm
message to the server to check whether its IPv6 address/prefix is still available.
If the IPv6 address needs to be validated, the client multicasts a DHCPv6 Confirm
message containing the IPv6 address to be validated.
After the DHCPv6 server receives the DHCPv6 Confirm message, if the IPv6
address/prefix assigned to the client is still available, the server replies with a
DHCPv6 Response message in which the status of the IPv6 address is set to Success.
After receiving the DHCPv6 Response message from the server, the client continues
to use this IPv6 address.
If the IPv6 prefix needs to be validated, the client multicasts a DHCPv6 Rebind
message containing the IPv6 prefix to be validated. The DHCPv6 server processes
the received Rebind message and then replies with a Response message. After the
client receives the Response message from the server, if the lifetime of the IPv6
prefix is not 0, the client continues to use this prefix and renew the lease.
− The DHCPv6 client detects a duplicate IPv6 address.
If the DHCPv6 client detects a duplicate IPv6 address, it notifies the server of the
address conflict.
That is, the DHCPv6 client sends a DHCPv6 Decline message containing the
duplicate IPv6 address to the server. The source address of the Decline message
cannot be the duplicate address. If the client and server support unicast, the client
unicasts a DHCPv6 Decline message to the server. Otherwise, the client broadcasts a
DHCPv6 Decline message to the server.
When receiving the DHCPv6 Decline message, the server marks the IPv6 address
contained in the Decline message as a duplicate address.
− The DHCPv6 client releases an IPv6 address/prefix.
To release its IPv6 address/prefix, the DHCPv6 client sends a DHCPv6 Release
message containing the IPv6 address/prefix to be released to the server. If the client
and server support unicast, the client unicasts a DHCPv6 Release message. Otherwise,
the client broadcasts a DHCPv6 Release message.
After receiving the DHCPv6 Release message from the client, the server releases the
IPv6 address/prefix assigned to the client and responds with a Reply message.
Lease of an IPv6 prefix pool
Different IPv6 prefix pools can be set with different leases by DHCPv6 servers, but
prefixes in one prefix pool have the same lease.
Renew time and rebind time of an IPv6 address pool

In different IPv6 address pools, the respective proportions of the renew time and rebind
time in the preferred lifetime can be set to different values. In one IPv6 address pool, the
respective proportions of the renew time and rebind time in the preferred lifetime are
fixed.
Hot standby
For a router with two SRUs/MPUs, DHCPv6 data on the two SRUs/MPUs are backed up
in real time. Therefore, after master/slave switchover is performed, related DHCPv6
functions on the slave SRU/MPU can still work properly.
Principles of the DHCPv6 Relay Agent

Similar to DHCP relay agents, DHCPv6 relay agents are introduced to transmit DHCPv6
multicast packets between DHCPv6 clients and DHCPv6 servers that are on different network
segments.
In the actual networking, the DHCPv6 relay agent is generally a specific interface of a router.
This interface needs to be configured with an IPv6 relay address or an outbound interface to
encapsulate and forward DHCPv6 packets.
If an IPv6 relay address is configured, the interface (the DHCPv6 relay agent)
encapsulates a Relay-Forward message with the configured unicast relay address being
the destination address, and then forwards the encapsulated message to the specified
server according to the routing table.
If an outbound interface is configured, the interface (the DHCPv6 relay agent)
encapsulates a Relay-Forward message with the protocol multicast address
All_DHCP_Servers (FF05::1:3) being the destination address, and then forwards the
encapsulated message through the configured outbound interface.
5.5.3 Principles of IPoEv6 Access

IPoEv6 access refers to the access mode in which users access the BRAS by sending DHCPv6
packets, ND packets, or IPv6 packets.
According to the used media, the broadband access include the Asymmetric Digital
Subscriber Line (ADSL) access using telephone cables, Ethernet access using Category 5
twisted pair cables, and Wireless Local Area Network (WLAN) access using wireless signals.
Users are connected to the BRAS through access devices such as the Digital Subscriber Line
Access Multiplexer (DSLAM), LAN Switch, and Access Point (AP). The differences in
physical connections are obscured by access devices. As a result, the BRAS does not have to
be concerned with the access modes of users; instead, it distinguishes users by the protocol
stack of packets sent by the terminals to the BRAS. By using various methods such as binding
authentication, the BRAS identifies users according to the user names and passwords of the
users, and then manages the users. For example, the BRAS assigns IP addresses to users and
accounts the services of access users.
DHCPv6 and ND do not support functions such as user authentication, link establishment,
and link monitoring. Therefore, IPoE adopt some extension function to support these
functions.
Authentication: Unlike that in PPP access mode, neither DHCPv6 packets nor ND
packets carry authentication information such as the user name and password. Therefore,
in IPoEv6 access mode, binding authentication is used to authenticate users. In binding
authentication, the information about the physical connections of users is used to
authenticate users. Users do not need to enter their user names and passwords. The
BRAS generates user names according to the information such as Option82 fields, MAC

addresses, and IP addresses, and sends the user names together with the default
passwords configured on the BRAS device to the authentication server for authentication.
Only the users that pass the authentication are assigned IP addresses.
Link establishment: Devices set up related forwarding entries for online IPoEv6 users,
and only the users that pass the authentication and obtain IPv6 addresses can forward
traffic.
Link monitoring: ND detection is used to detect link status for an IPoEv6 user. If the ND
detection fails for the specified number of times, the IPoEv6 user is considered offline,
and the IPv6 address of the IPoEv6 user is reclaimed and the related forwarding entry is
deleted.
The IPoE dual-stack access refers to the access mode in which a user has both an IPv4 address
and an IPv6 address and IPoE authentication can be triggered through DHCP packets, ARP
packets, IP packets, DHCPv6 packets, ND packets, or IPv6 packets. After receiving a Request
message, the BRAS performs the following operations: If the user is a new user, the BRAS
performs authentication and authorization for the user. If the user is a dual-stack user that has
obtained an IP address of a specified type, the BRAS does not authenticate the user; instead,
the BRAS performs authorization for the user according to the authentication result.
The IPoE dual-stack access supports binding authentication and Web authentication. Web
authentication is an interactive authentication mode in which the user that has obtained an IP
address opens the authentication page on the Web authentication server, and enters the user
name and password to be authenticated. Currently, only the IPv4 Web authentication server
can be used to authenticate dual-stack users.
5.5.4 ND Proxy
When two hosts whose addresses have the same prefix communicate with each other, they do
not search routing tables. Instead, one of them sends a Neighbor Solicitation (NS) packet to
obtain the link layer address corresponding to the destination address, and then use the link
layer address to encapsulate data packets.
In practice, hosts whose addresses have the same prefix cannot belong to the same broadcast
domain because NS packets cannot be sent to a destination host and thus the hosts cannot
communicate with each other.
To make these hosts communicate with each other, you can enable ND proxy on the BRAS so
that the BRAS rather than a host can reply with a Neighbor Advertise (NA) packet that carries
the link layer address of the BRAS. With the help of the BRAS, two hosts whose addresses
have the same prefix can communicate with each other.

Figure 5-1 Principle of ND proxy
I nt er f ace
I nt er f ace B
A
PC1 PC2
1234: : 1/ 64 1234: : 2/ 64
Needs t o send PC2 dat a
packet s
NS ( r eqest s f or t he 1234: : 2/
64 MAC addr ess)
NA ( r epl i es wi t h t he 1234: : 2/
64 MAC addr ess t hat bel ongs
t o i nt er f ace A)
Dat a packet s dest i ned f or Dat a packet s dest i ned f or
1234: : 2/ 64 1234: : 2/ 64
Needs t o send PC1 dat a packet s
NS ( r eqest s f or t he 1234: : 1/
64 MAC addr ess)
NA ( r epl i es wi t h t he 1234: : 1/
64 MAC addr ess t hat bel ongs
t o i nt er f ace B)
Dat a packet s dest i ned f or Dat a packet s dest i ned f oR
1234: : 1/ 64 1234: : 1/ 64
DIP
To improve system reliability, an RRS checks the health of an MQE address periodically to
determine whether to schedule FCC or RET requests to the MQE address. The Dynamic
Inspect Protocol (DIP) is a private protocol of Huawei for the health check between an RRS
and an MQE address.
The working principle of DIP is simple. The process is that an RRS periodically sends a
request for querying the health status of a registered MQE address. If MQE works normally,
the IPTV service interface can receive the requests and reply to the RRS. If MQE works
abnormally, the IPTV service interface cannot receive the requests. After the health check
times out, the RRS considers the MQE address as unhealthy.
5.6 Applications
Typical IPv6oE Applications
Currently, IPv6oE supports Layer 2 individual users and Layer 3 individual users. Layer 2
individual users are connected to the BRAS through Layer 2 LAN switches, ADSL devices
such DSLAMs, and WLAN devices such as APs. Layer 3 individual users are connected to
the BRAS through Layer 3 devices such as routers.

Figure 5-2 Networking diagram of IPv6oE user access
IPv6 IPv4
Ba c kb o ne
La ye r 2
IPv4/IPv6 Ne tw o rk
Ne tw o rk
IPv4/v6
Radius
IPv4/IPv6
La ye r 3 IPv4
BRAS Web Server
Ne tw o rk
IPv6
IPv6
Ba c kb o ne
Ne tw o rk
Access of a Layer 2 IPv6 User Running ND

To access the BRAS through a Layer 2 network, an IPv6 user sends an RS message. After
receiving the RS message from the user, the BRAS authenticates the user. If the user passes
the authentication, the BRAS assigns an IPv6 prefix to the user through an RA message. After
receiving the RA message, the user generates a global unicast address by using the IPv6 prefix
and the interface ID of the user, and then accesses the corresponding network by using the
address.
Figure 5-3 Networking diagram for access of a Layer 2 IPv6 user running ND
Interface
M=0
BRAS
IPv6 PC DSLAM Radius
IPv6
The PC and the BRAS need to support basic IPv6 functions. If the M on the access interface
of the BRAS is set to 0, it indicates that the BRAS assigns an address to the user connected to
the BRAS through the interface in stateless address configuration mode. In this case, binding
authentication needs to be configured on the interface because IPv6 users support only
binding authentication, and the IPv6 prefix pool and the IPv6 address pool need to be
configured on the BRAS. In addition, other user access configurations need to be performed
on the BRAS.
Access of a Layer 2 IPv4/IPv6 Dual-Stack User Running DHCPv4 and ND

To access the BRAS through a Layer 2 network, an IPv4/IPv6 dual-stack user sends an RS
message or a DHCPv4 Discovery message. After receiving the message, the BRAS
authenticates the user. If the message sent by the user is an RA message and the user passes

the authentication, the BRAS sends an RA message containing an IPv6 prefix to the user. If
the message sent by the user is a DHCPv4 Discovery message and the user passes the
authentication, the BRAS assigns an IPv4 address to the user. The user can then access the
corresponding network by using the obtained address.
After receiving an RS message or a DHCPv4 Discovery message from a user that has been
authenticated, the BRAS assigns an address of another type to the user without authenticating
the user. After obtaining the address, the user can access the corresponding network by using
the address.
Figure 5-4 Networking diagram for access of an IPv4/IPv6 dual-stack user running DHCPv4 and
ND
Interface
M=0 Radius
IPv6/IPv4 PC DSLAM BRAS

IPv6/IPv4
IPv4 Web
Sever
The PC and the BRAS need to support the IPv4/IPv6 dual stack. Compared with the access of
an IPv6 user running ND, the related IPv4 configuration needs to be performed for the access
of an IPv4/IPv6 dual-stack user.
An IPv4/IPv6 dual-stack user supports Web authentication. After the user obtains an IPv4
address and an IPv6 address, the BRAS allows the user to access the Web server only. After
the user accesses the Web server with the IPv4 address and passes the Web authentication, the
BRAS allows the user to use the IPv4 address and the IPv6 address. Then, the user can access
the corresponding IPv4 and IPv6 networks.
Access of a Layer 2 IPv6 User Running DHCPv6

To access the BRAS through a Layer 2 network, an IPv6 user sends an RS message to the
BRAS. The BRAS replies with an RA message with the M/O field being set to 1. After
receiving the RA message from the BRAS, the user sends a DHCPv6 Solicitation message to
the BRAS. After receiving the DHCPv6 Solicitation message from the user, the BRAS
authenticates the user. If the user passes the authentication, the BRAS assigns an IPv6 address
to the user. Then, the user can access the corresponding network by using the IPv6 address.

Figure 5-5 Networking diagram for access of a Layer 2 IPv6 user running DHCPv6
Interface
M=1
BRAS
IPv6 PC DSLAM Radius
IPv6
In the access of a Layer 2 IPv6 user running DHCPv6, the PC and the BRAS need to support
DHCPv6. If the M on the access interface of the BRAS is set to 1, it indicates that the BRAS
assigns an address to the user connected to the BRAS through the interface in stateful address
configuration mode. In this case, binding authentication needs to be configured on the
interface because IPv6 users support only binding authentication, and the DHCPv6 DUID,
IPv6 prefix pool, and IPv6 address pool need to be configured on the BRAS. In addition,
other user access configurations need to be performed on the BRAS.
Access of a Layer 2 IPv4/IPv6 Dual-Stack User Running DHCPv4 and DHCPv6

To access the BRAS through a Layer 2 network, an IPv4/IPv6 dual-stack user running
DHCPv4 and DHCPv6 sends an RS message to the BRAS. The BRAS replies with an RA
message with the M being set to 1. The user then sends a DHCPv6 Solicitation message or a
DHCPv4 message to go online. After receiving the DHCPv6 Solicitation message or DHCPv4
message, the BRAS authenticates the user. If the user passes the authentication, the BRAS
assigns an address of the corresponding type to the user. Then, the user sends a related
message to obtain an address of the other type.
Figure 5-6 Networking diagram for access of an IPv4/IPv6 dual-stack User running DHCPv4 and
DHCPv6
Interface
M=1 Radius
IPv6/IPv4 PC DSLAM BRAS

IPv6/IPv4
IPv4 Web
Sever
The PC and the BRAS need to support the IPv4/IPv6 dual stack and DHCPv6. Compared
with the access of an IPv6 user running DHCPv6, the related IPv4 configuration needs to be
performed for the access of the IPv4/IPv6 dual-stack user running DHCPv4 and DHCPv6.
Like the access of an IPv4/IPv6 dual-stack user running DHCPv4 and ND, the IPv4/IPv6
dual-stack user running DHCPv4 and DHCPv6 needs to support Web authentication.

Access of a Layer 3 IPv6 User Running DHCPv6

To access the BRAS through a Layer 3 network, an IPv6 user sends an RS message to the
router. The router replies with an RA message with the M/O field being set to 1. After
receiving the RA message with M field being set to 1 from the BRAS, the user sends a
DHCPv6 Solicitation message to the router. The router relays DHCPv6 packets between the
user and the BRAS. After receiving the DHCPv6 Solicitation message from the user, the
BRAS authenticates the user. If the user passes the authentication, the BRAS assigns an IPv6
address to the user. Then, the user can access the corresponding network by using the IPv6
address.
Figure 5-7 Networking diagram for access of a Layer 3 IPv6 User Running DHCPv6
Interface
M=1
IPv6 PC CX600 BRAS Radius

IPv6
The PC, CX device, and BRAS need to support basic IPv6 functions and DHCPv6. The
DHCPv6 relay function needs to be configured on the CX device, the DHCPv6 DUID, IPv6
prefix pool, and IPv6 address pool need to be configured on the BRAS. In addition, other user
access configurations need to be performed on the BRAS.
Access of Layer 2 IPv6 Users Through a Routed Home Gateway (HG)

As shown in the following figure, home IPv6 PCs are connected to an HG, and the HG is
connected to a BRAS over a Layer 2 network. The HG obtains an IPv6 prefix from the BRAS
through DHCPv6, and then allocates IPv6 addresses with the same prefix to the IPv6 PCs.
After obtaining IPv6 addresses, the PCs can access the network.
Figure 5-8 Networking diagram for access of Layer 2 IPv6 users through a routed HG
ND(DHCPv6) DHCPv6-PD
IPv6 PC
HG DSLAM BRAS
Radius
IPv6
IPv6 PC
In the preceding scenario, both the HG and the BRAS must support DHCPv6-Prefix
Delegation (DHCPv6-PD) for IPv6 prefix allocation. The HG can allocate IPv6 addresses to
the IPv6 PCs through ND or DHCPv6. The BRAS interfaces that allow access to users must

be configured with binding authentication. The BRAS must be configured with the DHCPv6
DUID, IPv6 prefix pool, address pool, and other access configurations.
Access of Layer 2 IPv4/IPv6 Dual-Stack Users Through a Routed HG

IPv4/IPv6 dual-stack users can be connected to a BRAS through a routed HG. As shown in the
following figure, the HG obtains a public IPv4 address from the BRAS through DHCPv4,
allocates private IPv4 addresses to IPv4/IPv6 PCs, and forwards IPv4 packets of the PCs
through NAT; the HG obtains an IPv6 prefix from the BRAS through DHCPv6, allocates IPv6
addresses to IPv4/IPv6 PCs according to the prefix through ND or DHCPv6, and forwards
IPv6 packets of the PCs.
Figure 5-9 Networking diagram for access of Layer 2 IPv4/IPv6 dual-stack users through a routed
HG
DHCPv4/
DHCPv4/DHCPv6-PD
ND(DHCPv6)
IPv4/IPv6 Radius
PC
HG DSLAM BRAS
IPv6
IPv4/IPv6
PC IPv4 Web Server
In the preceding scenario, both the HG and the BRAS must support IPv4/IPv6 dual stack and
DHCPv6-PD. In addition to the configurations for access of Layer 2 IPv6 users through a
routed HG, the related IPv4 configurations are required. Like IPv6 users, IPv4/IPv6 dual-stack
users support Web authentication.
ND Proxy
As shown in the following figure, PC1 and PC2 belong to different VLANs and are both
IPv6oE users attached to the BRAS. To allow PC1 to communicate with PC2, you need to
enable ND proxy on the BRAS interfaces that connect to PC1 and PC2.

Figure 5-10 Schematic diagram of communication between users with the same prefix through
the BRAS
1234::1/64
ND Pr oxy
IPv6 PC1 Enabl ed
VLAN1
VLAN2
DSLAM
BRAS
IPv6
IPv6 PC2
1234::2/64
If PC1 and PC2 are connected to different interfaces of the BRAS, both interfaces must be
enabled with ND proxy; otherwise, the PCs cannot communicate with each other.
5.7 Impact
5.7.3 Defects

None.

None.
5.7.3 Defects
None.

Terms
Term Description
IPv6 Internet Protocol Version 6, which is also called IP Next Generation

Term Description
ND Neighbor discovery, which is used during the forwarding of IPv6 packets
for duplicate address detection, neighbor address resolution, and neighbor
reachability detection. Additionally, ND is a set of protocols and processes
for host address configuration. In ND, different ICMPv6 messages are used
for router discovery and neighbor discovery.
Abbreviations
ND Neighbor Discovery
DAD Duplicate Address Detection
NS Neighbor Solicitation
NA Neighbor Advertisement
RS Router Solicitation
RA Router Advertisement
DHCPv6 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
DUID A DHCP Unique Identifier for a DHCP participant

Feature Description - User Access 6 PPPoE Access
6 PPPoE Access
About This Chapter

6.1 Introduction
6.2 References
6.3 Availability
6.4 Principles
6.5 Applications
6.6 Impact
6.1 Introduction
Definition
PPP
The Point-to-Point Protocol (PPP) is a data link protocol that transmits network-layer
datagrams over point-to-point (P2P) links.
PPP functions at the data link layer of both the Open Systems Interconnection (OSI) reference
model and the TCP/IP protocol stack. PPP is designed for synchronous and asynchronous
full-duplex links to transmit data from point to point.

6 PPPoE Access Feature Description - User Access
Figure 6-1 PPP in the protocol stack
SNMP TELNET FTP RADIUS
SOCKET
TCP UDP
ICMP
IP
ARP
PPP
Physical Layer
PPP defines a set of protocols, including:

LCP
The Link Control Protocol (LCP) is used to create, tear down, and monitor data links.
NCP
The Network Control Protocol (NCP) is used to negotiate the format and type of packets
transmitted over a data link.
PAP and CHAP
The Password Authentication Protocol (PAP) and Challenge Handshake Authentication
Protocol (CHAP) are used for network security.
PPPoE
Point-to-Point Protocol over Ethernet (PPPoE) is a data link layer protocol. PPPoE, as a
supplement to PPP for more applications, provides P2P connections, sets up PPP sessions, and
encapsulates PPP packets over the Ethernet. To provide a P2P connection over the Ethernet,
each PPP session must learn the Ethernet address of the remote peer and establish a unique
session identifier. PPPoE that includes a discovery protocol addresses this problem.
Purpose
PPPoE access has the following advantages:
Transmission of multi-protocol datagrams
PPP datagrams are transmitted over the Ethernet. PPP provides a standard method for
transmitting not only IP information but also information about multiple protocols, even
including link layer protocols such as Ethernet.
Flexibility of network accounting
PPPoE access provides statistics about the number of incoming and outgoing packets,
the number of bytes of packets, and the start time and end time of connections. Network
accounting can be flexibly performed based on these statistics.
IPv4/IPv6 dual stack
PPPoE access supports the IPv4/IPv6 dual stack. IPv4 and IPv6 addresses can be
allocated simultaneously.

Benefits
PPPoE access brings the following benefits to operators:
Provides the access of multiple remote hosts to the network through the Ethernet.
Provides access control and accounting.
6.2 References
RFC 1661 The Point-to-Point Protocol (PPP)
RFC 1877 PPP Internet Protocol Control Protocol Extensions for Name
Server Addresses
RFC 1990 The PPP Multilink Protocol (MP)
RFC 2472 IP Version 6 over PPP
RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE)
RFC 5072 IP Version 6 over PPP
6.3 Availability
Terminals for PPPv6 user access, such as Windows Vista and Windows 7, need to support the
IPv6 protocol stack. Windows XP does not support PPPv6.
Devices on the bearer network must support IPv6 forwarding.
License Support
PPPoE services are available only after the corresponding license is obtained. .
Version Support
Product Version
CX600 V600R002
Feature Dependency
None.

Hardware Support
On the CX device, the LPUF-21, LPUF-40, BSUF-10, LPUF-10, and LPUF-10 support
PPPoX access services. When accessing PPPoXoA services, they do not provide network-side
functions.
Other Features
None.
6.4 Principles
6.4.1 Process of a PPPoE User Going Online
6.4.2 PPP State Machine
6.4.3 PPP Packet Format
6.4.1 Process of a PPPoE User Going Online

A PPPoE user goes online after PPPoE negotiation, LCP negotiation, PAP/CHAP
authentication, and NCP negotiation.
PPPoE Negotiation
In PPPoE negotiation, the CX device assigns a unique session ID for a user that accesses the
network through PPPoE. The session ID uniquely identifies a PPPoE link between the user
and CX device over the Ethernet. The PPPoE negotiation process is as follows:
Figure 6-2 PPPoE negotiation process
User CX
1.PADI
2.PADO
PPPoE
3.PADR
negotiation
4.PADS
1. A host broadcasts a PPPoE Active Discovery Initiation (PADI) packet that contains
information about the desired service.
2. Upon receiving the PADI packet, all access concentrators on the Ethernet compare
services that they can provide with the service that the host requires. If an access
concentrator provides the required service, it replies with a PPPoE Active Discovery
Offer (PADO) packet.

3. The host may receive more than one PADO packets. In this case, the host checks the
received PADO packets and chooses one access concentrator that has sent a PADO
packet. The host then sends a PPPoE Active Discovery Request (PADR) packet
containing the required service to the access concentrator.
4. When the access concentrator receives the PADR packet, it begins to prepare for a PPP
session. It generates a unique session ID for the PPPoE session and replies to the host
with a PPPoE Active Discovery Session-confirmation (PADS) packet containing the
session ID. If no fault occurs and the host receives the PADS packet, both the access
concentrator and the host enter the PPP session phase.
LCP Negotiation
In LCP negotiation, the two ends exchange LCP Configure-Request packets and confirm the
configuration options in the Configure-Request packets for negotiation. Then, the two ends
make proper responses after confirming whether they recognize or accept the configuration
options. If both ends reply with a Configure-Ack packet, it indicates that LCP negotiation
succeeds and an LCP connection is set up. Otherwise, the two ends keep on sending
Configure-Request packets until receiving a Configure-Ack packet from each other.
Configure-Ack: If every configuration option in a received Configure-Request packet is

recognizable and every value is acceptable, the receiver replies with a Configure-Ack packet that
contains all configuration options in the Configure-Request packet.
Configure-Nak: If every configuration option is recognizable, but certain values are unacceptable,
the receiver replies with a Configure-Nak packet that contains expected values. For example, if the
peer MRU is 1500 but the expected MRU is 1492, the local end fills in the expected MRU 1492 in
the Configure-Nak packet.
Configure-Reject: If certain configuration options in a received Configure-Request packet are
unsupported, the receiver replies with a Configure-Reject packet that contains unsupported
configuration options. For example, if a Windows dialer negotiates for CBCP but the CX600 does
not support CBCP, the CX600 rejects the configuration option of CBCP.
Figure 6-3 LCP negotiation process
Client Server
Config-req
Config-ack
LCP
negotiation Config-req
Config-ack
1. When LCP Configure-Request and LCP Configure-Ack packets are both sent and
received between a host and the CX device, it indicates that LCP negotiation succeeds.
Then, the CX device periodically sends an Echo-Request packet to the host to check
whether the host is still connected.
2. LCP detects the link status by sending Echo-Request and receiving Echo-Reply packets
between the two ends of LCP negotiation. This helps maintain the LCP connection.

Some devices or terminals cannot actively send Echo-Request packets and can only respond with
Echo-Reply packets. Echo packets are detection packets of PPPoE users.
LCP defines that Echo detection is performed three times in each period of 20 seconds by default.
One period after a user logs in, the BRAS starts detecting the link status by sending Echo-Request
packets. If the BRAS does not receive any Echo-Reply packet after three detection attempts, that is,
80 seconds (20 x (3 + 1)) after the user logs in, the user is forcibly logged out.
Authentication Phase
PAP authentication
PAP is an authentication protocol of two-way handshake by transmitting both user names
and passwords on a network. In PAP authentication, if the two ends of a link can both
transmit data, the authenticatee sends its user name and password to the authenticator.
The authenticator searches the user list locally or on the RADIUS server for the user
name and checks whether the password is correct. If the password is correct, the
authenticator replies with an Authenticate-Ack packet indicating that the authenticatee
passes authentication. If the password is incorrect, the authenticator replies with an
Authenticate-Nak packet indicating that authentication fails. However, the link is not
directly disconnected; instead, it is disconnected only when authentication fails several
times consecutively (10 times by default). In PAP authentication, the user name and
password are transmitted in plaintext on the network. Network security will be greatly
threatened if the user name and password are intercepted during transmission. Therefore,
PAP authentication is applicable to the scenario where network security is not strictly
required.
After the host sends an Authenticate-Request packet to the authenticator and receives an
Authenticate-Ack packet from the CX device, PAP authentication succeeds. Otherwise,
the CX device replies with an Authenticate-Nak packet to notify the host of the
authentication failure.
Figure 6-4 PAP authentication process
Client Server Radius
Auth-req
Auth-req
PPP
authentication Auth-ack
Auth-ack
CHAP authentication
CHAP is an authentication protocol of three-way handshake by transmitting only user
names on a network. Compared with PAP, CHAP is of a higher security level because
passwords are not transmitted. In CHAP authentication, the authenticator periodically
sends a randomly generated packet and the host name of the authenticator to the
authenticatee. The authenticated searches for the user password in the local user list
according to the host name of the authenticator in the packet. If the host name can be
found in the list, the authenticatee generates a Response packet by using the packet ID
and the key (password) of the authenticator through the MD5 algorithm, and then sends
the Response packet and the host name to the authenticator. After receiving the Response

packet, the authenticator obtains the result by using the packet ID, password (key) on the
authenticator, and a randomly generated packet through the MD5 algorithm. The
authenticator then compares the obtained result with the Response packet from the
authenticatee and then replies with an Authenticate-Ack or Authenticate-Nak packet. The
CHAP authentication process is as follows:
− The authenticator sends a Challenge packet.
− The authenticatee sends an Authenticate-Request packet.
− The authenticator replies with an Authenticate-Ack packet.
After the preceding procedures, CHAP authentication is complete.
Figure 6-5 CHAP authentication process
Client Server Radius
Challenge(CHAP)
Auth-req
PPP Auth-req
authentication Auth-ack
Auth-ack
NCP Phases
NCP includes IPCP, BCP, and IPv6 Control Protocol (IPv6CP). NCP negotiates network-layer
parameters of PPP packets. The parameters include the IP address, IP address of the DNS
server, and IP address of the Windows server. A PPPoE user obtains an IP address or an IP
address segment for network access mainly through IPCP.
The NCP negotiation process is similar to the LCP negotiation process. When both NCP
Configure-Request and NCP Configure-Ack packets are transmitted between a host and the
CX device, it indicates that NCP negotiation succeeds. Then, the host can access the network.
IPv6CP
As defined in RFC 2472, IPv6CP is a network control protocol used for establishing and
configuring IPv6 over PPP. IPv6CP is responsible for configuring, enabling, and
disabling IPv6 protocol modules on both ends of a P2P link. IPv6CP uses the same
packet exchange mechanism as LCP. IPv6CP packets are not exchanged until PPP has
entered the Network-Layer Protocol phase. IPv6CP packets received before this phase
are discarded.
In PPPv6 access defined in RFC 5072, interface IDs of both ends of the link must be
negotiated in the IPv6CP negotiation phase. Interface IDs obtained in this phase,
however, can be used as LinkLocal addresses only and are not associated with global
unicast addresses. Specific global IPv6 unicast addresses are notified through RA
packets.
At present, only interface IDs can be negotiated in the IPv6CP negotiation phase. The
NCP negotiation process is as follows:

Figure 6-6 NCP negotiation process
Client Server
Parmeter-req
Parmeter-ack
NCP
negotiation Parmeter-req
Parmeter-ack
PPPoE Access Process

The following part takes PPPoE CHAP as an example to illustrate the access process of a PPP
user.
Figure 6-7 Access process of a PPP user
User CX AAA Server
1.PADI
2.PADO
PPPoE
negotiation 3.PADR
4.PADS
PPP 5.LCP negotiation£¨CHAP

negotiation authentication£©
6.Challenge
7.Response
8.Access Request
9.Access Accept/Reject
10.Success/Failure
11 NCP negotiation
User logs
in

6.4.2 PPP State Machine

LCPs and NCPs run in compliance with the PPP state machine, whereas PAP and CHAP do
not.
All PPP negotiation processes are implemented through the PPP state machine. As the core of
PPP, the PPP state machine provides the following status:
Initial: In the Initial state, the lower layer is unavailable and no Open event has occurred.
The Restart timer does not run in the Initial state.
Starting: In the Starting state, an Open event has occurred, but the lower layer is still
unavailable (Down) and the Restart timer does not run. When the lower layer becomes
available (Up), a Configure-Request packet is sent and the system enters the
Request-Sent state.
Closed: In the Closed state, the link is available (Up), but no Open event has occurred.
The Restart timer does not run in the Closed state.
Stopped: After a link is disconnected, the link configuration fails, or a state machine fault
occurs, a Terminate -Ack or This-layer-Finished event occurs, the system enters the
Stopped state. The Restart timer does not run in the Stopped state. The automation
machine enters the Starting state after receiving a Down event. A new configuration
negotiation starts upon reception of Configure-Request packets.
Closing: In the Closing state, an attempt is made to terminate the connection. A
Terminate-Request packet has been sent and the Restart timer runs, but no
Terminate-Ack packet has been received. Upon reception of a Terminate-Ack packet, the
system enters the Closed state. Upon the expiration of the Restart timer, a new
Terminate-Request packet is sent, and the Restart timer is restarted. After the Restart
timer has expired Max-Terminate times, the system enters the Closed state.
Stopping: In the Stopping state, a Terminate-Request packet has been sent and the
Restart timer runs, but no Terminate-Ack packet has been received. After the link has
been terminated, a protocol can be re-configured in the Stopped or Starting state. The
difference between the Stopping state and the Closing state is that an Open event has
occurred in the Stopping state whereas no Open event occurs in the Closing state.
Request-Sent: In the Request-Sent state, an attempt is made to negotiate connection
parameters. A Configure-Request packet has been sent and the Restart timer runs, but no
Configure-Ack packet has been received.
Ack-Rcvd: In the Ack-Rcvd state, a Configure-Request packet has been sent and a
Configure-Ack packet has been received. The Restart timer still runs because no
Configure-Ack packet has been sent.
Ack-Sent: In the Ack-Sent state, a Configure-Ack packet is sent.
Opened: In the Opened state, negotiation succeeds and the Restart timer is not closed.
When the system enters the Opened state, the lower layer notifies the upper layer that the
lower layer goes Up. When the system quits the Opened state, the lower layer notifies
the upper layer that the lower layer goes Down.
State transitions in the state machine are caused by the following events:
Up: This event occurs when the lower layer gets ready for transmitting packets. The low
layer notifies the upper layer of the Up event indicating that the upper layer can use the
lower layer protocol.
Down: This event occurs when the lower layer will no longer transmit packets. The
lower layer notifies the upper layer of the Down event indicating that the upper layer can
no longer use the lower layer protocol. Then, resources can be released.

Open: This event indicates that a link is available. When this event occurs and the link is
not in the Opened state, the automaton attempts to send packets to the peer for
negotiation.
Close: This event indicates that a link is unavailable. When this event occurs and the link
is not in the Closed state, the automaton attempts to terminate the connection. Further
attempts for connecting the link will be denied until a new Open event occurs.
Timeout(T0+,T0-): This event indicates the expiration of the Restart timer. The Restart
timer is used for responses to Configure-Request and Terminate-Request packets. The
TO+ event indicates that the value of the Restart timer is greater than 0, which triggers
retransmission of the corresponding Configure-Request or Terminate-Request packet.
The TO- event indicates that the value of the Restart timer is smaller than 0, and no more
packets need to be retransmitted.
Receive-Configure-Request(RCR+,RCR-): This event occurs when a Configure-Request
packet is received from the peer. The RCR+ event indicates that the Configure-Request
is acceptable, which triggers transmission of a corresponding Configure-Ack packet. The
RCR- event indicates that the Configure-Request is unacceptable, which triggers
transmission of a corresponding Configure-Nak or Configure-Reject packet.
Receive-Configure-Ack(RCA): This event occurs when a valid Configure-Ack packet is
received from the peer.
Receive-Configure-Nak/Reject(RCN): This event occurs when a valid Configure-Nak or
Configure-Reject packet is received from the peer. A Configure-Nak packet contains
valid but rejected options, excluding acceptable options. A Configure-Reject packet
contains unacceptable options.
Receive-Terminate-Request(RTR): This event occurs when a Terminate-Request packet
is received. The Terminate-Request packet indicates that the peer intends to close the
connection.
Receive-Terminate-Ack(RTA): This event occurs when a Terminate-Ack packet is
received. The Terminate-Ack packet is usually in response to a Terminate-Request
packet. The Terminate-Ack packet may also indicate that the peer is in the Closed or
Stopped state.
Receive-Unknown-Code(RUC): This event occurs when an un-interpretable packet is
received. A Code-Reject packet is sent in response.
Receive-Code-Reject, Receive-Protocol-Reject(RXJ+,RXJ-): This event occurs when a
Code-Reject or a Protocol-Reject packet is received. The RXJ+ event occurs when the
rejected value is acceptable; the RXJ- event occurs when the rejected value is
unacceptable, which terminates the connection.
Receive-Echo-Request,Receive-Echo-Reply,Receive-Discard-Request(RXR): This event
occurs when an Echo-Request packet, an Echo-Reply packet, or a Discard-Request
packet is received. An Echo-Reply packet is sent in response to an Echo-Request packet
and no packet is sent in response to an Echo-Reply packet or a Discard-Request packet.

State Transition
Figure 6-8 State transition
Up Opened
Dead Establish Authenticate
Fail Fail
Terminate Network
Down Closing
Success/None
Link Dead phase: The link necessarily begins and ends with this phase. When an external
event (such as carrier detection or network administrator configuration) detects that the
physical layer gets ready, PPP will enter the Establishment phase. In this phase, the LCP state
machine will be in the Initial or Starting state. An Up event will be sent to the LCP state
machine when a link transits from either the Initial state or the Starting state to the
Establishment state. The link returns to this phase automatically after being disconnected.
Generally, this phase is very short, merely long enough to detect that the device is in service.
Link Establishment phase: LCP is used to establish a connection by exchanging Configure
packets. Once a Configure-Ack packet is sent and then received by the peer, LCP enters the
Opened state. Only Configuration options which are independent of particular network-layer
protocols are configured by LCP. Configuration of individual network-layer protocols is
handled by separate Network Control Protocols (NCPs) during the Network-Layer Protocol
phase. Any non-LCP packet received in this phase is directly discarded. Receipt of the LCP
Configure-Request packet causes a return to the Link Establishment phase from the
Network-Layer Protocol or Authentication phase.
Authentication phase: A certain link may require a peer to authenticate itself before allowing
network-layer protocol packets to be exchanged. By default, authentication is not mandatory.
If an application requires that the peer authenticate by using a certain authentication protocol,
a request for the use of the authentication protocol must be sent in the Link Establishment
phase. Authentication should take place immediately after link establishment. However, link
quality determination may occur concurrently. An application must ensure that no delay
during the exchange of link quality determination packets. The Authentication phase cannot
transit to the Network-Layer Protocol phase until authentication is complete. If authentication
fails, the authenticator should perform authentication again instead of entering the Link
Termination phase. Only LCP, authentication protocol, and link quality monitoring packets
can be transmitted in this phase. Other packets received in this phase are discarded
Network-Layer Protocol phase: Once PPP goes through the previous phases, each
network-layer protocol (such as IP or IPX) must be separately configured by an appropriate
NCP. An NCP may be Opened or Closed at any time. After an NCP reaches the Opened state,
PPP transmits corresponding network-layer protocol packets. Any network-layer protocol
packet received when the corresponding NCP is not in the Opened state must be discarded. In

this phase, link traffic consists of any possible combination of LCP, NCP, and network-layer
protocol packets.
Link Termination phase: PPP can terminate a link at any time because of carrier loss,
authentication failures, poor link qualities, timer expiration, or administrative closing of the
link. PPP closes the link by exchanging Terminate packets. After the exchange of Terminate
packets, the application instructs the physical layer to interrupt the connection in order to
disconnect the link. In the case of an authentication failure, the sender of the
Terminate-Request packet must disconnect the connection after receiving a Terminate-Ack
packet or after the Restart timer expires. The receiver of a Terminate-Request packet must
wait for the peer to disconnect the connection or disconnect the connection after sending a
Terminate-Ack packet and waits for expiration of at least one Restart timer. Then, PPP
proceeds to the Link Dead phase.
6.4.3 PPP Packet Format

The following figure shows the PPP packet format.
Figure 6-9 Format of a PPP packet
Format of
Fl ag Addr ess Cont r ol Pr ot ocol FCS Fl ag
a PPP I nf or mat i on
01111110 11111111 00000011 8/ 16bi t s 16bi t s 01111110
packet
Format of an LCP Code I dent i f i er Lengt h Dat a

packet 8bi t s 8bi t s 16bi t s ......
Format of LCP
Type Lengt h Dat a Type Lengt h Dat a ...
configuration
8bi t s 8bi t s ...... 8bi t s 8bi t s ...... ......
parameters
Format of a PPP Packet

A PPP packet contains the Address, Control, Protocol, and Information fields. The meanings
of the fields are as follows:
Flag
The Flag field identifies the beginning and ending of a frame. The value of the field is
0x7E.
Address
The Address field can uniquely identify the peer because PPP is applied to P2P links.
Two communicating devices do not need to know data link layer addresses of each other.
The Address field, as defined in the PPP protocol, is padded with "11111111" that
indicates a broadcast address.
Control
Similar to the Address field, the Control field does not have actual meanings and is
constantly filled with 0x03.
The Address field and the Control field together specify a PPP packet. That is, a PPP
packet header is FF03.

Protocol
The Protocol field differentiates the contents in the Information field.
As described by the address extension mechanism provided in ISO 3390, the value of the
Protocol field must be an odd number. That is, the lowest bit of the low byte is "1",
whereas the lowest bit of the high byte is "0".
If the Protocol field of a PPP frame does not comply with the preceding definitions, the
receiver regards the frame as unknown. The receiver sends a Protocol-Reject packet that
contains the protocol number of the rejected packet to the sender.
Table 6-1 Common protocol codes
Protocol Code Protocol Type

21 Internet Protocol
002b Novell IPX
002d Van Jacobson Compressed TCP/IP
002f Van Jacobson Uncompressed TCP/IP
57 IPv6
8021 Internet Protocol Control Protocol
802b Novell IPX Control Protocol
8031 Bridging NC
8057 IPv6CP
C021 Link Control Protocol
C023 Password Authentication Protocol
C223 Challenge Handshake Authentication
Protocol
Information
The maximum length of the Information field plus the padding cannot be greater than
1500 bytes. The maximum length of the Information field is the same as the default
Maximum Receive Unit (MRU). In practice, the maximum length of the Information
field can be negotiated.
If the length of the Information field is less than 1500 bytes, the field can be, but not
necessarily, padded. If the Information field is padded, devices can communicate only if
they can distinguish between necessary and unnecessary information.
FCS
Frame Check Sequence (FCS) mainly checks the correctness of transmitted PPP frames.
Transmission guarantee mechanisms such as FCS bring more costs and delays in
interaction at the application layer.

Format of an LCP Packet

The format of a PPP packet, such as an IPCP packet, a PAP packet, or a CHAP packet, is
similar to the format of an LCP packet. The following part takes the format of an LCP packet
as an example.
During the Establish phase, PPP sets up a PPP link by exchanging LCP packets. An LCP
packet is encapsulated as payload in the Information field of a PPP frame. The Protocol field
of the PPP frame is fixed to 0xC021.
During the Establish phase, the contents of the Information field change. Therefore, this field
may belong to different types of packets. The following fields that comprise the Information
field can identify the type of a packet.
Code
The Code field identifies the type of an LCP packet. The length of the code field is 1
byte.
During the Establish phase, a receiver receives an LCP packet. If the Code field of the
LCP packet is regarded as unknown, the receiver sends a Code-Reject packet to the
sender.
An IP packet does not have this field.
Table 6-2 Common code values
Code Value Message Type

0x01 Configure-Request
0x02 Configure-Ack
0x03 Configure-Nak
0x04 Configure-Reject
0x05 Terminate-Request
0x06 Terminate-Ack
0x07 Code-Reject
0x08 Protocol-Reject
0x09 Echo-Request
0x0A Echo-Reply
0x0B Discard-Request
0x0C Reserved
Identifier
The Identifier field indicates the matching between negotiation packets.
The Identifier field, being 1 byte, identifies a pair of request and response packets. A
request packet and its response packet have the same vale of the Identifier field.

Generally, before entering the phase for establishing links, the communicating devices
continuously send several Configure-Request packets to their peers. Those packets have
different Identifier fields; however, their Data fields may be identical.
Generally, the Identifier field of a Configure-Request packet is increased by 1 from
0x01.
Regardless of the type of the response packet, the ID of the response packet and that of
the Configure-Request packet must be the same.
When the communicating device receives the response packet, it compares the response
packet with the packet it sends and then performs the following operations.
Length
The Length field indicates the length of a negotiation packet, including the lengths of the
Code and Identifier fields.
The value of the Length field is the total length of an LCP packet that includes the
lengths of the Code, Identifier, Length, and Data fields.
The bytes that exceed the length are regarded as the padding and are ignored. The value
of the Length field cannot be greater than the MRU.
Data
The Data field contains the contents of a negotiation packet. The main contents of the
Data field are as follows:
− Type: indicates the type of the negotiation packet.
− Length: indicates the length of the negotiated options. That is, this field indicates the
total length of the Type, Length, and Data fields.
− Data: indicates the contents of the Data field.
Type Value Type of Negotiation Packets

0x01 Maximum-Receive-Unit
0x02 Async-Control-Character-Map
0x03 Authentication-Protocol
0x04 Quality-Protocol
0x05 Magic-Number
0x06 RESERVED
0x07 Protocol-Field-Compression
0x08 Address-and-Control-Field-Compression
6.5 Applications
Typical Applications of PPPoX User Access
According to the networking, PPPoX services can be classified into the following services:
Point-to-Point Protocol over Ethernet (PPPoE)

In PPPoE services, the Ethernet interface card of a PC encapsulates PPP packets into
PPPoE packets, and then directly sends PPPoE packets to the CX device without any
encapsulation or change.
The following figure shows the typical networking model of PPPoE services. In this
model, a PC accesses the Ethernet interface on the CX device through a Layer 2 device
(such as a hub or a LAN switch) that does not encapsulate or change PPPoE packets.
Figure 6-10 Typical networking model of PPPoE services
Eth PPPoE IP Data Eth PPPoE PPP IP Data
I nt er net
subscriber Lanswitch CX
Point-to-Point Protocol over Ethernet over VLAN (PPPoEoV)

In PPPoEoV services, the Ethernet interface card of a PC encapsulates PPP packets into
PPPoE packets, and then sends them to a LAN switch. The LAN switch adds a VLAN
tag to each of the PPPoE packets, which are then called PPPoEoV packets, and sends the
PPPoEoV packets to the CX600.
The following figure shows the typical networking model of PPPoEoV services. In this
model, a PC accesses the Ethernet interface on the CX600 through a switch that
complies with IEEE 802.1Q.
Figure 6-11 Typical networking model of PPPoEoV services
Eth PPPoE PPP IP Data Eth Q PPPoE PPP IP Data
Internet
subscriber LAN Switch CX
Point-to-Point Protocol over Ethernet over QinQ (PPPoEoQ)

In PPPoEoQ services, the Ethernet interface card of a PC encapsulates PPP packets into
PPPoE packets, and then sends them to a switch. The switch adds a VLAN tag to each of
the PPPoE packets, which are then called PPPoEoV packets, and then sends the
PPPoEoV packets to another switch that is adjacent to the CX600. The later switch adds
another VLAN tag to each of the PPPoEoV packets, which are then called PPPoEoQ
packets, and then sends the PPPoEoQ packets to the CX600.
The following figure shows the typical networking model of PPPoEoQ services. In this
model, a PC accesses the Ethernet interface on the CX600 through two switches that
comply with IEEE 802.1Q.

Figure 6-12 Typical networking model of PPPoEoQ services
IP Data IP Data IP Data

PPP PPP PPP
PPPoE PPPoE PPPoE
Eth Eth Q Eth Q Q
Internet
subscriber LAN Switch LAN Switch CX
Point-to-Point Protocol over ATM Adaptation Layer 5 (PPPoA)

In PPPoA services, an Asymmetric Digital Subscriber Line (ADSL) modem that supports
ATM Adaptation Layer 5 (AAL5) encapsulation encapsulates PPP packets into PPPoA
packets, and then sends the PPPoA packets to a Digital Subscriber Line Access
Multiplexer (DSLAM). The DSLAM sends the PPPoA packets to the CX600.
The following figure shows the typical networking model of PPPoA services. In this
model, a PC is connected to an ADSL modem over the LAN; the ADSL modem is
connected to the DSLAM over the PSTN/ISDN; the DSLAM is connected to the CX600
over the ATM network. Serving as a PPP client, the ADSL modem automatically dials in
after being powered on to establish a PPP connection with the CX600. This PPP
connection is transparent for the PC, and thus it is unnecessary to install the client dial-in
software on the PC.
Figure 6-13 Typical networking model of PPPoA services
AAL5 PPP IP Data AAL5 PPP IP Data
Internet
PC ADSL Modem DSLAM CX
Point-to-Point Protocol over Ethernet over ATM Adaptation Layer 5 (PPPoEoA)

In PPPoEoA services, the Ethernet interface card of a PC encapsulates PPP packets into
PPPoE packets, and then sends them to an ADSL modem. The ADSL modem that
supports AAL5 encapsulation encapsulates the PPPoE packets into PPPoEoA packets,
and then sends the PPPoEoA packets to the CX600.
The following figure shows the typical networking model of PPPoEoA services. In this
model, a PC is connected to an ADSL modem over the Ethernet; the ADSL modem is
connected to the DSLAM over the PSTN/ISDN; the DSLAM is connected to the CX600
over the ATM network. The PC is installed with the PPPoE client dial-in software and
sets up a PPP connection with the CX600. The ADSL modem provides only the Layer 2
bridging function to transparently transmit data.

Figure 6-14 Typical networking model of PPPoEoA services
Eth PPPoE PPP IP Data AAL5 Eth PPPoEPPP IP Data
Internet
ADSL
PC DSLAM CX
Modem
PPPv6 User Access

With the wide application of IPv6 networks, users need to be capable of accessing IPv6
networks.
Figure 6-15 Typical networking of PPPv6 user access
DNS server RADIUS server

3001:0410::1:2 3001:0410::1:1
access
network Internet
subscriber CX
@isp5
A PPPoE dial-in connection is set up in the same manner as in PPPv4. Note that the user
access domain name following "@" must be the same as that configured on the CX device or
you can configure the access domain on the access interface of the CX device instead of
configuring the user access domain name.
PPPv4/PPPv6 Dual-stack User Access

For users that need to access both IPv4 and IPv6 networks, you need to configure an IPv4
address pool and an IPv6 address pool in the user authentication domain on the CX600. In this
manner, the CX600 can assign IPv4 addresses and IPv6 addresses to users and implement
separate and unified accounting for dual-stack users.
6.6 Impact
6.6.3 Other Defects


None.

None.
6.6.3 Other Defects

None.

Abbreviations
CHAP Challenge-Handshake Authentication
Protocol
LCP Link Control Protocol
PAP Password Authentication Protocol
PPP Point-To-Point Protocol

Feature Description - User Access 7 802.1x Access
7 802.1x Access
About This Chapter

7.1 Introduction to 802.1x Access
7.2 References
7.3 Availability
7.5 Principle
7.6 Applications
7.7 Impact
7.1 Introduction to 802.1x Access

Definition
802.1x access is the broadband access mode in which a user is authenticated and accesses a
BRAS by sending Extensible Authentication Protocol (EAP) packets. A user who adopts this
access mode exchanges information with the authentication server and accesses the Internet
through an 802.1x standard.
Purpose
Generally, 802.1x authentication is applied to the security authentication of 802.11 wireless
users in collaboration with the WLAN feature. Being an authentication protocol, EAP also
supports 802.1x authentication of wired users through dialers.
Benefits
This feature brings the following benefit to operators:
802.1x access is a secure wireless access mode.

7 802.1x Access Feature Description - User Access
7.2 References
Name
RFC 2284 PPP Extensible Authentication Protocol (EAP) -
RFC 3748 Extensible Authentication Protocol (EAP) -
IEEE Std IEEE Standard for Local and Metropolitan Area -
802.1X-2001 Networks--Port-Based Network Access Control
7.3 Availability
License Support
None.
Version Support
Product Version
CX600 V600R002
Feature Dependency
The relationship between 802.1x access and other features is as follows:
EAP-Protected EAP (PEAP) authentication must be used in collaboration with the
WLAN feature.
Hardware Support
Both EAP-PEAP authentication and EAP-SIM authentication need hardware support of
access points (APs).

The CX600 supports EAP-PEAP/SIM encrypted authentication of 802.1x wireless access
users only when the collaboration of the WLAN feature is available. The CX600 supports
only EAP packet-triggered 802.1x authentication. The CX600 allows only the users who pass
802.1x authentication to obtain IP addresses. The CX600 supports IPoE, IPoEoVLAN, and
IPoEoQ.

7.5 Principle
7.5.1 Basic Principle of 802.1x Access
7.5.2 Authentication Initiation and User Logoff
7.5.3 EAP Packet Relaying and Termination
7.5.4 Basic Process of the IEEE 802.1x Authentication System
7.5.5 Basic Process of EAP-PEAP Authentication for Secure and Encrypted WLAN Access
Through WPA
7.5.1 Basic Principle of 802.1x Access

Figure 7-1 Architecture of the 802.1x authentication system
Authenticati
Client Device
on server
Device-provided Authenticat
Client PAE Device PAE
service ion server
Non-
Controled Unauthenticated controlled
interface
interface interface
LAN/WLAN
The three major components of the 802.1x authentication system are the client, device, and
authentication server.
The client is at one end of a point-to-point (P2P) LAN segment and is authenticated by the
device that is connected to the client through a link. Commonly, the client is a user terminal.
The user initiates 802.1x authentication by starting the client software. The client must
support EAP over LAN (EAPoL).
The device is at the other end of the P2P LAN segment and authenticates the client that is
connected to the device through a link. Commonly, the device supports an 802.1x standard.
The device provides the client with a LAN-accessing interface, which can be a physical
interface (for example, an Ethernet interface on an Ethernet switch) or a logical interface (for
example, the user MAC address or the VLAN ID).
The authentication server is an entity that provides authentication services for the device. The
authentication server undertakes authentication, authorization, and accounting for users. You
are recommended to use a RADIUS server as the authentication server.

In the 802.1x authentication system, the authentication server and client exchange
authentication information through EAP. Between the client Port Access Entity (PAE) and the
device PAE, EAPoL encapsulation is adopted for EAP packets.
Between the device PAE and the RADIUS server, EAP packets can adopt EAP over RADIUS
(EAPoR) encapsulation and be borne by RADIUS. EAP packets can be terminated on the
device PAE. In this case, Password Authentication Protocol (PAP) or Challenge Handshake
Authentication Protocol (CHAP) packets are transmitted between the device PAE and the
RADIUS server.
The device PAE is isolated from the authentication function. The RADIUS server can
authenticate the client PAE through any of several authentication mechanisms such as
MD5-challenge, PAP, and EAP-PEAP.
The device PAE determines the status (authorized/unauthorized) of the controlled interface
according to the instructions (accept/reject) from the RADIUS server.
Figure 7-2 Protocol structure of the 802.1x authentication system
RADIUS-bearing
EAP/PAP/CHAP packet
EAPOL Device exchange Authentication
Client PAE server
PAE
In a scenario of WLAN access, user-based interface control is implemented through APs.

Non-EAP packets of a user can reach the BRAS only after the user passes 802.1x
authentication.
7.5.2 Authentication Initiation and User Logoff

Authentication Initiation
The IEEE 802.1x standard defines that authentication can be initiated by either a client PAE
or a device PAE. The BRAS allows a user to initiate authentication. You can enable
re-authentication on the BRAS to configure the BRAS to re-authenticate the client
periodically.
When the client needs to access the service that the device provides, the client initiates
authentication. Before the client initiates authentication, the client PAE must send an
EAPoL-Start packet to the device PAE. After receiving the EAPoL-Start packet, the device
PAE must respond with an EAP-Request/Identity packet.
User Logoff
When any of the following situations exists, the user logs off and the controlled interface
becomes unauthorized:
The client fails authentication.
The administrator forcibly sets the controlled interface to the unauthorized state.
The interface-associated MAC address is unavailable because the hardware fails or the
administrator prohibits the MAC address.
The physical connection between the client and the device fails, causing the
authorization status of the controlled interface to age.

The client fails re-authentication.

The client PAE cannot respond to the authentication request from the device PAE.
The client PAE sends an EAPoL-Logoff packet requesting logoff.
The client PAE can send a request for logoff at any time and in any situation. It is
recommended that the client PAE send a request for logoff when the user quits the client or
the client needs to restart.
7.5.3 EAP Packet Relaying and Termination

802.1x authentication supports relaying and termination of EAP packets.
EAP Packet Relaying

The device PAE is responsible for relaying EAP packets between the client and the RADIUS
server. In addition, the device PAE can re-encapsulate EAPoR packets into EAPoL packets
and send them to the client or re-encapsulate EAPoL packets into EAPoR packets and send
them to the RADIUS server. Information in a packet being relayed is unchangeable.
EAPoL-Start, EAPoL-Logoff, EAPoL-Key, or EAP-Request/Identity packets do not need to
be relayed.
EAP Packet Termination

The device PAE is responsible for terminating EAP packets between the client and the
RADIUS server. In addition, the device PAE can map EAPoL packets into PAP/CHAP
packets and send them to the RADIUS server or map PAP/CHAP packets into EAPoL packets
and send them to the client. Information in a packet being terminated is unchangeable.
7.5.4 Basic Process of the IEEE 802.1x Authentication System

Basic process of the IEEE 802.1x authentication system (1)
This part takes EAP packet relaying on the device PAE as an example. Figure 7-3 shows the
basic process of the IEEE 802.1x authentication system. Being a relay device, the BRAS
converts EAPoL packets from the user into EAPoR packets and sends them to the RADIUS
server. In addition, the BRAS converts EAPoR packets from the RADIUS server into EAPoL
packets and sends them to the user. During authentication, the BRAS transparently transmits
user packets until it receives an Access-Accept packet from the RADIUS server, which
indicates a successful user access.

Figure 7-3 Basic process of the IEEE 802.1x authentication system (1)
EAPoL Device RADIUS

Cl i ent PAE PAE
RADIUSserver
EAPoL-Start
EAP-Request/Identity
RADIUSAccess-Request
EAP-Response/Identity (EAP-Response/MD5 Challenge)
RADIUSAccess-Chanllenge
EAP-Request/MD5Challenge (EAP-Request/MD5 Challenge)
EAP-Response/MD5 Challenge (EAP-Response/MD5 Challenge)
RADIUSAccess-Accept
EAP-Success (EAP-Success)
Interface
authorized
Handshake Handshake
r equest
[ EAP- Request / I dent i t y] timer times out
Handshake
reply
[ EAP- Response/ I dent i t y]
......
EAPoL- Logof f
Interface
unauthorized
Basic process of the IEEE 802.1x authentication system (2)

This part takes EAP packet terminating and mapping into CHAP packets on the device PAE as
an example. Figure 7-4 shows the basic process of the IEEE 802.1x authentication system.
The BRAS terminates EAP packets and converts them into standard RADIUS packets and
sends an authentication request to the RADIUS server. Generally, this process is applicable to
access authentication in the situation where the RADIUS server does not support the EAP
attribute.

Figure 7-4 Basic process of the IEEE 802.1x authentication system (2)
EAPoL RADIUS
Client PAE Device PAE RADIUSserver
EAPoL-Start
EAP-Request/Identity
EAP-Response/Identity
EAP-Request/MD5Challenge
EAP-Response/MD5 Challenge (EAP-Response/MD5 Challenge)
RADIUSAccess-Accept
EAP-Success (EAP-Success)
Interface authorized
Handshake timer
Handshake request
times out
[EAP-Request/Identity]
Handshake reply
[EAP-Response/Identity]
EAPoL-Logoff
Interface unauthorized
7.5.5 Basic Process of EAP-PEAP Authentication for Secure and

Encrypted WLAN Access Through WPA
Figure 7-5 shows the process that a wireless user accesses the BRAS through Wi-Fi Protected
Access (WPA) in a secure and encrypted manner. After being associated with an AP, the user
sends an EAPoL-Start packet to trigger EAP-PEAP authentication. Being a relay device, the
BRAS transparently transmits the authentication request to the RADIUS server. The BRAS
sends an EAP-Success packet to the user after receiving an Access-Accept packet. Meanwhile,
the BRAS sends an EAPoL-Key packet to the user to trigger four-way handshake negotiation
of the key. After the negotiation, the user sends a DHCP packet to obtain an IP address. Then,
the wireless user can access the network in a secure and encrypted manner.

Figure 7-5 Basic process of IEEE 802.1x EAP-PEAP authentication
Terminal AP BRAS AAA Server

1.broadcast probe
Search for 2.reply to probe

AP 3.802.11AUTH
4.association request 5.association message

Association
7. association succeeds 6.association succeeds
8.EAPOL-start
9.EAP-request/Identity
11.Radius-Access-
10.EAP-response/Identity Request
12.Radius-Access-
802.1X EAP 13.EAP-request/Identity Challenge
authenticatio
15.Radius-Access-
n 14.EAP-response/Identity Request
17.BRAS saves PMK and 16.Radius-Access-
sends EAP-success Accept
18.EAPOL-nonce
19.calculate PTK and send to AC
802.11i key
20.Check the PTK and deliver the GTK
generated
21.Key is usable
AP interface usable 22.KEY delivered
23.DHCP Discover,
apply for address
24.DHCP Offer,
User address allocation
address 25.DHCP Request,
application address acknowledged
26.DHCP ACK
27. Terminal
. data
forwarding
Userdata
forwarding
7.6 Applications
Typical Applications of 802.1x Access
The networking mode for 802.1x access is similar to that for IPoE, IPoEoV, and IPoEoQ. An
EAP packet is converted into an EAPoL packet after passing through an Ethernet interface on

a PC. The EAPoL packet can arrive at the BRAS directly or arrive at the BRAS after being
added with a VLAN tag on a LAN switch or being encapsulated through AAL5 on a DSLAM.
By decapsulating the packet and identifying the VLAN tag, the BRAS obtains information
such as the physical information about the user, user name, and password. In this manner, the
BRAS prepares data for user access authentication.
Figure 7-6 is a typical networking diagram for 802.1x access. As shown in this diagram, the
user packet arrives at the BRAS directly.
Figure 7-6 Typical networking diagram for 802.1x access
Internet
subscriber BRAS
Figure 7-7 is a networking diagram for 802.1XoEoV access. As shown in this diagram, the
user packet is sent to the BRAS for authentication after being added with a VLAN tag on the
switch.
Figure 7-7 Networking diagram for 802.1XoEoV access
Internet
subscriber Switch BRAS
Figure 7-8 is a networking diagram for 802.1XoEoQ access. As shown in this diagram, the
user packet is sent to the BRAS for authentication after being added with VLAN tags on two
switches.
Figure 7-8 Networking diagram for 802.1XoEoQ access
Internet
subscriber Switch Switch BRAS
Application of 802.1x Wireless Access

A WLAN supports secure and encrypted access of wireless users. A user can encrypt wireless
links through the TKIP and CCMP algorithms defined in 802.11i to ensure data security.
Figure 7-9 is a typical networking diagram of WLAN 802.1x access. After a user is associated

with an AP, the AP adds a VLAN tag to the user packet. Then, the switch transmits the packet
to the BRAS.
The AP determines the VT aggregation point (VAP) through which the user logs in to the
BRAS. If the authentication mode of users on this VAP is WPA, the AP creates an 802.1x
controlled interface based on the user MAC address. Before the user passes 802.1x
authentication, only an EAP packet is sent to the BRAS. After the user passes 802.1x
authentication, the BRAS instructs the AP to enable the controlled interface and send the
non-EAP packet, including the DHCP packet carrying the IP address to be allocated to the
user.
Figure 7-9 Networking diagram of WLAN access
Internet
subscriber AP Switch BRAS
7.7 Impact
7.7.3 Defects

None.

The total number of access users is composed of the numbers of DHCP, PPP, and 802.1x
access users.
7.7.3 Defects
None.


Term
Term Definition
WLAN A LAN in which data is sent and received through radio, infrared
optical signaling, or other technologies that do not require a
physical connection between individual nodes and the hub.
WLANs are often used in offices or workshops where users use
portable computers.
Abbreviation
EAP Extensible Authentication Protocol
EAPoL EAP over LAN
EAPoR EAP over RADIUS

Feature Description - User Access 8 WLAN
8 WLAN
About This Chapter

8.1 Introduction to WLAN
8.2 References
8.3 Availability
8.4 Principles
8.5 Applications
8.6 Impact
8.1 Introduction to WLAN

Definition
A wireless local area network (WLAN) links two or more devices by using some wireless
distribution method. It connects the devices such as PCs based on 802.11a, 802.11b, 802.11g,
or 802.11n, the various versions of IEEE 802.11 (Wi-Fi), to form a resource-sharing
communications network. Radio waves are the media of data transmission on a WLAN.
Usually, cables are used on the backbone layer of a WLAN, and users access the WLAN from
one or more wireless access points (WAPs). WLANs are popular on the campus and in the
business centers, airports, and other public areas. The primary advantage of WLANs is that
terminals such as computers can access a network through a wireless medium rather than a
connected cable, which facilitates the network construction and gives users mobility to move
around.
The WLAN feature includes AP management, RF management, Service Set Management
(ESS profile), configuration auto-provisioning management, centralized BSSID management,
load balancing, WLAN STA roaming, WLAN security, and QoS.
WLAN basics
Currently, the primary WLAN Wi-Fi access standards include IEEE 802.11a, 802.11b,
802.11g, and 802.11n.

8 WLAN Feature Description - User Access
A Wi-Fi-enabled device such as a mobile phone, laptop, or PDA can connect to the
Internet when within range of a wireless network connected to the Internet. A Wi-Fi
network uses the public channel provided for the equipment such as cordless telephones.
Once a hotspot is connected to the high-speed Internet, a Wi-Fi network can be set up
within hundreds of meters around the hotspot.
Wi-Fi signals can be transmitted within only a radium of hundreds of meters but its rate
can reach tens of megabits per second. The latest version of IEEE 802.11n supports the
transmission rate of hundreds of megabits per second and the coverage of signals can be
expanded to several square kilometers. This greatly improves the mobility provided for
users. The architecture of a Wi-Fi network is very simple. Manufacturers deploy hotspots
at airports, bus stations, coffee bars, libraries, and other densely populated places. To
access the Internet at a high speed, users only need to take the equipment that supports
Wi-Fi to receive signals in these areas.
Compared with other wireless access technologies, Worldwide Interoperability for
Microwave Access (WiMax) features longer transmission radius, and the transmission
distance can reach 50 kilometers; the cost of construction, however, is relatively high
because big stations need to be deployed to support WiMax. WiMax can transmit data
between Wi-Fi hotspots, but it cannot take the place of cost-effective and flexible Wi-Fi
in homes and offices. In a word, WiMax uses the licensed or unlicensed spectrum to
serve in metropolitan area networks (MANs), whereas Wi-Fi uses the unlicensed
spectrum to serve in local area networks (LANs). As a complement to each other,
WiMax and Wi-Fi provide a complete MAN/LAN solution.
3G access is another WAN technology. The same as WiMax, 3G access requires the
support of big base stations. It provides seamless coverage in the downtown and suburbs
so that users can use the services provided by the system everywhere.
Among the three wireless access technologies, Wi-Fi is relatively mature and its
development is quite fast. It can be used together with WiMax and 3G access in wireless
access.
WLAN network architecture
The Control And Provisioning of Wireless Access Points (CAPWAP) working group of
the Internet Engineering Task Force (IETF) researches on the solution to large-scale
WLANs. This working group defines three WLAN architectures after a research on the
popular WLAN solutions. They are autonomous WLAN architecture, centralized WLAN
architecture, and distributed WLAN architecture. The distributed WLAN architecture is
not described in this document because no network devices are required for this
architecture.
A conventional WLAN usually adopts the autonomous architecture, which is also called
the fat access point (AP) mode. In this mode, an AP carries out all the functions defined
in IEEE 802.11, and every AP in the WLAN needs to be configured, managed,
monitored, and controlled. Because a large-scale WLAN consists of hundreds of APs, the
configuration and management of all the APs in the WLAN inflict a heavy load on the
network management system. On the other hand, APs are independent of each other,
which makes the dynamic management of network-wide wireless resources difficult. In
addition, APs are often installed in unsafe places to cover wide areas. Thus, if APs are
stolen, the configurations statically stored on the APs will leak. How to deny illegal APs
the access is also a great challenge to the autonomous WLAN architecture. To solve all
the preceding problems of the autonomous WLAN architecture, the centralized WLAN
architecture emerges, giving solutions to the network management, security, resource
management, and interoperability in large-scale WLANs. The centralized WLAN
architecture is also called the fit AP mode.

Figure 8-1 Centralized WLAN architecture
WTP
WTP Switch AC
IP
WTP
Ntetword
Commnmication
Protocol
As shown in Figure 8-1, an access controller (AC) is added in the centralized

architecture compared with the autonomous architecture. An AC can be considered as a
group of logical devices, which implement network management, monitoring, dynamic
configuration, and Authentication, Authorization, and Accounting (AAA). The wireless
termination points (WTPs) shown in this figure are different from the APs defined in
IEEE 802.11. APs perform all the functions defined in IEEE 802.11, whereas WTPs
perform only some of these functions. Therefore, WTPs are considered as lightweight
APs. The connection between an AC and a WTP can be a direct connection, an L2
switched connection, or an L3 routed connection. Through an L3 routed connection, a
WTP can access an AC on an IP network, which makes the WTP deployment more
flexible and implements seamless Layer 3 roaming. For this reason, L3 routed
connections are widely used.
In the centralized WLAN architecture, the CAPWAP protocol is applied to endow the
AC with WTP management capabilities. Most of the CAPWAP functions reside in the
AC (except for the function defined in IEEE 802.11, the CAPWAP working group
defines the following CAPWAP functions: RF monitoring, RF configuration, WTP
configuration, WTP firmware loading, network-wide STA state information database,
mutual authentication between network entities, for example AC and WTP authentication
in a centralized WLAN architecture). The physical layer functions defined in IEEE
802.11 reside in the WTP, and there are three MAC architectures, namely, local MAC,
split MAC, and remote MAC.
The local MAC architecture means that both the link layer and physical layer functions
reside in the WTP. Conversely, the split MAC architecture requires that only the
real-time MAC functions reside in the WTP, whereas the AC takes on an role to process
the non-real time MAC functions. The real-time MAC functions include beacon
generation, probe transmission and response, control frame processing (for example
Request to Send (RTS) and Clear to Send (CTS), and retransmission; the non-real time
functions include authentication and deauthentication, association and reassociation,
bridging between Ethernet and wireless LAN, and fragmentation. In the remote MAC
architecture, however, 802.11 MAC functions reside in the AC, which are completely
separated from the physical layer functions.
In the local MAC architecture, the WTP processes wireless frames and then encapsulates
them into IEEE 802.3 frames before forwarding them to the AC; in the split MAC
architecture, the WTP directly encapsulates wireless frames before forwarding them to
the AC.
AP management
As a basic function of the AC, AP management includes version management,
configuration management, access control, and domain and group management of APs.
RF management

When radio signals are propagated, they are greatly affected by surroundings.
Specifically, due to multipath options, radio signals encounter complex attenuation in
different directions. Therefore, thorough network planning is performed before build-out
of a WLAN network. After a WLAN network is deployed, radio signal propagation may
also be affected by much interference arising from constant change of the wireless
environment, moving obstacles, and operating microwave. Therefore, it is inevitable to
adjust parameters. In this case, RF resources such as channel and transmit power must be
dynamically adjusted to adapt to changes of application environments.
RF management is to apply a set of systematic real-time intelligent RF methods
(including data collection, data analysis, decision making, and decision execution) to the
wireless network, so as to quickly adapt to changes of the wireless environment and
maintain the optimal status of RF resources.Figure 8-2 shows the RF management
process.
Figure 8-2 RF management process

Data collection: APs collect RF
Data analysis: The AC analyzes
environment information in real
and assesses data collected by
time according to policies provided
the APs.
by the AC.
Decision execution: APs execute Decision making: According to the

configurations set by the AC and analysis result, the AC assigns
adjust RF resources. channels and transmit power.
Service set management (ESS profile)

Service set management is to manage certain attributes of a service set, including
creating, deleting, modifying, and querying the service set.
Configuration auto-provisioning management
Configuration auto-provisioning management is to manage the creation, modification,
deletion, and query of the configuration auto-provisioning rules. Configuration
auto-provisioning rules are pre-defined. In this manner, APs can obtain necessary
configurations and perform configurations automatically.
Centralized BSSID management
Basic service set (BSS) is a basic component over the 802.11 network, and comprises a
group of stations (STAs) that can communicate with each other. Every BSS is assigned a
BSSID to uniquely identify the BSS (the BSSID is a binary 48-bit identifier used by all
STAs in a BSS).
Centralized BSSID management is a process in which the AC automatically assigns a
unique BSSID over the entire network to every VAP, eliminating any need of manual
operations.
Load balancing
Load balancing is a method to load the excess STAs on an AP to other APs within the
same group as the AP when the quantity of STAs on the AP exceeds the preset user
quantity and user traffic threshold.
WLAN STA roaming

When a STA moves at a small area within a deployed WLAN network, the STA may
roam from one AP to another. For this scenario, the WLAN STA roaming function is
provided.
WLAN STA roaming is a process in which an STA moves from one AP to another.
Currently, Huawei's products support quick WLAN STA roaming within a same AP. That
is, if an STA uses 802.1x authentication, 802.1x authentication and key exchange are not
performed after the client moves from one AP to another, thus speeding up roaming.
In short, when an STA roams from one AP to another (the two APs are within the same
AC), the STA does not need to log in or be authenticated again.
Figure 8-3 shows quick WLAN STA roaming.
Figure 8-3 Quick WLAN STA roaming
AC
ESS
AP1 AP2
Roam
STA STA
ESS: extended service set

STA: station
The following types of quick WLAN STA roaming are supported:

− IPoE STA roaming at Layer 2 within the same AC.
− IPoE STA roaming at Layer 3 within the same AC, that is, STA roaming among
different subnets.
− PPPoE STA roaming under a same physical port at Layer 2 within the same AC.
QoS
The 802.11 network provides contention-based wireless access services, and different
applications have different network requirements. The original network, however, fails to
fulfill actual applications because it fails to provide access services of different qualities
for different applications. To ensure the interoperability between different WLAN
vendors' devices that provide QoS services, the Wi-Fi Alliance defines the Wi-Fi
Multimedia (WMM) standard, which enables the WLAN to be capable of providing QoS
services.
With WMM-based QoS, wireless access services of different qualities over the entire
WLAN are managed.

− Wireless access services are managed through the WMM profile. The WMM profile
includes the following parameters: WMM function switch, permission control switch,
and EDCA parameters.
− Wired access services are managed through the traffic profile. The traffic profile
includes the following parameters: wireless upstream rate limitation on the
VAP/client, UP priority configuration of the 802.11 packets, 802.1p priority
configuration of the upstream 802.3 packets, and upstream/downstream tunnel
priority configuration.
WLAN security
The access to wired networks can be restricted through physical means to a certain extent.
As for the security of WLANs, if it is not taken seriously, the intruders can gain
unauthorized access by listening to wireless data. Most of the Wi-Fi-enabled wireless
network entities complying with IEEE 802/11a, IEEE 802.11b, or IEEE 802.11g support
several security measures in authentication, such as Wired Equivalent Privacy (WEP),
Wi-Fi Protected Access (WPA), and WPA2.
WLAN access security mainly includes functions such as configuration of
security-related parameters, and frame encryption/decryption and key management on
the wireless side.
Currently, the OPEN-SYS and shared key authentication modes and standards such as
WPA/WPA2 authentication modes, and WAPI authentication modes are supported.
WLAN standards and organizations
Standards of WLAN technologies are mainly defined by the IEEE 802.11 working group.
The first IEEE 802.11 standard emerged in 1997 and its revision was completed in 1999.
To address the security defects of this version and to meet the requirements of higher
throughput and manageability along with the development of user and enterprise
applications, the IEEE 802.11 working group later defines and develops a lot of
subsequent versions of IEEE 802.11, including IEEE 802.11a, IEEE 802.11b, IEEE 802.
11g, IEEE 802.11i, IEEE 802.11e, IEEE 802.11n, and IEEE 802.11k. In addition, the
IETF's CAPWAP working group also defines the standard for wireless AP management.
− Wireless throughput
From IEEE 802.11a, IEEE 802.11b, and IEEE 802.11g to the latest IEEE 802.11n, the
maximum throughput of the physical layer is increased from 54 Mbit/s to 600 Mbit/s.
− Wireless security
To address the security defects in IEEE 802.11, such as the defects of WEP, the IEEE
802.11i working group proposes IEEE 802.11i. China also defines a WAPI standard,
which is now waiting for approval to become an international standard. Both IEEE
802.11i and WAPI aim to protect the security of users' wireless data. The 802.11
protocol packets (management packets) are also important in security protection; thus,
the IEEE 802.11w working group is developing a standard concerning the security of
management packets.
− Wireless manageability
The large-scale deployment of WLANs and demands for voice over WLAN services
raise higher requirements of the management over wireless resources and stations. To
meet the requirements, IEEE 802.11k and IEEE 802.11v working groups come into
existence. In addition, to simplify the deployment of a lot of APs and reduce the costs
of operation, the IETF assigns a CAPWAP working group to define specific
standards.
− Other standards
To meet the requirements of QoS and fast roaming as the demands for Voice over
WLAN services increase, the IEEE 802.11e and 802.11r working groups come into

existence. One more working group, the IEEE 802.11s working group, is assigned to
define the WLAN-based mesh network technologies.
As an organization is required to promote the products and industrialization of IEEE
802.11 and certify the interoperability of products, the Wi-Fi Alliance comes into being.
This alliance defines a lot of certification standards based on IEEE 802.11, such as the
WPA/WPA2 certification standard based on IEEE 802.11i and Wi-Fi MultiMedia
(WMM) certification standard based on IEEE 802.11e. The existence of the Wi-Fi
alliance greatly promotes the industrialization of WLANs.
When being created in 1999, the Wi-Fi Alliance was called the Wireless Ethernet
Compatibility Alliance (WECA) at that time. In October 2002, its name was changed to
Wi-Fi Alliance.
Now, the certification types released by the Wi-Fi Alliance include:
− WPA/WPA2: It is a certification program created by the Wi-Fi Alliance to indicate
the compliance of the IEEE 802.11a/b/g-based single-mode, dual-mode, or dual-band
products with the security protocol. The certification includes the verification of
protocol negotiation and the security mechanism of wireless networks as well as the
debugging of transmission performance of networks and the compatibility.
− WMM: It is a certification program created by the Wi-Fi Alliance to verify the
bandwidth guarantee and security for the multimedia data when it is transmitted
through different wireless network entities on the wireless network.
Purpose
The access to WLANs is independent of the positions of cables and ports. It enables users to
access the network anywhere at any time. In WLAN access, cabling between stations and
devices is not required, which effectively saves the cost of cabling and makes the network
construction more economical and communications more convenient. With these advantages,
WLANs are applicable especially in the special environment such as tunnels, ports, docks,
and highways.
Benefits
This feature brings the following benefits to operators:
− Costs of network construction can be reduced.
− The requirements of various user applications can be met.
This feature brings the following benefits to users:
A user can access a WLAN everywhere at any time, experiencing great mobility and
flexibility.
8.2 References
AP Management
The reference standards and protocols for AP management of the AC are as follows:
Document Name Description

RFC 5415 CAPWAP protocol
RFC 5416 CAPWAP protocol binding IEEE 802.11

Document Name Description

RFC 5417 CAPWAP AC DHCP option
RFC 4347 Datagram Transport Layer Security
RFC 4118 CAPWAP Architecture Taxonomy
RFC 4564 Objectives for Control and Provisioning of
Wireless Access Points (CAPWAP)
WLAN Access Security

Relevant reference standards and protocols of WLAN access security are as follows:
802.11i-2004
IEEE802.11-2007
Guide for WAPI
QoS
Relevant reference standards and protocols of QoS are as follows:
802.11e-2005, Amendment 8: Medium Access Control (MAC) Quality of Service
Enhancements, IEEE Computer Society, 2005.
Wi-Fi, WMM Specification version 1.1, Wi-Fi Alliance, 2005.
8.3 Availability
Related Network Elements
WLAN access supports the centralized WLAN architecture in local MAC mode. The network
includes APs and an AC function-integrated BRAS. APs collaborate with the AC to access
wireless users.
License Support
You can deploy the WLAN access service only after obtaining an AP management license.
Version Support
Product Version
CX600 V600R002
Feature Dependency
N/A

Hardware Support
The boards that support WLAN access are as follows:
CX600: LPUF-21 and LPUF-40
Others
N/A
8.4 Principles
8.4.1 AP Management
This topic describes the principles of AC auto-discovery, AP domain management, version
upgrade, and CAPWAP protocol.
8.4.2 RF Management
This topic describes the principles, methods, and advantages of channel adjustment and power
adjustment.
8.4.3 Service Set Management (ESS Profile)
This topic describes the principle of service set management.
8.4.4 Configuration Auto-Provisioning Management
This topic describes the principle of configuration auto-provisioning management.
8.4.5 Centralized BSSID Management
This topic describes the principle of centralized BSSID management.
8.4.6 Load Balancing
This topic describes the principle of load balancing.
8.4.7 WLAN STA Roaming
This topic describes the principle, implementation mode, and precautions of quick STA
roaming.
8.4.8 WLAN Access Security
This topic describes the principles of OPEN-SYS, shared key, and 802.1x authentication, and
WEP, WPA, WPA2, and WAPI authentication and encryption of WLAN access security.
8.4.9 QoS
This topic describes the principle of QoS management.
8.4.1 AP Management
This topic describes the principles of AC auto-discovery, AP domain management, version
upgrade, and CAPWAP protocol.

Principle of AC Auto-Discovery
After an AP is powered on, it can automatically discover an AC in either static or dynamic
mode. Figure 8-4 shows the operation flow.
Figure 8-4 Flowchart of AC auto-discovery
Start
Y N
Any pre-configured static
AC IP address list?
AP associates AP enables the

with the AC with dynamic AC
specified IP discovery
address mechanism
AP associates
with AC
End
End
As shown in Figure 8-4, if a static AC IP address list is pre-configured, the AP directly

connects to the AC with the specified IP address. If no AC IP address list is pre-configured,
the AP enables the dynamic AC auto-discovery mechanism to associate with the AC.
Figure 8-5 shows the topology of the AC and the AP.
Figure 8-5 Topology of the AC and the AP
AC
DHCP/DNS
Switch server
AP
An AP can implement AC auto-discovery by pre-configuring a static AC IP address list or

dynamically obtaining an AC IP address through the DHCP server or the DNS server.
AC auto-discovery by pre-configuring a static AC IP address list:

When the AP is started, it sends a DHCP discovery packet to obtain an IP address. Then, the
AP pre-configures a static AC IP address list. The AP sends a discovery request to all the ACs
whose IP addresses are contained in the pre-configured list. If the AP receives a discovery
response from an AC, the AP automatically sets up a management connection to the AC. If the
AP does not receive a response from any AC, the AP waits for 30s before initiating the
discovery process again.
AC auto-discovery by dynamically obtaining an AC IP address through the DHCP
server:
When no AC IP address list is pre-configured, the AP enables the dynamic AC auto-discovery
mechanism. Then, the AP dynamically obtains the IP address of an AC through the DHCP
server. Figure 8-6 shows the registration flow.
Figure 8-6 Registration flowchart of the AP obtaining an AC IP address through the DHCP server
AP DHCP server AC
AP obtains IP
address and DHCP
server domain name
1
AP sends discovery request

2
Switch sends discovery response

3
AP downloads version
4
AP downloads configuration
5
AP and AC transfer user data

6
As shown in Figure 8-6, the registration flow of the AP dynamically obtaining an AC IP

address through the DHCP server is as follows:
1. The AP obtains its own IP address, and obtains the AC IP address (through DHCP
Option 43) and DHCP server domain name through the DHCP server.
2. The AP enables the CAPWAP discovery mechanism and broadcasts discovery requests,
attempting to associate with the switch.
This step is optional. The AC will voluntarily send broadcast packets at a certain interval to associate
with the AP ready for connection within the frequency range.

3. On receipt of the discovery request, the AC checks whether the AP has the right (proven
by an authorized MAC address or SN) to access the AC. If the AP is authorized, the AC
replies with a discovery response; if not, the AC rejects the association request of the
AP.
4. The AP downloads the latest software version from the AC.
5. The AP downloads the latest configuration from the AC.
6. The AP starts to run in the normal state and exchanges user data packets with the AC.
AC auto-discovery by dynamically obtaining an AC IP address through the DNS server
The AP can also dynamically obtain the IP address of an AC through the DNS server. Figure
8-7 shows the registration flow.
Figure 8-7 Registration flowchart of the AP obtaining an AC IP address through the DNS server
AP DHCP server DNS server AC
AP obtains IP
address and DHCP
& DNS server
domain names
1
AP sends discovery request

2
AP does not receive a response over a
long time
AP obtains IP address of switch

3
Switch sends discovery response

4
AP downloads version
5
AP downloads configuration
6
AP and AC transfer user data

7
As shown in Figure 8-7, the registration flow of the AP dynamically obtaining an AC IP

address through the DHCP server and DNS server is as follows:
1. The AP obtains its own IP address, and obtains the AC IP address (through DHCP
Option 43), DHCP server domain name, and DNS server domain name through the
DHCP server.
2. The AP enables the CAPWAP discovery mechanism, and broadcasts discovery requests,
attempting to associate with the switch. The AP may take either of the following actions
if no response is received after multiple attempts:

− If the DHCP server supports Option 43 and the response message (for allocating the
IP address) carries Option 43, according to the AC host name list carried in Option 43,
the AP obtains the IP addresses of the ACs in the list from the DNS server and sends
discovery requests to the ACs one by one.
− If the DHCP server does not support Option 43, the AP obtains the HW.xxxx.xxx IP
address from the DNS server. "xxxx.xxx" is the domain name that the AP has learned
from the DHCP server. Then, the AP sends discovery requests to the IP address.
3. On receipt of the discovery request, the AC checks whether the AP has the right to
access the AC. If the AP is authorized, the AC replies with a discovery response. On
each AC, the access priorities of APs are configured. For the AP with a higher priority,
the AC sends the discovery response within a shorter time. For the AP without the access
right, the AC rejects its discovery request.
4. The AC sends a discovery response indicating that the discovery is successful.
5. The AP downloads the latest software version from the AC.
6. The AP downloads the latest configuration from the AC.
7. The AP starts to run in the normal state and exchanges user data packets with the AC.
AP Domain Management
Domain is a logical concept. A set of APs can be grouped in one domain. Domain division is
planned by the carrier according to actual deployment. Usually, a domain maps a hot spot. In
addition, an AP domain is also the effective domain of radio frequency (RF) adjustment. The
RF optimization algorithm can be conducted based on the domain. The difference between
certain RF optimization parameters can be demonstrated by the deployment mode of domains.
The deployment mode of an AP domain can be set to any of the following:
Distributed deployment: AP working at the maximum power; no power optimization
involved
Common deployment: Minimum power of AP = Maximum power x 50%
Dense deployment: Minimum power of AP = Maximum power x 25%
An AP domain can be manually created. When manually creating an AP domain, you must
specify a domain that can be the default domain. In AP auto-online mode, the AP
automatically creates a default domain and then joins it. The default domain is typically
applied to the deployment of a hot spot. On the hot spot, after APs are installed and powered
on in advance, the APs automatically connect to the network and join the default domain
(provided that the default domain does not contain any AP). Then, the APs create a domain
corresponding to the current hot spot and import all the APs in the default domain into the
new domain.
Version Upgrade
Version upgrade is classified into two types: automatic upgrade and manual batch upgrade.
Automatic upgrade
Automatic upgrade complies with CAPWAP. After an AP is started and goes online, the AP
compares its version with the version information on the AC. If the versions are different, the
AP automatically upgrades its version. The AC can specify the version to be used by the AP of
a certain type through configuration.
Manual batch upgrade

In this mode, you can run commands to trigger the upgrade of the AP of a certain type. This
mode is valid to online APs. The APs download the version but do not automatically reset.
You can run the reset command to reset the APs of different types in batches.
A typical application is to batch download the version to the APs in the daytime and batch
reset the APs at night.
Two upgrade modes are supported: by downloading through the AC and by downloading
through the FTP server. The APs can be batch upgraded based on their type. The concurrency
in the AC download mode is 128 and is not limited in the FTP download mode, depending on
the capability of the FTP server.
CAPWAP Protocol
Controlling and Provisioning of Wireless Access Point (CAPWAP) defines how
communication is implemented between an AP and an AC. CAPWAP provides a universal
encapsulation and transmission mechanism for the interoperability between the AP and the
AC.
CAPWAP runs on the AP and the AC at the same time to provide secure AC-AP
communication in a WLAN system. CAPWAP establishes UDP-based tunnels between the
AC and the AP. After the AP discovers the AC, the AP requests for the establishment of a
CAPWAP channel, and subsequent exchange and control are conducted through the channel.
The channel can be classified into the control channel and data channel. The control channel
is mandatory and the data channel is optional.
According to CAPWAP, the data channel is also mandatory. As supported by the equipment, however,
the data channel can be optional. In other words, data can be directly forwarded so as to improve
forwarding efficiency.
The control channel runs control protocols. Various message elements are used to define
different control meanings. CAPWAP defines some message elements and provides some
user-defined elements for extension. Various configuration, control, and query information is
transmitted through the control channel.
The tunnels are fitted with a heartbeat detection mechanism and DTLS encryption mechanism.
The two mechanisms guarantee the security of CAPWAP tunnels. As defined in CAPWAP,
DTLS is mandatory for the control channel and optional for the data channel.
channel forwarding
When channel forwarding is adopted, a CAPWAP data channel is set up between the AP
and the AC. All user packets are encapsulated through the channel. The AP is responsible
for packet encapsulation and the AC is responsible for packet decapsulation. User
packets cannot be sensed or changed on the network between the AP and the AC.
The channel forwarding mode is applicable to the situation where there is a Layer 2 or
Layer 3 network between the AP and the AC.

Figure 8-8 Channel forwarding mode
L2/L3
Network
PC AP AC/BAS
User packet
CAPWAP tunnel
Non-channel forwarding
If the non-channel forwarding mode is adopted, each user packet does not need to be
encapsulated through a CAPWAP data channel but is directly forwarded along the
network between the AP and the AC. Therefore, non-channel forwarding is also referred
to as direct forwarding. If the non-channel forwarding mode is adopted, a user packet
may be changed on the network between the AP and the AC.
The non-channel forwarding mode is applicable only to the situation where there is a
Layer 2 network between the AP and the AC.
Figure 8-9 Direct forwarding mode
L2 Network
PC AP AC/BAS
User packet
AC discovery starts when a WTP is connected to the network. A WTP sends a discovery
request in broadcast, multicast, or unicast mode. To send a discovery request in unicast mode,
a WTP needs to obtain the IP address list of ACs through DHCP or DNS. The ACs that
receive the request reply to the WTP with send-response packets. The WTP chooses one from
the responding ACs and sets up a DTLS connection with it. Then, the WTP sends a join
request to the AC and the AC replies with a join response to acknowledge that the WTP joins
the management range of the AC. If the firmware version of the WTP is obsolete, the WTP
upgrades its firmware. The WTP downloads firmware of the latest version from the AC. Then,
the WTP upgrades the firmware version and restarts. The WTP enters the discovery process
again. If the firmware on the WTP is of the latest version, it downloads configuration
parameters from the AC and then starts to operate.

Figure 8-10 Principle of CAPWAP
Discover AC
Set up DTLS Restart
Join AC Yes Upgrade the

firmware
Previous
Version
No
Download
configuration
Operation
During operation, the AC dynamically changes the configuration of the WTP through control
packets and obtains the operation status of the WTP and information about stations and radio
frequencies. All the data is processed on the AC. Therefore, the AC can perform QoS
management and dynamic RF monitoring on the entire network.
8.4.2 RF Management
This topic describes the principles, methods, and advantages of channel adjustment and power
adjustment.
RF adjustment involves two modes: global optimization and individual periodic optimization.
Global optimization is based on the RF domain. That is, ACs within a same RF
coordinate RF parameters of all relevant APs in a unified manner to achieve optimal
performance. The use of the RF domain zooms out the applicable scope of the RF
optimization algorithm and therefore speeds up optimization. The signal coverage of the
RF domain must be the same as that of the AP domain.
Individual periodic optimization is to make adjustments on a single AP.
RF optimization (global optimization and individual periodic optimization) is triggered in any
of the following modes:
Individual periodic optimization is triggered according to the air-interface performance
indexes detected periodically (the indexes include conflict rate threshold and packet
loss/error packet threshold).
Global optimization can be triggered at the preset time. That is, global optimization starts
when the preset time is due.
Global optimization can be triggered manually.
Channel Adjustment
Within a WLAN network, channel resources are scarce and non-overlapping channels over
which every AP works are very limited. For example, for a 2.4G network, there are only three
non-overlapping channels. Thus, it is very crucial for wireless applications to assign channels

intelligently to APs. In addition, within the operating frequency range of WLAN, there are a
large number of possible interference sources such as radar and microwave. They will
interfere in the normal operation of APs. The channel adjustment function can achieve the
following results: Every AP can be assigned an optimal channel, with minimum interference
from neighboring channels; APs are free from interference sources such as radar and
microwave because of real-time channel detection. Dynamic channel adjustment achieves
continuous communications and provides reliable transmission over the wireless network.
A centralized channel assignment mechanism is used on the AC, and relevant information
throughout the deployed wireless network needs to be collected periodically. The information
includes the neighboring relationships of an AP, BSSID and operating channel of the AP,
signal strength and interference that the AP perceives on the operating channel, and STAs
connected to the AP.
AP side
In the case of global optimization, all APs work on the same channel. In the case of individual
periodic optimization, an AP needs to detect, on the current operating channel, the Received
Signal Strength Indicator (RSSI) strength from neighboring APs to the AP, collect RSSI
values of all available channels (channels 1, 6, and 11), and save and report the collected
values to the AC.
To ensure accuracy, you can collect the average RSSI value within a period of time.
AC side
The AC receives information collected by all APs managed by the AC, and then based on the
information calculates channels for APs through an optimization algorithm. The optimization
algorithm ensures overall optimum of frequency effectiveness, that is, minimum interference
but best performance.
Power Adjustment
A traditional method of controlling RF power is to statically set the transmit power to the
largest value for the largest signal coverage. Such a large transmit power may bring
interference to other wireless equipment. Therefore, an optimal power that balances signal
coverage and system capacity needs to be selected.
Power adjustment is to dynamically assign a proper power according to the real-time status of
the wireless network. When an AP runs for the first time, the AP uses the maximum transmit
power. When getting reports from its neighbors (that is, other APs that are detected by the AP
and managed by the same AC), the AP decides to increase or decrease its power according to
the report conclusion.
When a neighbor is added, the power of the AP is decreased. As shown in Figure 8-11,
when AP4 is added, the neighbor quantity of each AP reaches the default upper limit 3
(this limit is configurable). In this case, the frequency transmit coverage of every AP
becomes smaller. It can be seen that the power of every AP is smaller than that in the
case of three APs.

Figure 8-11 Power decrease
AP1 AP2
AC Switch
AP3
When AP4 is added, the neighbor

quantity of each AP reaches the default
upper limit 3 (this limit is configurable).
In this case, the power of every AP
becomes smaller.
AP1 AP2
AC Switch
AP3 AP4
Channel 1
Channel 6
Channel 11
As shown in Figure 8-12, if AP4 goes offline, the power of each of the other three APs
will be increased to eliminate "black hole" of signal coverage.

Figure 8-12 Power increase
AP1 AP2
AC Switch
AP3 AP4
When AP4 goes

offline, the power of
each of the other three
APs is increased to
guarantee the wireless
coverage.
AP1 AP2
AC Switch
AP3
Channel 1
Channel 6
Channel 11
Elimination of "Black Hole" of Signal Coverage

Currently, when an AP is deleted or goes offline, the power of its neighbors is increased to
eliminate signal coverage "black hole" caused by the AP. As shown in Figure 8-12, when AP4
is powered off or goes offline due to a fault, the power of the other three APs is increased to
enhance their downstream signal strength, thereby eliminating signal coverage "black hole"
caused by AP4.

8.4.3 Service Set Management (ESS Profile)

This topic describes the principle of service set management.
In terms of service set management, multiple service set profiles can be pre-configured, bound,
and then issued. Service set profiles are bound to RF resources of APs. Certain APs may
support multiple RFs. In this case, you can bind service set profiles to these RFs respectively.
After a service set profile is bound to an RF, a VAP is generated in the system. In fact, a VAP
is a type of binding relationship between the AP, RF, and service set profile. The VAP
functions like an RF instance of the service set profile on the AP. It has all attributes of the
service set profile and uses RF hardware of the AP.
Service set parameters include SSID, whether to hide SSID, Layer 2 user isolation, user
association timeout period, service set type, IGMP status, VLAN ID, traffic policy, and
security policy. For details, see Table 8-1.
Table 8-1 Description of parameters of service set management

Parameter Description
SSID Indicates the network name of the service set.
Whether to hide SSID Controls whether SSID is hidden in the Beacon frame sent by
the service set at the preset time or interval. If the "whether to
hide SSID" function is enabled, the SSID field in the Beacon
frame is null; otherwise, the SSID field is not null.
NOTE
After SSID is hidden, STAs cannot search out the SSID.
Layer 2 user isolation Controls Layer 2 isolation of users associated with the service
set.
User association timeout Controls the aging timeout period of users associated with the
period service set. When a user does not send any data when the user
association timeout period is due, the user is aged.
Service set type A service set can be of three types, that is, management, data
forwarding, and service.
Management type: This type of service set manages APs. APs
can determine whether to forward data upstream according to
the data forwarding status of the management type service
set.
Data-forwarding type: This type of service set manages ACs.
An AC, after determining that a user in a management service
set is accessing the AC according to the VLAN information,
identifies the user as a management user during user
authentication according to the VLAN information. In this
manner, the user can make a Telnet connection to the AC in
an inband manner.
Service type: This type of service set cannot manage the
equipment.
IGMP status Indicates the IGMP status that can be off, proxy, or snooping.
VLAN ID Indicates the ID of the VLAN mapping the service set.

Traffic policy Indicates the traffic policies implemented by the service set.
Security policy Indicates the security policies (such as authentication and
encryption) implemented by the service set.
8.4.4 Configuration Auto-Provisioning Management

This topic describes the principle of configuration auto-provisioning management.
Configuration auto-provisioning management involves managing and applying configuration
auto-provisioning rules.
In terms of managing configuration auto-provisioning rules, you can create, modify, delete, or
query a rule. Configuration auto-provisioning rules are based on the AP type and the RF index.
Before admitting STAs, an AP requires certain configurations including relevant parameters
of every RF on the AP and service sets applied on every RF.
Configuration auto-provisioning rules consolidate configuration actions and configuration
data for a specific AP and are applied to all APs of the same type as the specific AP. This is
because a type of fit APs in the centralized control architecture generally have the same
configurations.
When the AC discovers an AP and starts configurations for the AP, the AC queries
configuration auto-provisioning rules.
If the type of the AP matches configuration auto-provisioning rules, the AC applies the
matched configuration auto-provisioning rules to the AP. After the application of the
preceding rules, the configuration for the AP is already complete and the AP can transmit
services.
For an AP, the manually added rules have higher priority than the automatically allocated
rules.
8.4.5 Centralized BSSID Management

This topic describes the principle of centralized BSSID management.
Table 8-2 describes the carrier ID.
Table 8-2 Carrier ID
Carrier ID Used to uniquely identify a carrier over the entire network.
Carrier ID is selected only from the preset enumerated options.
Currently, the supported enumerated options are:
cmcc: China Mobile
ctc: China Telecom
cuc: China Unicom
Table 8-3 describes the AC ID.

Table 8-3 AC ID
AC ID Used to uniquely identify an AC managed by a carrier. The AC
ID ranges from 0 to 4095.
8.4.6 Load Balancing

This topic describes the principle of load balancing.
On the AC, you can configure STA-quantity-based load balancing (that is, load balancing
based on the quantity of STAs connected to the AP) or traffic-based load balancing for an AP.
The precondition for load balancing to take effect is that: On the AC, the load balancing
threshold for an AP and the maximum number of STAs connected to the AP are configured
beforehand.
When the quantity of STAs connected to an AP exceeds the preset threshold, the AP
starts to perform load balancing, denying the connection attempt of any STA.
When the quantity of STAs connected to an AP is lower than the preset threshold, the AP
admits a connection attempt of an STA and associates with the STA.
8.4.7 WLAN STA Roaming

This topic describes the principle, implementation mode, and precautions of quick STA
roaming.
When quick STA roaming occurs, the STA in involved in the following procedures:
1. Roaming detection. When the STA pre-starts roaming, it sends a roaming request to
every channel.
2. Roaming triggering. STA roaming can be triggered in any of the following modes:
− According to the ratio of the signal strength of the current AP to the signal strength of
neighboring APs, STA roaming is triggered if the ratio reaches the preset threshold.
− According to service indexes such as packet loss ratio, STA roaming is triggered if
the service indexes reach the preset threshold. This roaming triggering mode is slow
and less effective.
3. Roaming operation. For different STAs, there are different operation modes. In general
cases, after sending a roaming request, the STA sends an association request to associate
with a new AP. After the STA's requests are accepted, the STA associates with the new
AP and then deletes association with the original AP. In special cases, the STA directly
associates with a new AP and then de-associates with the original AP.
After quick STA roaming starts, the AC performs processing operations in any of the
following modes:
Quick roaming of IPoE STAs at Layer 2. According to the roaming request sent by the
STA, the AC determines that roaming is a fast roaming, and then starts 4-way handshake
and negotiates PTK to start fast roaming, as shown in Figure 8-13.

Figure 8-13 4-way handshake during the AC's processing quick roaming
AP AC
Roam request
Roam response
Request of associating with a

new AP
Response to the request of
associating with a new AP
Quick roaming of IPoE STAs at Layer 3. The process is similar to the preceding process
at Layer 2. The difference is that the AC determines that the STA requires a roaming
across Layer 3, and then the AC directly uses the original service IP address and
implements re-leasing in the original IP address domain for the STA through proxy.
Figure 8-14 shows the principle of quick roaming by a STA within a same AC.

Figure 8-14 Fast roaming by a STA within a same AC
AC
(2) (3)
AP1 AP2
Channel 1 Roam Channel 6
SSID: Huawei SSID: Huawei
SSID: service set identifier

(2) Deassociate between STA and AP1
(3) Set up association between STA and AP2
As shown in Figure 8-14, the AC has associated with AP1. If an STA roams to AP2 from AP1,
the AC processes the STA's roaming as follows:
1. The STA sends the 802.11 request frame to every channel. After receiving the STA's
802.11 request frame in channel 6 (a channel used by AP2), AP2 sends a response frame
in channel 6. After the STA receives the response frame, it assesses the response frame
and determines which AP is best for the STA to associate with.
2. As shown in (2), association between the STA and AP1 is deleted. Specifically, the STA
sends an 802.11 deassociation frame in channel 1 (a channel used by AP1) to AP1 for
deassociation between them.
3. As shown in (3), the STA sends an association request frame in channel 6 to AP2. Then,
AP2 sends an association response frame to the STA, thereby setting up association
between the STA and AP2.
At this moment, the STA roams to AP2 from AP1 quickly.

AP1 and AP2 must use the same SSID, for example, SSID Huawei shown in Figure 8-14.
AP1 and AP2 must be connected to the same AC.
8.4.8 WLAN Access Security

This topic describes the principles of OPEN-SYS, shared key, and 802.1x authentication, and
WEP, WPA, WPA2, and WAPI authentication and encryption of WLAN access security.
OPEN-SYS Authentication
OPEN-SYS authentication is the default authentication mechanism. It is the simplest
authentication algorithm, that is, null authentication. If the authentication type is set to
OPEN-SYS, it indicates that any STA that transmits an authentication request will pass the
authentication. OPEN-SYS authentication involves two stages: authentication request and
authentication result return. If the authentication is successful, the STA and the AP are
declared mutually authenticated. Figure 8-15 shows the process of OPEN-SYS authentication.
Figure 8-15 Process of OPEN-SYS authentication
STA AP
Authentication request
Authentication response
OPEN-SYS authentication is mainly applied to public and hotspot areas, such as the airport
and hotel lobbies where wireless access services (such as Internet access) are provided.
The advantage of OPEN-SYS authentication is that OPEN-SYS authentication is a basic
authentication mechanism and can be implemented by wireless equipment that does not
support complex authentication algorithms. In IEEE 802.11, authentication is
connection-oriented. OPEN-SYS authentication can be used for verifying a design that allows
equipment to quickly access the WLAN. The disadvantage of OPEN-SYS authentication is
that OPEN-SYS authentication cannot detect whether an STA is a legal or illegal client. When
encryption-free OPEN-SYS authentication is adopted, any STA who knows the SSID of a
WLAN can access the WLAN.
WEP Encryption
Wired Equivalent Privacy (WEP) is the earliest security standard in IEEE 802.11. Security
measures of WEP mainly include two stages: authentication and encryption. When an STA
wants to access an AP, the STA must be authenticated, and in perfect conditions, the STA also

expects the AP to be authenticated. This process is a mutual authentication process. After

authentication, data is encrypted and transmitted. Data encryption uses the RC4 algorithm.
Shared Key Authentication

Shared key authentication requires that the STA and AP be configured with the same shared
key.
The process of shared key authentication is as follows: An STA transmits an authentication
request to an AP, and the AP randomly generates a "challenge text" and transmits it to the STA.
The STA then copies the received "challenge text" to a new message, and transmits the
message encrypted with the shared key to the AP. Then, the AP decrypts the message with the
shared key, and compares the decrypted character string with the character string that has been
provided to the STA. If the character strings are the same, it indicates that the STA has the
same shared key with the AP, that is, the STA passes shared key authentication; otherwise,
shared key authentication of the STA fails. Figure 8-16 shows the process of shared key
authentication.
WEP encryption must be adopted for the encryption of shared key authentication.
Figure 8-16 Process of shared key authentication
STA AP
Authentication request
PSK PSK
Randomly generate a
"challenge text"
Cipher text with "challenge

Use the key to Compare the
text" encrypted
encrypt the plain decrypted cipher text
text Successful authentication with the plain text
response
The WEP key used in shared key authentication is a static encryption key. When transmitting
a packet to the AP through WLAN, the AC provides the packet content and the WEP key to
the encryption process of the AP. After receiving the packet from the AP, the STA uses the
same WEP key to decrypt the packet. Compared with OPEN-SYS authentication, shared key
authentication is more secure, but has the following disadvantages:
1. Poor extensibility. Each STA must be configured with a long key character string.
2. Unsatisfactory security. A key is used for a long time before a new key is configured
manually. The longer time the key is used, the longer available time that a malicious user

is used to collect data associated with the key. This increases the probability of key
crack.
The static WEP key can be cracked, and therefore shared key authentication is not
recommended. IEEE 802.11 WEP is the first-generation security solution to wireless
authentication and encryption.
WPA Authentication and Encryption

Wi-Fi Protected Access (WPA) is a commercial standard released by the Wi-Fi Alliance. WEP
authentication and encryption proves insecure; therefore, the Wi-Fi Alliance launches WPA,
which remedies the defects of WEP. WPA provides the following WLAN security measures:
STA authentication or server-based 802.1x (EAP) authentication through the pre-shared
key (PSK).
Mutual authentication between the STA and the server.
Ensuring data encryption by using Temporal Key Integrity Protocol (TKIP) or
Per-Packet Keying (PPK).
Ensuring data integrity by using message integrity check (MIC).
PSK authentication
In this authentication mode, the STA is required to be pre-configured with a key, and then the
AP uses 4-way Handshake to verify the validity of the key. In the case of small-sized
networks without any important data, WPA-PSK authentication can be used. Therefore, PSK
authentication is applicable to small-sized networks with few risks and networks where users
do not need much protection. For large enterprises, they have higher requirements on security,
and 802.1x authentication and encryption is more often used.
WPA TKIP encryption algorithm
TKIP uses the existing WEP encryption hardware embedded in the STA and the AP. In TKIP,
the WEP encryption process is the same as the original WEP encryption process. In TKIP,
however, the WEP key is generated more frequently. In reauthentication each time, a new
WEP key is generated. Actually in TKIP, a new key is generated for each packet. The key is
generated based on an SN and the MAC address of the transmitter (STA or AP). When each
packet is transmitted, the WEP key is updated. When an STA is reauthenticated, a new WEP
key is generated, and then the key is updated for each packet.
If no external authentication server is used or required, WPA authentication can be performed
through PSK. In this case, when the STA and the AP are mutually authenticated, only the PSK
can be used. If data encryption does not use PSK, TKIP speeds up the update of the
encryption key for WEP encryption.
WPA2 (802.11i) Authentication and Encryption

With the official release of 802.11i security standard, WPA2 comes into sight. Different from
WPA, WPA2 adopts 802.1x authentication, with the authentication modes including EAP,
LEAP, EAP-TLS, EAP-TTLS, and PEAP. A pairwise master key (PMK) is generated each
time the user goes online, and the PMK generated each time is different. Therefore,
theoretically, the data encryption key deriving from PMK is secure. WPA2 adopts the CCMP
encryption algorithm for data encryption.
Compared with WPA, WPA2 has the following improvement:
WPA2 adopts the advanced encryption standard (AES) for encryption. AES is an extended
encryption algorithm. WPA2 can also adopt TKIP for data encryption so that it is backward

compatible with WPA. When WPA or any other EAP-based authentication is used, an STA
must submit the authentication request to each AP which the STA is to access. That is, when
the STA wants to access another AP, new authentication is required, which is inconvenient.
Proactive key caching (PKC) of WPA2 solves this problem. With the PKC mechanism, an
STA only needs to be authenticated by its first AP. Then, if the STA is to access another AP,
the STA's authentication information and key that are buffered in the first AP will be
automatically transmitted to this AP, if this AP also supports WPA2 and is configured to be in
the same logic group as the first AP.
WAPI Authentication and Encryption

WAPI, a national standard of PRC in WLAN, is an access control method based on
tri-element peer authentication (TePA). It consists of two parts: WLAN authentication
infrastructure (WAI) and WLAN privacy infrastructure (WPI).
WAI has the following functions:
− Determines the security policy.
− Implements mutual authentication based on certificate or PSK.
− Implements unicast and multicast key negotiation.
WPI can solve all the known problems of WEP.
Figure 8-17 shows the process of WAPI authentication and encryption.

Figure 8-17 Process of WAPI authentication and encryption
AS server
STA AP AC
Authentication activation
Certificate
authentication request
Identity authentication process
Access authentication request

Certificate
authentication response
Access authentication response
Unicast Key negotiation request
Unicast Key negotiation response
Unicast key confirmation
Multicast key notification
Multicast key response

Communica
process
Access network resources

tion
(link encryption)
If an STA is associated with an AP by using WAPI, mutual authentication and key negotiation
are required. WAPI provides two authentication and key management modes:
Based on certificate. In this mode, the whole process of WAPI authentication and
encryption involves certificate authentication, unicast key negotiation, and multicast key
notification.
Based on PSK. In this mode, the whole process of WAPI authentication and encryption
involves unicast key negotiation and multicast key notification.
After unicast key negotiation and multicast key notification are successful, the STA begins
data transmission with the AP. During data transmission, data is encrypted and decrypted by
using the key generated by WAPI, and the encryption algorithm is SMS4.
The STA obtains the AP's security policy through passive monitoring of Beacon frames or
through active probing. If the WAI certificate authentication and key management mechanism
is used, the AP transmits the authentication activation packet to start the certificate
authentication process. After the certificate authentication is successfully completed, the AP
starts the unicast key negotiation process and the multicast key notification process with the
STA. If the PSK mechanism is used, the AP directly starts the unicast key negotiation process
and the multicast key notification process with the STA.

Unicast data transmitted between the STA and AP is protected by the unicast encryption key
and the unicast integrity check key that are calculated through the unicast key authentication
process. The AP uses its notified multicast key to protect and transmit broadcast/multicast
data, and the STA uses the multicast key of which the AP is notified to decrypt the received
data.
802.1x Authentication
IEEE 802.1x is a port-based network access control protocol. It provides an authentication
process framework and supports multiple authentication protocols. In 802.1x, different
authentication protocols use the same EAP encapsulation format. That is, 802.1x only controls
authentication, and the specific authentication also requires other authentication protocols.
In WLAN, 802.1x requires the following logic entities for device authentication.
Supplicant: WLAN STA, also called EAP STA
Authenticator: AP
Authentication server: RADIUS server
802.1x is a port-based network access control protocol, which is used to authenticate and
control access devices on the ports of access control devices in a LAN. If a user connected to
a port passes authentication, the user can access the resources in the LAN. If the user fails to
pass authentication, the user fails to access the resources in the LAN, which is similar to the
physical connection cut.
There are many types of EAP, among which Extensible Authentication Protocol-Transport
Layer Security (EAP-TLS) is a common authentication protocol for authentication in WLAN.
EAP-TLS is based on TLS. TLS, an IETF protocol, is a substitute for Secure Socket Layer
(SSL). TLS can provide secure communication and data transmission services in a public
domain and prevent attacks such as interception and packet tampering. EAP-TLS adopts PKI,
and therefore the following requirements must be met:
The network can authenticate an STA only when the STA obtains a certificate.
The STA can confirm that an AAA server is legal only when the AAA server provides a
certificate.
The certification authority (CA) server must grant certificates to the AAA server and
STA.
In the EAP-TLS authentication process, the STA uses OPEN-SYS authentication to set up an
association with the AP. Before authentication on the RADIUS server is successful, the AP
limits (or denies) all traffic except the EAP traffic.
Figure 8-18 shows the process of 802.1x authentication based on EAP-TLS.

Figure 8-18 Process of 802.1x authentication based on EAP-TLS
RADIUS server
STA AP AC
OPEN-SYM
authentication
Associate
EAP start
EAP request for user identification
EAP response to user indentification User identification
Verify the server

certificate, and use the Server certificate (public key) Server certificate (public key)
public key to encrypt
the master key to
generate PMK STA certificate (master key encrypted STA certificate (master key
by the public key) encrypted by the public key) Verify the STA certificate, and
use the private key to decrypt the
Authentication success master key to generate PMK
Authentication success PMK is generated
Check PMK
4-way handshake key negotiation
consistency, and Check PMK consistency,
generate other keys and generate other keys
Encrypt data packet
8.4.9 QoS
This topic describes the principle of QoS management.
Principle of QoS Management of Wireless Access Services

In IEEE 802.11, the distributed coordination function (DCF) specifies the access modes of the
AP and the STA as carrier sense multiple access with collision avoidance (CSMA/CA).
Before using a channel to transmit data, the AP or STA senses the channel. When the idle
duration of the channel is longer than or equal to the duration for the AP/STA to wait for the
channel to be idle, the AP or STA will select a random backoff time within the range of the
contention window to perform backoff. The AP or STA that terminates backoff first can
occupy the channel.
In WMM, data packets are classified into four AC queues, namely, AC_VO, AC_VI, AC_BE,
and AC_BK. The AC queue with a higher priority is more likely to occupy the channel than
the AC queue with a lower priority. In each AC queue, a set of enhanced distributed channel
access (EDCA) parameters for channel contention is defined. This set of parameters
determines the queues' capability of occupying the channel.
EDCA parameters include the following:
Arbitration interframe spacing number (AIFSN). The larger the AIFSN value, the longer
it takes to wait for the channel to be idle.
Exponent form of CWmin (ECWmin) and exponent form of CWmax (ECWmax). These
two values determine the average backoff time. The larger these two values, the longer
the average backoff time.

Transmission opportunity limit (TXOPLimit), indicating the maximum duration of

occupying a channel after the AP/STA succeeds in contending for the channel. The larger
the value, the longer it takes the AP/STA to occupy the channel. If the value is 0, it
indicates that the AP/STA can transmit only one packet each time the AP/STA occupies
the channel.
ACK policy: NORMAL ACK means that the receiver responds with an ACK message
for confirmation after successfully receiving every unicast packet. No ACK means that:
When communication is very good with little interference, the receiver does not respond
with an ACK message after receiving every unicast packet; the unicast packet is not
re-transmitted even when the receiver does not receive the unicast packet. This is to
improve transmission efficiency.
EDCA parameters for an STA include AIFSN, ECWmin, ECWmax, and TXOPLimit; EDCA parameters
for an AP include AIFSN, ECWmin, ECWmax, TXOPLimit, and ACK policies.
EDCA parameters and other WMM parameters are integrated in the WMM profile for
centralized management. Table 8-4 lists parameters of the WMM profile.
Table 8-4 Parameters of the WMM profile
WMM switch Enables or disables the WMM function.
Permission control Determines whether an STA that does not support the WMM
switch function can access the AP that supports the WMM function.
EDCA For details about the EDCA parameters, see the preceding
description. Parameters of the four queues (AC_VO, AC_VI,
AC_BE, and AC_BK) of EDCA can be configured for the AP and
the STA respectively.
A WMM profile can be created, modified, deleted, or queried. When a WMM profile is bound
to an RF profile, the WMM profile cannot be deleted. After a WMM profile is created, the
WMM profile needs to be bound to an RF profile and will be applied to the RF to which the
RF profile is bound.
Principle of QoS Management of Wired Access Services

In the upstream direction, after receiving the 802.11 data packets from the STA, the AP
converts the packets into the 802.3 packets and transmits the packets to the AC through or not
through the tunnel. Then, the packets are forwarded to the network side. During the whole
transmission process, 802.3 packets are scheduled according to the packet or tunnel priority.
In the downstream direction, the AC transmits the 802.3 packets received on the network side
to the AP through or not through the tunnel. When transmitted through the tunnel, packets can
be scheduled according to the tunnel priority on the intermediate network. After receiving the
802.3 packets, the AP converts the packets into the 802.11 packets, selects different AC
queues for packets according to the packet UP priority, and then transmits the packets to the
STA.
Wired access services are managed through a traffic profile. The traffic profile includes the
following parameters: wireless upstream rate limitation on the VAP/client, UP priority
configuration of the 802.11 packets, 802.1p priority configuration of the upstream 802.3

packets, and upstream/downstream tunnel priority configuration. Table 8-5 lists parameters of
the traffic profile.
Table 8-5 Parameters of the traffic profile
rate-limit Limits the upstream packet rate on the STA or the entire VAP.
Configuration of the Configures the inner 802.1p priority of the 802.3 packet
802.3 packet priority transmitted upstream from the AP by adopting a specified value or
performing mapping according to the UP priority of the 802.11
packet transmitted from the STA.
Configuration of the Configures the outer tunnel priority of the 802.3 packet
upstream tunnel transmitted upstream from the AP by adopting a specified value or
priority performing mapping according to the inner priority.
Configuration of the Configures the outer tunnel priority of the 802.3 packet
downstream tunnel transmitted downstream from the AP by adopting a specified value
priority or performing mapping according to the inner priority.
UP priority Configures mapping between the 802.1p priority of the
configuration downstream 802.3 packet and the UP priority of the 802.11
packet.
A traffic profile can be created, modified, deleted, or queried. When a traffic profile is bound
to an extended service set (ESS), the traffic profile cannot be deleted. After a traffic profile is
created, the traffic profile needs to be bound to an ESS and will be applied to the
corresponding VAP of the ESS.
8.5 Applications
The Internet access in airports, meeting rooms, exhibition centers, bars, cafes, or tea houses is
different from the traditional wired access to the Internet in offices. This is because people in
these places need to move around instead of being confined to a fixed place. Therefore, the
need for cheap and quality mobile broadband access services arises in the market. These
broadband access services provide high fidelity and bandwidth for users, and enable users to
roam freely within a specified area. The WLAN thus provides broadband wireless access
services to meet the needs of the market. With the development of WLAN technologies,
operators are able to provide reliable and stable broadband wireless Internet access services.

Figure 8-19 WLAN access solution
Wireless Modem
Wireless Modem
Terminal Access AC CORE
As shown in Figure 8-19, in addition to accessing Multi-service Edge (MSE) users, the ACs,
together with hotspot APs, provide WLAN accesses for users. In this case, the ACs can
manage APs (plug-and-play, RF management, load balancing, and roaming management),
WLAN user access, and AP QoS.
Networking diagram of WLAN applications on a Layer 2 network

When an AP and an AC are connected through a Layer 2 network, user data packets can be
directly forwarded or be forwarded though a channel.
A CAPWAP channel can be set up between the AP and AC to forward data packets. All user
packets are encapsulated in the channel, and both the AP and AC perform encapsulation and
decapsulation.
Figure 8-20 shows the networking scheme of CAPWAP channel access. Users access the BAS
or AC through a configured VE interface rather than a physical interface on the AP. User
packets are encapsulated in the CAPWAP channel and then these user packets can travel the
Layer 2 network without being modified.

Figure 8-20 Networking diagram of the scheme of channel access across the Layer 2 network
AC
GE1/0/1.1 VLAN 2 BAS
VE2/0/2.1 VLAN 1
Layer 2
network
AP
PC Phone
When users directly access the BAS or AC, the access interface is a real physical interface.
User packets are thus forwarded across the Layer 2 network to the AC for processing.

Figure 8-21 Networking diagram of the scheme of direct access across the Layer 2 network
AC AP BAS GE1/0/2.2
STA BAS GE1/0/2.1
Layer 2
network
AP
PC Phone
Networking diagram of WLAN applications on a Layer 3 network

When an AP and an AC are connected through a Layer 3 network, user data packets need to
be forwarded through a control channel. A CAPWAP control channel is then set up between
the AP and AC. As shown in Figure 8-20, all user packets are encapsulated through the
CAPWAP control channel, and both the AP and AC perform encapsulation and decapsulation.
8.6 Impact
8.6.3 Defects

The AC function including AP management is implemented on the MPU. When a large
number of APs are managed and a large number of CAPWAP control channels are set up
between the AC and these APs, CPU performance is affected on the MPU.
Currently, the device supports a maximum number of 4K APs.


When user packets are transmitted through the CAPWAP channel between an AP and an AC,
a VE interface needs to be configured on the AC for user access. On an LPUF-21, only one
Layer 2 VE interface and one Layer 3 VE interface can be configured. When a Layer 3 VE
interface provides access to both the VLL and WLAN for users, different Layer 3 VE
sub-interfaces are used. That is, users cannot access the VLL and WLAN through the same
Layer 3 VE sub-interface.
8.6.3 Defects
Only the EAP-MD5 relay mode, EAP-PEAP relay mode, and EAP-SIM relay mode
rather than local authentication are supported by the RADIUS server.
When user packets are forwarded through a CAPWAP channel, forwarding performance
is halved.
When user packets are forwarded through a CAPWAP channel, a Layer 3 VE
sub-interface is exclusive to WLAN access services and cannot be used to transmit other
access services.

Terms
Term Description
WLAN WLAN refers to a LAN using wireless signaling channels as the
transmission media. Integrating the computer network with wireless
communications technologies, the WLAN technology uses the wireless
multi-address channels as the transmission media and provides traditional
wired LAN functions, enabling users to freely access broadband networks
anytime and anywhere. The launch and authentication of the WLAN
technology is performed by the Wi-Fi (Wireless Fidelity) Alliance, a
standard organization in the industry. Therefore, the WLAN technology is
called Wi-Fi.
EAP relay Defined in IEEE 802.1X, EAP services are encapsulated through another
mode upper-layer protocol such as EAP over RADIUS so that EAP packets can
reach the authentication server across a complicated network. In EAP relay
mode, the RADIUS server must support EAP attributes, EAP-Message (79),
and Message-Authenticator (80).
EAP EAP packets are terminated on an access device and mapped to RADIUS
termination packets. Then authentication and accounting of EAP services are performed
mode through the standard RADIUS protocol. In this manner, standard RADIUS
servers can be used, which secures investments of users.
WLAN WLAN handover enables users's terminals to roam accessibly within a
handover WLAN.

Term Description
Distribution Distribution system (DS) can connect different basic service sets (BSSs). A
system DS uses the medium logically independent of the medium used by a BSS
though the mediums may be physically the same, such as a radio spectrum
band. The DS provides functions required by the WLAN, such as
association, deassociation, reassociation, distribution, and integration.
Station An STA refers to a terminal such as a laptop or a PC with a wireless
(STA) network interface card (NIC).
Access point APs bridge STAs to the wireless local area network (WLAN) and convert
(AP) data frames in the wireless protocol format into data frames in the wired
protocol format and vice versa between STAs and the WLAN.
Access ACs control and manage all APs within a WLAN. ACs also can work with
controller the authentication server to provide authentication service for WLAN users.
(AC)
Wireless Wireless medium is a medium used for transmitting data frames between
medium wireless users. The WLAN uses RF as transmission medium.
CAPWAP CAPWAP is a protocol of control and provisioning of wireless access
points. The protocol defines how APs communicate with ACs and provides
a general encapsulation and transmission mechanism for interoperability
between APs and ACs.
WMM Wi-Fi Multimedia (WMM) is a wireless QoS protocol used for guaranteeing
preferential transmission of packets with a high priority. Through WMM,
applications (such as voice and video) over the wireless network are of good
quality.
EDCA Enhanced distributed channel access (EDCA) is a contention-based channel
access mechanism defined in WMM. This mechanism ensures that packets
with a high priority are provided with more bandwidth and transmitted
preferentially.
Acronyms & Abbreviations

Acronym & Abbreviation Full Spelling
WLAN Wireless Local Area Network
Wi-Fi Wireless Fidelity
CAPWAP Control And Provisioning of Wireless
Access Points Protocol
STA Station
AP Access Point
WTP Wireless Termination Point
AC Access Controller

Acronym & Abbreviation Full Spelling

BSS Basic Service Set
ESS Extended Service Set
EAP Extensible Authentication Protocol
WAPI Wireless LAN Authentication and Privacy
Infrastructure
MFHO Manageable Fast Handover
DS Distribution System
DTLS Datagram Transport Layer Security
LAN Local Area Network
MAN Metropolitan Area Network
WAN Wide Area Network
LWAPP Lightweight access point protocol
WEP Wired equivalent privacy
OPEN-SYS Open system authentication
DCF Distributed coordination function
CSMA/CA Carrier sense multiple access with collision
avoidance
EDCA Enhanced distributed channel access
AIFSN Arbitration inter frame spacing number


CX600 - Feature Description - User Access

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CX600 - Feature Description - User Access

Diunggah oleh

Hak Cipta:

Format Tersedia

HUAWEI CX600 Metro Services Platform

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential

About This Document

Indicates a hazard with a medium or low level of risk,

Issue 01 (2010-06-25) Huawei Proprietary and Confidential iii

Changes in Issue 01 (2010-06-25)

iv Huawei Proprietary and Confidential Issue 01 (2010-06-25)

About This Document ................................................................................................................... iii

Issue 01 (2010-06-25) Huawei Proprietary and Confidential v

2.7 Terms and Abbreviations ............................................................................................................................... 2-7

3 L2TP Access .................................................................................................................................3-1

vi Huawei Proprietary and Confidential Issue 01 (2010-06-25)

5.7.1 On the System Performance ............................................................................................................... 5-16

6 PPPoE Access ..............................................................................................................................6-1

7 802.1x Access ...............................................................................................................................7-1

Issue 01 (2010-06-25) Huawei Proprietary and Confidential vii

8.4.1 AP Management ................................................................................................................................... 8-9

viii Huawei Proprietary and Confidential Issue 01 (2010-06-25)

Figure 1-1 Format of a RADIUS message ......................................................................................................... 1-7

Figure 1-3 Process of command-line authorization in HWTACACS ............................................................... 1-11

Figure 2-1 Operation principle of a DHCP client ............................................................................................... 2-4

Figure 2-2 Operation process of PnP .................................................................................................................. 2-5

Figure 3-1 VPDN model based on L2TP ........................................................................................................... 3-2

Figure 3-2 L2TP protocol structure .................................................................................................................... 3-6

Figure 3-3 Format of an L2TP message header .................................................................................................. 3-6

Figure 3-4 Format of an L2TP data message ...................................................................................................... 3-8

Figure 3-7 Diagram of tearing down an L2TP session connection................................................................... 3-10

Figure 3-9 Networking diagram of an L2TP tunnel ......................................................................................... 3-12

Figure 3-10 Flowchart of establishing an L2TP tunnel call ............................................................................. 3-13

Figure 3-12 Two typical L2TP tunnel modes ................................................................................................... 3-16

Figure 3-13 Users accessing the LAC through a router.................................................................................... 3-17

Figure 3-14 Users accessing the LAC through a router.................................................................................... 3-18

Figure 4-1 Structure of the IPoX protocol stack ................................................................................................. 4-5

Figure 4-3 DHCP packet format ......................................................................................................................... 4-7

Issue 01 (2010-06-25) Huawei Proprietary and Confidential ix

Figure 4-5 Login process through a DHCP packet ........................................................................................... 4-12

Figure 4-7 Remote login of a DHCP user ........................................................................................................ 4-15

Figure 5-1 Principle of ND proxy .................................................................................................................... 5-10

Figure 5-2 Networking diagram of IPv6oE user access ................................................................................... 5-11

Figure 6-1 PPP in the protocol stack .................................................................................................................. 6-2

Figure 6-2 PPPoE negotiation process ............................................................................................................... 6-4

Figure 6-3 LCP negotiation process ................................................................................................................... 6-5

Figure 6-4 PAP authentication process ............................................................................................................... 6-6

Figure 6-5 CHAP authentication process ........................................................................................................... 6-7

Figure 6-6 NCP negotiation process ................................................................................................................... 6-8

Figure 6-7 Access process of a PPP user ............................................................................................................ 6-8

Figure 6-9 Format of a PPP packet ................................................................................................................... 6-12

Figure 6-10 Typical networking model of PPPoE services .............................................................................. 6-16

Figure 6-12 Typical networking model of PPPoEoQ services ......................................................................... 6-17

Figure 6-13 Typical networking model of PPPoA services .............................................................................. 6-17

x Huawei Proprietary and Confidential Issue 01 (2010-06-25)

Figure 6-15 Typical networking of PPPv6 user access ..................................................................................... 6-18

Figure 7-1 Architecture of the 802.1x authentication system ............................................................................. 7-3

Figure 7-6 Typical networking diagram for 802.1x access................................................................................. 7-9

Figure 7-7 Networking diagram for 802.1XoEoV access .................................................................................. 7-9

Figure 7-9 Networking diagram of WLAN access ........................................................................................... 7-10

Figure 8-1 Centralized WLAN architecture ....................................................................................................... 8-3

Figure 8-3 Quick WLAN STA roaming ............................................................................................................. 8-5

Figure 8-4 Flowchart of AC auto-discovery ..................................................................................................... 8-10

Figure 8-5 Topology of the AC and the AP ...................................................................................................... 8-10