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.

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

Copyright © Huawei Technologies Co., Ltd. i

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: [email protected]

HUAWEI CX600 Metro Services Platform Feature Description - User Access About This Document

Issue 01 (2010-06-25) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

iii

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.

About This Document HUAWEI CX600 Metro Services Platform


iv Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Issue 01 (2010-06-25)

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.

HUAWEI CX600 Metro Services Platform Feature Description - User Access Contents


v

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

Contents HUAWEI CX600 Metro Services Platform


vi Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Issue 01 (2010-06-25)

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

HUAWEI CX600 Metro Services Platform Feature Description - User Access Contents


vii



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

Contents HUAWEI CX600 Metro Services Platform


viii Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Issue 01 (2010-06-25)

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


HUAWEI CX600 Metro Services Platform Feature Description - User Access Figures


ix

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

Figures HUAWEI CX600 Metro Services Platform


x Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Issue 01 (2010-06-25)

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 DHCPv6 5-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

HUAWEI CX600 Metro Services Platform Feature Description - User Access Figures


xi

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

HUAWEI CX600 Metro Services Platform Feature Description - User Access Tables


xiii

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

HUAWEI CX600 Metro Services Platform Feature Description - User Access 1 AAA and User Management


1-1

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.

1 AAA and User Management HUAWEI CX600 Metro Services Platform


1-2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

Issue 01 (2010-06-25)

� 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-3

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)




Issue 01 (2010-06-25)

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.



1-5

� 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




Issue 01 (2010-06-25)

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.



1-7

− 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

Code Identifier Length

Authenticator

Attribute

1

2

3

4

5

6

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

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.




Issue 01 (2010-06-25)

� 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 namepassword 2.Request

3.Response

User RADIUS severCX600

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.



1-9

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




Issue 01 (2010-06-25)

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 (TCP) to provide reliable transmission.

Uses UDP.

Encrypts the main structure of a packet except the standard HWTACACS header.

Encrypts only the password field in the authentication packet.

Separates authorization from authentication.

Performs authentication together with authorization.

Is suitable for security control. Is suitable for accounting.

Authorizes the commands executed by administrative users.

Does not authorize the commands executed by 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



1-11

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

User CX600 TACACSServer

1.command 2.author-cmd REQ

3.author-cmd ACK

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.




Issue 01 (2010-06-25)

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 authentication. When a user access the CX600 and is not authenticated, the CX600 does not know the domain of the user, and thus by default considers that the user belongs to default0.

Non-authentication

Non-accounting

default1 It is a domain to which a user belongs during authentication. During authentication, if a user inputs a user account that does not contain a domain name, the CX600 by default considers that the user belongs to default1.

RADIUS authentication

RADIUS accounting

default_admin It is a domain to which an operation user belongs. In the case that an operation user logs in to the CX600 through Telnet or SSH, if the operation user inputs a user account that does not contain a domain name during authentication, the CX600 by default considers that the operation user belongs to default_admin.

RADIUS authentication

Non-accounting

� 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



1-13

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.




Issue 01 (2010-06-25)

− 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.



1-15

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




Issue 01 (2010-06-25)

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

user1@isp1

user2@isp2

user3@isp3

CX600

RADIUS(master)

RADIUS(backup)

Internet

129.7.66.67129.7.66.66

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



1-17

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

user1@isp1

user2@isp2

user3@isp3

CX600

HWTACACS(master)

HWTACACS(backup)

Internet

130.7.66.67130.7.66.66

Bill sever10.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




Issue 01 (2010-06-25)


HWTACACS HUAWEI Terminal Access Controller Access Control System

HUAWEI CX600 Metro Services Platform Feature Description - User Access 2 Plug-and-Play


2-1

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 HUAWEI CX600 Metro Services Platform



Issue 01 (2010-06-25)

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

Involved Network Element � 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.



2-3

� 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.




Issue 01 (2010-06-25)

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.



2-5

Figure 2-2 Operation process of PnP

NMS (DHCPServer)

DHCP RelayUPE(DHCP

Client)

8. Reply withDHCP ACK.

IP/MPLS

5. Send Request

4. Reply withDHCP Offer

1. Send Discover

7. Reply with a DHCP ACK, whichcarries allocated address

6.Insert Option 82 andforward DHCP Offer

3. Reply withDHCP Offer

2. Insert Option 82 andforward Discover

10.The NMS sends configuration and start fi les to UPE anddeliver restart conmand.

11. The device is usable afterrestart

9.UPE obtains IP address and startsdefault management

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.




Issue 01 (2010-06-25)

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

IP/MPLS

DHCP Client DHCP Relay

NMS

DHCP Server

UPE PE-AGG

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-7

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

HUAWEI CX600 Metro Services Platform Feature Description - User Access 3 L2TP Access


3-1

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 HUAWEI CX600 Metro Services Platform



Issue 01 (2010-06-25)

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

L2TP tunnel

LAC LNSRemotesubscriber

Internalserver

Remotebranch

NAS

PSTN/ISDN

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



3-3

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.




Issue 01 (2010-06-25)

� 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-l2tpext-tunnel-switching-07

PPP over L2TP Tunnel Switching



3-5

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




Issue 01 (2010-06-25)

3.5.2 L2TP Header

3.5.1 L2TP Protocol Structure

Figure 3-2 L2TP protocol structure

Packet transmission network (UDP, ...)

L2TP control messageL2TP data message

PPP frame

L2TP data channel (unreliable) L2TP control channel (reliable)

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

T L x x S x O P x x x x Ver Length (opt)Tunnel ID Session IDNs (opt) Nr (opt)

offset size (opt) offset padding (opt)

0 7 12 16 31

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: � 0: indicates a data message. � 1: indicates a control message.

The value must be 1 in a control message.



3-7

Field Meaning Remarks

L Indicates the Length bit. The value 1 indicates that a message header contains the Length field.


x Indicates a reserved bit. -

S Indicates the Sequence bit. The value 1 indicates that a message header contains the Ns field and the Nr field.


O Indicates the Offset size bit. The value 1 indicates that a message header contains the Offset size field.


P Indicates the priority. This field exists only in a data message.


Ver Indicates the version number of the L2TP protocol.

The value is 2 if L2TPv2 is enabled.

Length Indicates the total length of a message, in bytes.

-

Tunnel ID Indicates the tunnel ID, which is only locally valid.

The value must be 0 in a Hello 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 next message expected to be received.

It is a reserved field in data messages.

offset size Indicates the origin position of the payload.

-

offset padding

Indicates the padding bit. -

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




Issue 01 (2010-06-25)

� 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 8 16 2 20

New IPheader

UDP header L2TP header PPPheader

Originalheader

Data

bytes bytes bytes bytes bytes

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.



3-9

� 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 LNSSCCRQ

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




Issue 01 (2010-06-25)

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

ICRQ

ICRP

ICCN

ZLB ACK

Call Detected

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



3-11

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.




Issue 01 (2010-06-25)

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

PC HeadquarterLNSCX-C

LACCX-A

RADIUSServer

LNS' LAC'CX-B(LTS)

WAN

Tunnel1

WAN

Tunnel2

PSTN/ISDN

IPNetwork

RADIUSServer

RADIUSServer

IPNetwork

IPNetwork

Figure 3-10 shows the flowchart of establishing an L2TP call for tunnel authentication.



3-13

Figure 3-10 Flowchart of establishing an L2TP tunnel call

LAC LNS

(1) call setup

(2) PPP LCP setup

(3) PAP or CHAPauthentication

(4) access request

(5) access accept

(6) tunnel establish

(7) PAP or CHAP authentication(challenge/response)

(8) authentication passes

(9) user CHAP response, PPPnegotiation parameter (10) access request

(11) access accept(12) CHAP authentication twice(challenge/response)

(13) access request

(14) access accept(15) authentication passes

PCRADIUSServer

LNS

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.




Issue 01 (2010-06-25)

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:



3-15

− 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

PC HeadquarterLNSCX-C

LACCX-A

RADIUSServer

LNS' LAC'CX-B(LTS)

WAN

Tunnel1

WAN

Tunnel2

PSTN/ISDN

IPNetwork

RADIUSServer

RADIUSServer

IPNetwork

IPNetwork

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




Issue 01 (2010-06-25)

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

Remotesystem

LAC

LAC

LNS

LAC client

LNSInternal server

PSTN/ISDN

Internet

wan

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.



3-17

− 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

LAC LNSInternet

Internalserver

LANSwitch

Router

user

user

user

PPP/PPPoE

l2tp tunnel

� 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




Issue 01 (2010-06-25)

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

PC1

PC2

WAN

LAC LNS

accessnetwork

accessnetwork

Headquarter02

Headquarter01user1@isp1

user1@isp2

isp1

isp2

L2TP Tunnel

L2TP Tunnel

CX-ACX-B

vrf1

vrf2

� 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



3-19

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

accessnetwork

PPPoX

IPV6

IPV4

IPV4/IPV6

L2TP Tunnel(IPv4)

LAC LNS

IPv4network

IPv6network

DNSServer

AAAServer

DNSServer

AAAServer

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.




Issue 01 (2010-06-25)


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

HUAWEI CX600 Metro Services Platform Feature Description - User Access 4 IPoEv4


4-1

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 HUAWEI CX600 Metro Services Platform



Issue 01 (2010-06-25)

4.2 References The following table lists the references of this document.


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-3

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




Issue 01 (2010-06-25)

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.



4-5

Figure 4-1 Structure of the IPoX protocol stack

TCP/UDP

IP

IPoE

ETH

TCP/UDP

IP

QETH

IPoEoVLAN IPoEoQ IPoEoA

AAL5

TCP/UDP

IP

QETH Q

TCP/UDP

IP

ETH

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

DHCPClient

DHCPRelay

DHCPServer

1. DHCP Discover (broadcast)

3.DHCP Request (broadcast)

Obtain IPaddress

Extend addresslease

4.DHCP ACK

1.DHCP Discover (unicast)

2.DHCP Offer2.DHCP Offer

3. DHCP Request (unicast)

4.DHCP ACK

5. DHCP Request (unicast)

6.DHCP ACK7.DHCP Request( broadcast)

8.DHCP ACK7.DHCP Request(unicast)

8.DHCP ACK

1/2 of lease

3/4 of lease

� The DHCP client communicates with the DHCP server in any of three modes.




Issue 01 (2010-06-25)

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.



4-7

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."




Issue 01 (2010-06-25)

� 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.



4-9

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




Issue 01 (2010-06-25)

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



4-11

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.




Issue 01 (2010-06-25)

Figure 4-4 Networking diagram of local address allocation for Layer 2 access users

IPv4 user

IPv4 user

IPv4 user

VLAN1001

VLAN1002

VLAN1003

LSW BRAS

WEBServer

AAA ServerDNS Server

IPv4network

DHCP/IP/ARP

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

Client BRASAAA

Server

DHCP Discover

DHCP Request

User goesonline

Authentication requestAuthentication response

DHCP Offer

DHCP ACK

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



4-13

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




Issue 01 (2010-06-25)

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

IPv4 user

IPv4 user

IPv4 user

VLAN1001

VLAN1002

VLAN1003

LSW BRAS

DHCPServer

WEBServer

AAA ServerDNS Server

IPv4network

DHCP/IP/ARP

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.



4-15

Figure 4-7 Remote login of a DHCP user

Client BRASAAA

Server

DHCP Discover

DHCP Request

User goesonline

Authenticationrequest

Authenticationreply

DHCP Offer

DHCP ACK

DHCP DiscoverDHCP Offer

DHCP Request

DHCP ACK

DHCPServer

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

user LSW BRAS

WEB Server

RADIUS Server

Internet

Router




Issue 01 (2010-06-25)

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

IPv4 user

IPv4 user

IPv4 userRouter

WEBServer

AAA Server

BRAS

Layer2network

Internet

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



4-17

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

Internet

BRAS

LSW

subscriber DSLAM

subscriber

� 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

Internet

BRAS

Router

subscriberATM

Switch

subscriber

Accessnetwork

Accessnetwork

� 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




Issue 01 (2010-06-25)

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

VPN

DNS server RADIUS server

BRAS

Internet

LANSwitch

VLAN1

VLAN2

VLAN100

......

Router

4.7 Impact 4.7.1 Impact on the System Performance


4.7.3 Defects


None.


None.

4.7.3 Defects

None.



4-19


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-1

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.




Issue 01 (2010-06-25)

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 The following table lists the references of this document.


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.



5-3

Version Support

Product Version

CX600 V600R002

Feature Dependency

None.

Hardware Support

Board Supporting IPoEv6 Access

Board Supporting Access of IPv4/IPv6 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.




Issue 01 (2010-06-25)

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.



5-5

− 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.




Issue 01 (2010-06-25)

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.



5-7

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




Issue 01 (2010-06-25)

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



5-9

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.




Issue 01 (2010-06-25)

Figure 5-1 Principle of ND proxy

PC11234: : 1/ 64

PC21234: : 2/ 64

NS ( r eqest s f or t he 1234: : 2/64 MAC addr ess)

I nt er f aceA I nt er f ace B

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)

Needs t o send PC2 dat apacket s

Dat a packet s dest i ned f or1234: : 2/ 64

Dat a packet s dest i ned f or1234: : 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

1234: : 1/ 64Dat a packet s dest i ned f or

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.



5-11

Figure 5-2 Networking diagram of IPv6oE user access

BRAS

IPv4BackboneNetwork

IPv6

Radius

IPv4Web Server

IPv4/v6

IPv6

Layer 2Network

Layer 3Network

IPv4/IPv6

IPv4/IPv6

IPv6BackboneNetwork

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

IPv6 PCBRASIPv6

DSLAM Radius

InterfaceM=0

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




Issue 01 (2010-06-25)

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

IPv6/IPv4 PC BRASIPv6/IPv4

DSLAM

Radius

IPv4 WebSever

InterfaceM=0

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.



5-13

Figure 5-5 Networking diagram for access of a Layer 2 IPv6 user running DHCPv6

IPv6 PCBRASIPv6

DSLAM Radius

InterfaceM=1

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

IPv6/IPv4 PC BRASIPv6/IPv4

DSLAM

Radius

IPv4 WebSever

InterfaceM=1

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.




Issue 01 (2010-06-25)

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

IPv6 PC BRASIPv6

CX600 Radius

InterfaceM=1

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

IPv6 PC

IPv6 PC

HG DSLAM BRASIPv6

Radius

DHCPv6-PDND(DHCPv6)

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



5-15

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

IPv4/IPv6PC

IPv4/IPv6PC

HG DSLAM BRASIPv6

Radius

DHCPv4/DHCPv6-PDDHCPv4/

ND(DHCPv6)

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.




Issue 01 (2010-06-25)

Figure 5-10 Schematic diagram of communication between users with the same prefix through the BRAS

IPv6 PC1

DSLAMBRASIPv6

IPv6 PC2

ND Pr oxyEnabl ed

VLAN2

VLAN1

1234::2/64

1234::1/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



5-17

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

HUAWEI CX600 Metro Services Platform Feature Description - User Access 6 PPPoE Access


6-1

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 HUAWEI CX600 Metro Services Platform



Issue 01 (2010-06-25)

Figure 6-1 PPP in the protocol stack

IP

SNMP TELNET FTP RADIUS

SOCKET

UDPICMP

ARPPPP

Physical Layer

TCP

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.



6-3

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.




Issue 01 (2010-06-25)

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

2.PADO

1.PADI

3.PADR

4.PADS

PPPoEnegotiation

User CX

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.



6-5

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

LCPnegotiation

Config-req

Config-ack

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.




Issue 01 (2010-06-25)

� 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

PPPauthentication

Auth-req

Auth-ack

Radius

Auth-req

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



6-7

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

PPPauthentication

Challenge(CHAP)

Auth-ack

Radius

Auth-req

Auth-ack

Auth-req

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:




Issue 01 (2010-06-25)

Figure 6-6 NCP negotiation process

Client Server

NCPnegotiation

Parmeter-req

Parmeter-ack

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

2.PADO

1.PADI

3.PADR

4.PADS

5.LCP negotiation£¨CHAPauthentication£©

6.Challenge

7.Response

8.Access Request

9.Access Accept/Reject

10.Success/Failure

11 NCP negotiation

PPPoEnegotiation

PPPnegotiation

User logsin

User AAA ServerCX



6-9

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.




Issue 01 (2010-06-25)

� 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.



6-11

State Transition

Figure 6-8 State transition

Dead Establish Authenticate

Terminate Network

Up

Down

Success/None

Opened

FailFail

Closing

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




Issue 01 (2010-06-25)

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

Fl ag01111110

Addr ess11111111

Cont r ol00000011 I nf or mat i on FCS

16bi t sFormat of

a PPPpacket

Pr ot ocol8/ 16bi t s

Fl ag01111110

Code8bi t s

I dent i f i er8bi t s

Lengt h16bi t s

Dat a......

Type8bi t s

Lengt h8bi t s

Dat a......

Type8bi t s

Lengt h8bi t s

Dat a......

.........

Format of an LCPpacket

Format of LCPconfigurationparameters

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.



6-13

� 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.




Issue 01 (2010-06-25)

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.



6-15

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)




Issue 01 (2010-06-25)

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

CXsubscriber Lanswitch

I nt er net

Eth PPPoE IP Data Eth PPPoE PPP IP Data

� 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

QEth

subscriber LAN Switch CX

Internet

PPPoE PPP IP Data Eth PPPoE PPP IP Data

� 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.



6-17

Figure 6-12 Typical networking model of PPPoEoQ services

subscriber LAN Switch CX

Internet

LAN Switch

PPPoEPPP

Eth

IP Data

PPPoEPPP

Eth

IP Data

QPPPoE

PPP

Eth

IP Data

Q Q

� 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

PC CX

Internet

ADSL Modem DSLAM

AAL5 PPP IP Data AAL5 PPP IP Data

� 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.




Issue 01 (2010-06-25)

Figure 6-14 Typical networking model of PPPoEoA services

PC CX

Internet

ADSLModem

DSLAM

PPPoE PPP IP Data AAL5Eth PPPoEPPP IP DataEth

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

subscriber@isp5

CX

Internetaccessnetwork

DNS server3001:0410::1:2

RADIUS server3001:0410::1:1

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



6-19


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

HUAWEI CX600 Metro Services Platform Feature Description - User Access 7 802.1x Access


7-1

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 HUAWEI CX600 Metro Services Platform



Issue 01 (2010-06-25)

7.2 References

Document Name

Description Remarks

RFC 2284 PPP Extensible Authentication Protocol (EAP) -

RFC 3748 Extensible Authentication Protocol (EAP) -

IEEE Std 802.1X-2001

IEEE Standard for Local and Metropolitan Area 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-3

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

Client

Client PAE

Device

Unauthenticatedinterface

Controledinterface

Non-controlledinterface

Authentication server

Authentication server

Device PAEDevice-provided

service

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.




Issue 01 (2010-06-25)

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

Client PAEDevicePAE

Authenticationserver

EAPOL

RADIUS-bearingEAP/PAP/CHAP packet

exchange

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.



7-5

� 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.




Issue 01 (2010-06-25)

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

Cl i ent PAEDevice

PAERADIUS server

EAPoL-Start

EAP-Response/Identity

EAP-Response/MD5 Challenge

EAP-Request/Identity

RADIUS Access-Accept(EAP-Success)

Handshaketimer times out

Handshaker equest[ EAP- Request / I dent i t y]

Handshakereply

[ EAP- Response/ I dent i t y]. . . . . .

EAPoL- Logof f

Interfaceauthorized

Interfaceunauthorized

EAPoL RADIUS

EAP-Request/MD5 Challenge

RADIUS Access-Request(EAP-Response/MD5 Challenge)

EAP-Success

(EAP-Response/MD5 Challenge)RADIUS Access-Request

RADIUS Access-Chanllenge(EAP-Request/MD5 Challenge)

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.



7-7

Figure 7-4 Basic process of the IEEE 802.1x authentication system (2)

Client PAE Device PAE RADIUS server

EAPoL-Start

EAP-Response/Identity

EAP-Response/MD5 Challenge

EAP-Request/Identity

RADIUS Access-Accept(EAP-Success)

Handshake timertimes out

Handshake request[EAP-Request/Identity]

Handshake reply[EAP-Response/Identity]

EAPoL-Logoff

Interface authorized

Interface unauthorized

EAPoL RADIUS

EAP-Request/MD5 Challenge

RADIUS Access-Request(EAP-Response/MD5 Challenge)

EAP-Success

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.




Issue 01 (2010-06-25)

Figure 7-5 Basic process of IEEE 802.1x EAP-PEAP authentication

Terminal AP BRAS

1.broadcast probe

2.reply to probe

4.association request 5.association message

6.association succeeds7. association succeeds

8.EAPOL-start

Association

.

Useraddress

application

User dataforwarding

3.802.11AUTH

Search forAP

9.EAP-request/Identity

802.1X EAPauthenticatio

n

802.11i keygenerated

11.Radius-Access-Request

12.Radius-Access-Challenge

10.EAP-response/Identity

13.EAP-request/Identity

14.EAP-response/Identity15.Radius-Access-

Request

16.Radius-Access-Accept

17.BRAS saves PMK andsends EAP-success

18.EAPOL-nonce

19.calculate PTK and send to AC

20.Check the PTK and deliver the GTK

21.Key is usable

22.KEY delivered

23.DHCP Discover,apply for address

24.DHCP Offer,address al location

25.DHCP Request,address acknowledged

26.DHCP ACK

27. Terminal dataforwarding

AAA Server

AP interface usable

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



7-9

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 BRASSwitch

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 BRASSwitchSwitch

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




Issue 01 (2010-06-25)

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 BRASSwitchAP

7.7 Impact 7.7.1 Impact on the System Performance


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.



7-11


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

HUAWEI CX600 Metro Services Platform Feature Description - User Access 8 WLAN


8-1

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 HUAWEI CX600 Metro Services Platform



Issue 01 (2010-06-25)

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.



8-3

Figure 8-1 Centralized WLAN architecture

WTP

WTP

WTP Switch AC

IPNtetword

CommnmicationProtocol

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




Issue 01 (2010-06-25)

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 RFenvironment information in realtime according to policies providedby the AC.

Data analysis: The AC analyzesand assesses data collected bythe APs.

Decision making: According to theanalysis result, the AC assignschannels and transmit power.

Decision execution: APs executeconfigurations set by the AC andadjust RF resources.

� 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



8-5

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

Roam

AP2AP1

AC

STASTA

ESS

ESS: extended service setSTA: 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.




Issue 01 (2010-06-25)

− 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



8-7

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




Issue 01 (2010-06-25)

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



8-9

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.




Issue 01 (2010-06-25)

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

Any pre-configured staticAC IP address list?

AP associateswith the AC with

specified IPaddress

AP enables thedynamic AC

discoverymechanism

AP associateswith AC

Y N

Start

EndEnd

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

Switch

AP

DHCP/DNSserver

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:



8-11

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 obtains IPaddress and DHCPserver domain name

DHCP serverAP AC

AP sends discovery request

Switch sends discovery response

AP downloads version

AP downloads configuration

AP and AC transfer user data

1

2

3

4

5

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.




Issue 01 (2010-06-25)

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 obtains IPaddress and DHCP& DNS serverdomain names

DHCP serverAP AC

Switch sends discovery response

AP downloads version

AP downloads configuration

AP and AC transfer user data

1

2

3

4

5

6

DNS server

AP sends discovery request

AP does not receive a response over along time

AP obtains IP address of switch

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:



8-13

− 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




Issue 01 (2010-06-25)

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.



8-15

Figure 8-8 Channel forwarding mode

APPC

L2/L3Network

AC/BAS

CAPWAP tunnel

User packet

� 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

APPC

L2 Network

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.




Issue 01 (2010-06-25)

Figure 8-10 Principle of CAPWAP

Discover AC

Set up DTLS

Join AC

Downloadconfiguration

Operation

Restart

Upgrade thefirmware

PreviousVersion

Yes

No

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



8-17

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.




Issue 01 (2010-06-25)

Figure 8-11 Power decrease

AP4

Channel 1

Channel 11Channel 6

AC

AP1

AP3

AP2

Switch

AC

AP1

AP3

AP2

Switch

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.

� 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.



8-19

Figure 8-12 Power increase

When AP4 goes offline, the power of each of the other three APs is increased to guarantee the wireless coverage.

Channel 1

Channel 11Channel 6

AC

AP1

AP3

AP2

Switch Switch

AP4

AC

AP1

AP3

AP2

Switch

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.




Issue 01 (2010-06-25)

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 period

Controls the aging timeout period of users associated with the 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.



8-21


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.




Issue 01 (2010-06-25)

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.



8-23

Figure 8-13 4-way handshake during the AC's processing quick roaming

Roam request

AP AC

Roam response

Request of associating with anew AP

Response to the request ofassociating 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.




Issue 01 (2010-06-25)

Figure 8-14 Fast roaming by a STA within a same AC

Roam

AP2AP1

SSID: Huawei

AC

SSID: Huawei

SSID: service set identifier

(2)

Deassociate between STA and AP1

Set up association between STA and AP2

Channel 6Channel 1

(3)

(3)

(2)

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.



8-25

� 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

Authentication response

Authentication request

STA AP

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




Issue 01 (2010-06-25)

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

Successful authenticationresponse

Cipher text with "challengetext" encrypted

Randomly generate a"challenge text"

Authentication request

STA AP

PSK PSK

Use the key toencrypt the plaintext

Compare thedecrypted cipher textwith the plain text

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



8-27

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




Issue 01 (2010-06-25)

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.



8-29

Figure 8-17 Process of WAPI authentication and encryption

Unicast key confirmation

AS server

Access network resources(link encryption)

Multicast key response

Multicast key notification

Unicast Key negotiation response

Certificateauthentication response

Certificateauthentication request

Unicast Key negotiation request

Access authentication response

Access authentication request

Authentication activation

STA AP AC

Identity authentication processC

omm

unication

process

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.




Issue 01 (2010-06-25)

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.



8-31

Figure 8-18 Process of 802.1x authentication based on EAP-TLS

Check PMKconsistency, andgenerate other keys

Check PMK consistency,and generate other keys

Authentication success PMK is generated

Encrypt data packet

4-way handshake key negotiation

STA certificate (master key encryptedby the public key)

User identification

Authentication success

Server certificate (public key)

EAP response to user indentification

EAP request for user identification

EAP start

Associate

OPEN-SYMauthentication

STA AC

Verify the servercertificate, and use thepublic key to encryptthe master key togenerate PMK

APRADIUS server

Verify the STA certificate, anduse the private key to decrypt themaster key to generate PMK

Server certificate (public key)

STA certificate (master keyencrypted by the public key)

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.




Issue 01 (2010-06-25)

� 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 switch

Determines whether an STA that does not support the WMM 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



8-33

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 802.3 packet priority

Configures the inner 802.1p priority of the 802.3 packet 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 upstream tunnel priority

Configures the outer tunnel priority of the 802.3 packet transmitted upstream from the AP by adopting a specified value or performing mapping according to the inner priority.

Configuration of the downstream tunnel priority

Configures the outer tunnel priority of the 802.3 packet transmitted downstream from the AP by adopting a specified value or performing mapping according to the inner priority.

UP priority configuration

Configures mapping between the 802.1p priority of the 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.




Issue 01 (2010-06-25)

Figure 8-19 WLAN access solution

Terminal Access AC CORE

Wireless Modem

Wireless Modem

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.



8-35

Figure 8-20 Networking diagram of the scheme of channel access across the Layer 2 network

BASVE2/0/2.1 VLAN 1

GE1/0/1.1 VLAN 2

AP

AC

PC Phone

Layer 2network

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.




Issue 01 (2010-06-25)

Figure 8-21 Networking diagram of the scheme of direct access across the Layer 2 network

AP

ACSTA BAS GE1/0/2.1

AP BAS GE1/0/2.2

PC Phone

Layer 2network

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.1 On the System Performance


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.



8-37


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 mode

Defined in IEEE 802.1X, EAP services are encapsulated through another 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 termination mode

EAP packets are terminated on an access device and mapped to RADIUS packets. Then authentication and accounting of EAP services are performed through the standard RADIUS protocol. In this manner, standard RADIUS servers can be used, which secures investments of users.

WLAN handover

WLAN handover enables users's terminals to roam accessibly within a WLAN.




Issue 01 (2010-06-25)

Term Description

Distribution system

Distribution system (DS) can connect different basic service sets (BSSs). A 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 (STA)

An STA refers to a terminal such as a laptop or a PC with a wireless network interface card (NIC).

Access point (AP)

APs bridge STAs to the wireless local area network (WLAN) and convert data frames in the wireless protocol format into data frames in the wired protocol format and vice versa between STAs and the WLAN.

Access controller (AC)

ACs control and manage all APs within a WLAN. ACs also can work with the authentication server to provide authentication service for WLAN users.

Wireless medium

Wireless medium is a medium used for transmitting data frames between 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



8-39

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

Documents

CX600 - Feature Description - User Access