Professional Documents
Culture Documents
CX600 Feature Description User Access
CX600 Feature Description User Access
Feature Access
Issue Date 01 2010-06-25
Description
User
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.
Issue 01 (2010-06-25)
Symbol Conventions
The symbols that may be found in this document are defined as follows. Symbol Description Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
Issue 01 (2010-06-25)
iii
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues. None.
iv
Issue 01 (2010-06-25)
Contents
Contents
About This Document ................................................................................................................... iii 1 AAA and User Management ....................................................................................................1-1
1.1 Introduction to AAA and User Management ................................................................................................. 1-1 1.2 References ..................................................................................................................................................... 1-3 1.3 Availability .................................................................................................................................................... 1-4 1.4 Enhancement ................................................................................................................................................. 1-4 1.5 Principles ....................................................................................................................................................... 1-4 1.5.1 AAA ..................................................................................................................................................... 1-4 1.5.2 RADIUS............................................................................................................................................... 1-7 1.5.3 HWTACACS ..................................................................................................................................... 1-10 1.5.4 User management ............................................................................................................................... 1-11 1.6 Applications................................................................................................................................................. 1-16 1.6.1 RADIUS Authentication and Accounting .......................................................................................... 1-16 1.6.2 HWTACACS Authentication, Accounting, and Authorization .......................................................... 1-16 1.7 Impact.......................................................................................................................................................... 1-17 1.7.1 On the System Performance ............................................................................................................... 1-17 1.7.2 On Other Features .............................................................................................................................. 1-17 1.7.3 Defects ............................................................................................................................................... 1-17 1.8 Terms and Abbreviations ............................................................................................................................. 1-17
2 Plug-and-Play ..............................................................................................................................2-1
2.1 Introduction to Plug-and-Play ....................................................................................................................... 2-1 2.2 References ..................................................................................................................................................... 2-2 2.3 Availability .................................................................................................................................................... 2-2 2.4 Principles ....................................................................................................................................................... 2-2 2.4.1 Principle of DHCP ............................................................................................................................... 2-2 2.4.2 Operation Principle of a DHCP Client ................................................................................................. 2-3 2.4.3 Operation Process of PnP ..................................................................................................................... 2-4 2.5 Applications................................................................................................................................................... 2-6 2.6 Impact............................................................................................................................................................ 2-6 2.6.1 Impact on the System Performance ...................................................................................................... 2-6 2.6.2 Impact on Other Features ..................................................................................................................... 2-6 2.6.3 Defects ................................................................................................................................................. 2-7
Issue 01 (2010-06-25)
Contents
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 4.8 Terms and Abbreviations ............................................................................................................................. 4-19
5 IPoEv6 ...........................................................................................................................................5-1
5.1 Introduction to IPoEv6 .................................................................................................................................. 5-1 5.2 References ..................................................................................................................................................... 5-2 5.3 Availability .................................................................................................................................................... 5-2 5.4 Enhancement ................................................................................................................................................. 5-3 5.5 Principles ....................................................................................................................................................... 5-3 5.5.1 Principles of Stateless Address Autoconfiguration............................................................................... 5-3 5.5.2 Principles of DHCPv6 Access .............................................................................................................. 5-4 5.5.3 Principles of IPoEv6 Access ................................................................................................................ 5-8 5.5.4 ND Proxy ............................................................................................................................................. 5-9 5.6 Applications................................................................................................................................................. 5-10 5.7 Impact.......................................................................................................................................................... 5-16 vi Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-06-25)
Contents
5.7.1 On the System Performance ............................................................................................................... 5-16 5.7.2 On Other Features .............................................................................................................................. 5-16 5.7.3 Defects ............................................................................................................................................... 5-16 5.8 Terms and Abbreviations ............................................................................................................................. 5-16
8 WLAN ...........................................................................................................................................8-1
8.1 Introduction to WLAN .................................................................................................................................. 8-1 8.2 References ..................................................................................................................................................... 8-7 8.3 Availability .................................................................................................................................................... 8-8 8.4 Principles ....................................................................................................................................................... 8-9
Issue 01 (2010-06-25)
vii
Contents
HUAWEI CX600 Metro Services Platform Feature Description - User Access 8.4.1 AP Management ................................................................................................................................... 8-9 8.4.2 RF Management ................................................................................................................................. 8-16 8.4.3 Service Set Management (ESS Profile) ............................................................................................. 8-20 8.4.4 Configuration Auto-Provisioning Management ................................................................................. 8-21 8.4.5 Centralized BSSID Management ....................................................................................................... 8-21 8.4.6 Load Balancing .................................................................................................................................. 8-22 8.4.7 WLAN STA Roaming ........................................................................................................................ 8-22 8.4.8 WLAN Access Security ..................................................................................................................... 8-25 8.4.9 QoS .................................................................................................................................................... 8-31
8.5 Applications................................................................................................................................................. 8-33 8.6 Impact.......................................................................................................................................................... 8-36 8.6.1 On the System Performance ............................................................................................................... 8-36 8.6.2 On Other Features .............................................................................................................................. 8-37 8.6.3 Defects ............................................................................................................................................... 8-37 8.7 Terms and Abbreviations ............................................................................................................................. 8-37
viii
Issue 01 (2010-06-25)
Figures
Figures
Figure 1-1 Format of a RADIUS message ......................................................................................................... 1-7 Figure 1-2 Process of exchanging RADIUS messages between the RADIUS server and client........................ 1-8 Figure 1-3 Process of command-line authorization in HWTACACS ............................................................... 1-11 Figure 1-4 Network diagram of RADIUS authentication and accounting........................................................ 1-16 Figure 1-5 Networking diagram of HWTACACS authentication, accounting, and authorization ................... 1-17 Figure 2-1 Operation principle of a DHCP client ............................................................................................... 2-4 Figure 2-2 Operation process of PnP .................................................................................................................. 2-5 Figure 2-3 Network diagram of obtaining a management IP address and starting a management channel ........ 2-6 Figure 3-1 VPDN model based on L2TP ........................................................................................................... 3-2 Figure 3-2 L2TP protocol structure .................................................................................................................... 3-6 Figure 3-3 Format of an L2TP message header .................................................................................................. 3-6 Figure 3-4 Format of an L2TP data message ...................................................................................................... 3-8 Figure 3-5 Diagram of the three-way handshake during the establishment of a control connection .................. 3-9 Figure 3-6 Diagram of the process of establishing a session connection ......................................................... 3-10 Figure 3-7 Diagram of tearing down an L2TP session connection................................................................... 3-10 Figure 3-8 Diagram of tearing down an L2TP control connection ................................................................... 3-11 Figure 3-9 Networking diagram of an L2TP tunnel ......................................................................................... 3-12 Figure 3-10 Flowchart of establishing an L2TP tunnel call ............................................................................. 3-13 Figure 3-11 Networking diagram of L2TP tunnel switching ............................................................................ 3-15 Figure 3-12 Two typical L2TP tunnel modes ................................................................................................... 3-16 Figure 3-13 Users accessing the LAC through a router.................................................................................... 3-17 Figure 3-14 Users accessing the LAC through a router.................................................................................... 3-18 Figure 3-15 Application of IPv6 network access through L2TP on the carrier's network ................................ 3-19 Figure 4-1 Structure of the IPoX protocol stack ................................................................................................. 4-5 Figure 4-2 DHCP packet exchange .................................................................................................................... 4-5 Figure 4-3 DHCP packet format ......................................................................................................................... 4-7
Issue 01 (2010-06-25)
ix
Figures
Figure 4-4 Networking diagram of local address allocation for Layer 2 access users ..................................... 4-12 Figure 4-5 Login process through a DHCP packet ........................................................................................... 4-12 Figure 4-6 Networking diagram of remote address allocation for a Layer 2 access user ................................. 4-14 Figure 4-7 Remote login of a DHCP user ........................................................................................................ 4-15 Figure 4-8 Networking diagram of Layer 3 access users adopting Web authentication ................................... 4-15 Figure 4-9 Networking diagram of Layer 3 DHCP users ................................................................................. 4-16 Figure 4-10 Networking diagram of Layer 2 leased line access ....................................................................... 4-17 Figure 4-11 Networking diagram of Layer 3 leased line access ....................................................................... 4-17 Figure 4-12 Networking diagram of Layer 2 VPN leased line access .............................................................. 4-18 Figure 5-1 Principle of ND proxy .................................................................................................................... 5-10 Figure 5-2 Networking diagram of IPv6oE user access ................................................................................... 5-11 Figure 5-3 Networking diagram for access of a Layer 2 IPv6 user running ND .............................................. 5-11 Figure 5-4 Networking diagram for access of an IPv4/IPv6 dual-stack user running DHCPv4 and ND ......... 5-12 Figure 5-5 Networking diagram for access of a Layer 2 IPv6 user running DHCPv6 ..................................... 5-13 Figure 5-6 Networking diagram for access of an IPv4/IPv6 dual-stack User running DHCPv4 and DHCPv65-13 Figure 5-7 Networking diagram for access of a Layer 3 IPv6 User Running DHCPv6 ................................... 5-14 Figure 5-8 Networking diagram for access of Layer 2 IPv6 users through a routed HG ................................. 5-14 Figure 5-9 Networking diagram for access of Layer 2 IPv4/IPv6 dual-stack users through a routed HG ....... 5-15 Figure 5-10 Schematic diagram of communication between users with the same prefix through the BRAS .. 5-16 Figure 6-1 PPP in the protocol stack .................................................................................................................. 6-2 Figure 6-2 PPPoE negotiation process ............................................................................................................... 6-4 Figure 6-3 LCP negotiation process ................................................................................................................... 6-5 Figure 6-4 PAP authentication process ............................................................................................................... 6-6 Figure 6-5 CHAP authentication process ........................................................................................................... 6-7 Figure 6-6 NCP negotiation process ................................................................................................................... 6-8 Figure 6-7 Access process of a PPP user ............................................................................................................ 6-8 Figure 6-8 State transition ................................................................................................................................ 6-11 Figure 6-9 Format of a PPP packet ................................................................................................................... 6-12 Figure 6-10 Typical networking model of PPPoE services .............................................................................. 6-16 Figure 6-11 Typical networking model of PPPoEoV services .......................................................................... 6-16 Figure 6-12 Typical networking model of PPPoEoQ services ......................................................................... 6-17 Figure 6-13 Typical networking model of PPPoA services .............................................................................. 6-17 Figure 6-14 Typical networking model of PPPoEoA services .......................................................................... 6-18
Issue 01 (2010-06-25)
Figures
Figure 6-15 Typical networking of PPPv6 user access ..................................................................................... 6-18 Figure 7-1 Architecture of the 802.1x authentication system ............................................................................. 7-3 Figure 7-2 Protocol structure of the 802.1x authentication system .................................................................... 7-4 Figure 7-3 Basic process of the IEEE 802.1x authentication system (1) ............................................................ 7-6 Figure 7-4 Basic process of the IEEE 802.1x authentication system (2) ............................................................ 7-7 Figure 7-5 Basic process of IEEE 802.1x EAP-PEAP authentication ................................................................ 7-8 Figure 7-6 Typical networking diagram for 802.1x access................................................................................. 7-9 Figure 7-7 Networking diagram for 802.1XoEoV access .................................................................................. 7-9 Figure 7-8 Networking diagram for 802.1XoEoQ access .................................................................................. 7-9 Figure 7-9 Networking diagram of WLAN access ........................................................................................... 7-10 Figure 8-1 Centralized WLAN architecture ....................................................................................................... 8-3 Figure 8-2 RF management process ................................................................................................................... 8-4 Figure 8-3 Quick WLAN STA roaming ............................................................................................................. 8-5 Figure 8-4 Flowchart of AC auto-discovery ..................................................................................................... 8-10 Figure 8-5 Topology of the AC and the AP ...................................................................................................... 8-10 Figure 8-6 Registration flowchart of the AP obtaining an AC IP address through the DHCP server ............... 8-11 Figure 8-7 Registration flowchart of the AP obtaining an AC IP address through the DNS server.................. 8-12 Figure 8-8 Channel forwarding mode .............................................................................................................. 8-15 Figure 8-9 Direct forwarding mode .................................................................................................................. 8-15 Figure 8-10 Principle of CAPWAP .................................................................................................................. 8-16 Figure 8-11 Power decrease.............................................................................................................................. 8-18 Figure 8-12 Power increase .............................................................................................................................. 8-19 Figure 8-13 4-way handshake during the AC's processing quick roaming ....................................................... 8-23 Figure 8-14 Fast roaming by a STA within a same AC .................................................................................... 8-24 Figure 8-15 Process of OPEN-SYS authentication .......................................................................................... 8-25 Figure 8-16 Process of shared key authentication ............................................................................................ 8-26 Figure 8-17 Process of WAPI authentication and encryption ........................................................................... 8-29 Figure 8-18 Process of 802.1x authentication based on EAP-TLS .................................................................. 8-31 Figure 8-19 WLAN access solution ................................................................................................................. 8-34 Figure 8-20 Networking diagram of the scheme of channel access across the Layer 2 network ..................... 8-35 Figure 8-21 Networking diagram of the scheme of direct access across the Layer 2 network ......................... 8-36
Issue 01 (2010-06-25)
xi
Tables
Tables
Table 1-1 Comparisons between HWTACACS and RADIUS ......................................................................... 1-10 Table 1-2 Default domains of the CX600 ......................................................................................................... 1-12 Table 3-1 Description of fields in an L2TP message header............................................................................... 3-6 Table 4-1 Usages of DHCP options .................................................................................................................. 4-10 Table 4-2 Default values of timers .................................................................................................................... 4-10 Table 6-1 Common protocol codes ................................................................................................................... 6-13 Table 6-2 Common code values........................................................................................................................ 6-14 Table 8-1 Description of parameters of service set management ..................................................................... 8-20 Table 8-2 Carrier ID ......................................................................................................................................... 8-21 Table 8-3 AC ID ............................................................................................................................................... 8-22 Table 8-4 Parameters of the WMM profile ....................................................................................................... 8-32 Table 8-5 Parameters of the traffic profile ........................................................................................................ 8-33
Issue 01 (2010-06-25)
xiii
1
About This Chapter
1.1 1.2 References 1.3 Availability 1.4 Enhancement 1.5 Principles 1.6 Applications 1.7 Impact
Issue 01 (2010-06-25)
1-1
HWTACACS AAA can also be implemented through HWTACACS. HWTACACS is the enhancement of TACACS that is an access control protocol defined in RFC 1492. Similar to RADIUS, HWTACACS adopts the client/server model to communicate with the HWTACACS server, thus implementing AAA for various users, including Point-to-Point Protocol (PPP) users, Virtual Private Dial Network (VPDN) users, and login users. User management A broadband remote access server (BRAS) is used to manage access users. Currently, the BRAS manages users in the following modes:
Domain-based user management All users belong to a same domain. By default, users are added to a default domain. The BRAS manages users by configuring service attributes for a domain. Thus, the users in the same domain have the same service attributes.
User account-based user management User accounts and related service attributes are configured on an AAA server such as the RADIUS server or the HWTACACS server, and are then delivered to users when the users get online or dynamically delivered to users after the users get online.
In actual applications (except the applications of non-authentication and non-accounting) on the CX600, all user accounts must be configured on an AAA server, and all the domains to which the user accounts belong must be configured on the CX600. The CX600 supports the configuration and management of local user accounts. Commonly, the service attributes configured in a domain have a lower priority than the service attributes delivered by an AAA server. Therefore, when service attributes are configured in a domain and are also delivered by an AAA server, the CX600 adopts the service attributes that are delivered by the AAA server. The service attributes configured in a domain take effect only when the AAA server does not support or deliver the service attributes.
Purpose
The CX600 implements AAA through either RADIUS or HWTACACS. The CX600 supports domain-based or user account-based user management and supports multiple authentication and accounting policies. By authorizing and managing user attributes, the CX600 implements the enhanced the user management function, including user bandwidth control, access authority control, and QoS attribute control.
Benefits
This feature brings the following benefits to operators: Access users are identified to guarantee legal service access. Authorities of access users are controlled through domain-based or user account-based user management. The reliability of access user accounting is ensured through the RADIUS or HWTACACS accounting protocol and the local accounting function in case of the remote accounting failure.
1-2
Issue 01 (2010-06-25)
1.2 References
Document RFC 2903 RFC 2904 RFC 2905 RFC 2906 RFC 2989 RFC 3539 RFC 2809 RFC 2865 RFC 2866 RFC 2867 RFC 2868 RFC 2869 RFC 2882 RFC 3162 RFC 3575 RFC 3579 RFC 3580 RFC 4014 Description Generic AAA Architecture AAA Authorization Framework AAA Authorization Application Examples AAA Authorization Requirements Criteria for Evaluating AAA Protocols for Network Access Authentication, Authorization and Accounting (AAA) Implementation of L2TP Compulsory Tunneling via RADIUS Remote Authentication Dial In User Service (RADIUS) (June 2000) RADIUS Accounting (June 2000) RADIUS Accounting Modifications for Tunnel Protocol Support RADIUS Attributes for Tunnel Protocol Support RADIUS Extensions (June 2000) Network Access Servers Requirements: Extended RADIUS Practices RADIUS and IPv6 IANA Considerations for RADIUS (Remote Authentication Dial In User Service) RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option TACACS user identification Telnet option An Access Control Protocol, Sometimes Called TACACS (July 1993)
Issue 01 (2010-06-25)
1-3
1.3 Availability
Involved Network Element
None.
License Support
None.
Version Support
Product CX600 Version V600R002
Feature Dependency
None.
1.4 Enhancement
Version V600R002 Feature Enhancement 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-4
Issue 01 (2010-06-25)
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)
1-5
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-6
Issue 01 (2010-06-25)
If the policy is set to "online", the user remains online and sends real-time accounting packets to the AAA server. If the user needs to go offline, it sends an accounting packet to the AAA server. When the AAA server fails to charge the user, the user bill is saved locally. Policy for remote offline-accounting failures When a user goes offline and the AAA server fails in accounting, the user bill is saved locally; if the local bill pool is full, the bill is lost.
Accounting packet copy Accounting packet copy indicates that during accounting, accounting packets are sent to two AAA servers synchronously for separate accounting. This function is used when the original accounting information need be saved on multiple devices, for example, in the scenario of the multi-operator networking. In this case, the accounting packets are sent to two AAA servers and are used as original accounting information in subsequent bill accounting. There are the following accounting packet copy modes:
Physical accounting For physical accounting, an accounting copy server is configured on the BAS interface for user access. After the user logs in, the CX600 searches for the accounting copy server based on the user access interface and VLAN information and then copies the accounting packets to this accounting server.
Two-level accounting For two-level accounting, a main accounting server and an accounting copy server are configured for a domain. During accounting, the main accounting server copies the accounting packets to the accounting copy server.
1.5.2 RADIUS
Format of a RADIUS Message
Figure 1-1 shows the format of a RADIUS message. Figure 1-1 Format of a RADIUS message 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7- 0-1- 2- 3- 4- 5- 6-7 1 2 3 4 5 6 Attribute Authenticator Code Identifier Length
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)
1-7
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.
User
1. 2. 3.
A user initiates authentication and sends a user name and password to the CX600. After the RADIUS client configured on the CX600 receives the user name and password, it sends an authentication request to the RADIUS server. 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-8
Issue 01 (2010-06-25)
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.
Issue 01 (2010-06-25)
1-9
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 Uses the Transmission Control Protocol (TCP) to provide reliable transmission. Encrypts the main structure of a packet except the standard HWTACACS header. Separates authorization from authentication. Is suitable for security control. Authorizes the commands executed by administrative users. RADIUS Uses UDP. Encrypts only the password field in the authentication packet. Performs authentication together with authorization. Is suitable for accounting. 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.
1-10
Issue 01 (2010-06-25)
HWTACACS server displays a message to inform the user that command-line authorization fails and the command cannot be run. If the router does not receive any authorization response from the HWTACACS server within the timeout period set by the user, it considers that the command-line authorization times out, and thus the command cannot be run. Figure 1-3 shows the process of command-line authorization in HWTACACS. Figure 1-3 Process of command-line authorization in HWTACACS 1.command 2.author-cmd REQ
User
1. 2. 3.
The user enters a command on the CX600. The CX600 sends a command-line authorization request to the TACACS server. 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.
Issue 01 (2010-06-25)
1-11
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 default0 Description 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. 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. 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. Default Attributes Non-authenticatio n Non-accounting
default1
default_admin
Default-domain pre-authentication Default-domain authentication Default-domain authentication force Default-domain authentication replace Authentication domain Roam-domain Permit-domain Default-domain pre-authentication
1-12
Issue 01 (2010-06-25)
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)
1-13
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-14
Issue 01 (2010-06-25)
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)
1-15
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
user3@isp3
1-16
Issue 01 (2010-06-25)
corresponding rights to the users, and then the users can access the Internet. The accounting bills can also be copied to the bill server the same time they are being sent to the HWTACACS server. Figure 1-5 Networking diagram of HWTACACS authentication, accounting, and authorization HWTACACS (master) 130.7.66.66 HWTACACS (backup) 130.7.66.67
user3@isp3
1.7 Impact
1.7.1 On the System Performance 1.7.2 On Other Features 1.7.3 Defects
1.7.3 Defects
None.
Issue 01 (2010-06-25)
1-17
Abbreviation HWTACACS
1-18
Issue 01 (2010-06-25)
2 Plug-and-Play
2
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
Plug-and-Play
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.
Issue 01 (2010-06-25) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2-1
2 Plug-and-Play
2.2 References
The following table lists the references of this document. Document RFC 2131 RFC 2132 RFC 3046 Description Dynamic Host Configuration Protocol DHCP Options and BOOTP Vendor Extensions 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 CX600 Version 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-2
Issue 01 (2010-06-25)
2 Plug-and-Play
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.
Issue 01 (2010-06-25)
2-3
2 Plug-and-Play
Figure 2-1 Operation principle of a DHCP client DHCP Client DHCP Server
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
Issue 01 (2010-06-25)
2 Plug-and-Play
8. Reply with DHCP ACK. 5. Send Request 4. Reply with DHCP Offer 1. Send Discover
7. Reply with a DHCP ACK, which carries allocated address 6.Insert Option 82 and forward DHCP Offer 3. Reply with DHCP Offer 2. Insert Option 82 and forward Discover
UPE(DHCP Client)
10.The NMS sends configuration and start files to UPE and deliver restart conmand. 11. The device is usable after restart
The operation process of PnP is as follows: 1. After being powered on, the UPE starts the PnP process automatically. First, the UPE sends a DHCP Discover broadcast packet that carries the Vendor Class Identifier (VCI) in the Option 60 field. 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. 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. The DHCP relay agent receives the DHCP Offer packet and then sends it to the UPE. The UPE broadcasts a DHCP request. 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. 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. The DHCP relay agent receives the DHCP ACK packet and sends it to the UPE. After receiving the DHCP ACK packet, the UPE sends gratuitous ARP packets and checks whether the allocated address is already in use.
2.
3.
4. 5. 6.
7.
8. 9.
Issue 01 (2010-06-25)
2-5
2 Plug-and-Play
If the UPE finds that the allocated address is not in use, the UPE obtains information such as the IP address (yiaddr), mask (option 1), and gateway (option 3) from the DHCP ACK packet and generates a route. Meanwhile, the IP address X.X.X.X dynamic command is automatically executed; Telnet, AAA administrative user, FTP, and SNMP are configured on the UPE. Finally, the DHCP client function is disabled on the UPE, and the UPE cannot send or handle DHCP packets any longer. 10. The NMS delivers configuration files, startup files, and a restart command to the UPE. 11. The UPE restarts and can use the PnP feature. That is, the PnP process is complete.
2.5 Applications
As shown in Figure 2-3, the UPE obtains a management IP address through DHCP and starts a management channel through automatic configuration. The NMS delivers configuration files and startup files through the management channel. Figure 2-3 Network diagram of obtaining a management IP address and starting a management channel
UPE
PE-AGG IP/MPLS
NMS
DHCPClient
DHCPRelay
DHCPServer
2.6 Impact
2.6.1 2.6.2 Impact on the System Performance Impact on Other Features
2.6.3 Defects
2-6
Issue 01 (2010-06-25)
2 Plug-and-Play
2.6.3 Defects
None.
Acronyms
Acronym PNP DHCP Full Spelling Plug-and-Play Dynamic Host Configuration Protocol
Issue 01 (2010-06-25)
2-7
3 L2TP Access
3
About This Chapter
3.1 Introduction 3.2 References 3.3 Availability 3.4 Enhancement 3.5 Principles 3.6 Applications 3.7 Impact
L2TP Access
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).
Issue 01 (2010-06-25)
3-1
3 L2TP Access
L2TP supports the tunneling of PPP-encapsulated packets. It extends the PPP model by allowing the Layer 2 and PPP endpoints to reside on different devices interconnected through the packet switching technology. With L2TP, a user can set up an end-to-end PPP session on a non-point-to-point network. L2TP combines advantages of the Layer 2 Forwarding (L2F) and Point-to-Point Tunneling protocol (PPTP), and therefore is standardized by the IETF. L2TP involves the following concepts: Users In an L2TP networking, users are devices (such as PCs) to access a private network. The access modes and locations of VPDN users are always changing. In this situation, VPDN users can set up connections with an L2TP Access Concentrator (LAC) through the PSTN or ISDN or directly accesses the Internet to communicate with the server of the headquarters. A user is always the initiator of a PPP negotiation. Therefore, the user is both a Layer 2 PPP link end and a PPP session end. LAC An L2TP Access Concentrator (LAC) is a device on the switched network, with the capability of terminating PPP packets and performing L2TP functions. Usually, the LAC is an access device of the local ISP, such as the NAS, which provides access services for users through the PSTN or ISDN. The LAC tunnels individual PPP packets to the NAS through L2TP tunnels and PPP sessions. An LAC can provide services not only for a specified VPN but also for multiple VPNs. The LAC sits between the L2TP Network Server (LNS) and a remote system (remote subscribers and branches), as shown in Figure 3-1. Figure 3-1 VPDN model based on L2TP
Remote subscriber
Internal server
The LAC exchanges packets between the LNS and the remote system. It sends packets from the remote system to the LNS after the L2TP encapsulation process, and sends packets from the LNS to the remote system after the decapsulation process. The LAC and the remote system can be connected through local links or PPP links. Usually, PPP links are used between VPDN users and the LAC. The LAC is both an end to responds to users' requests and a PPP link end. LNS
3-2
Issue 01 (2010-06-25)
3 L2TP Access
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.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3-3
Issue 01 (2010-06-25)
3 L2TP Access
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 RFC 2661 RFC 1918 RFC 2809 RFC 2888 draft-ietf-l2tpe xt-tunnel-switc hing-07 Description Layer Two Tunneling Protocol "L2TP" Address Allocation for Private Internets Implementation of L2TP Compulsory Tunneling via RADIUS Secure Remote Access with L2TP PPP over L2TP Tunnel Switching Remarks
3-4
Issue 01 (2010-06-25)
3 L2TP Access
3.3 Availability
Involved Network Element
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 CX600 Version 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 V600R002 Enhancement 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
3 L2TP Access
3.5.2
L2TP Header
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.
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 T Meaning Indicates the type of a message: 0: indicates a data message. 1: indicates a control message. Remarks The value must be 1 in a control message.
3-6
Issue 01 (2010-06-25)
3 L2TP Access
Field L
Meaning Indicates the Length bit. The value 1 indicates that a message header contains the Length field. Indicates a reserved bit. Indicates the Sequence bit. The value 1 indicates that a message header contains the Ns field and the Nr field. Indicates the Offset size bit. The value 1 indicates that a message header contains the Offset size field. Indicates the priority. This field exists only in a data message. Indicates the version number of the L2TP protocol. Indicates the total length of a message, in bytes. Indicates the tunnel ID, which is only locally valid.
Remarks The value must be 1 in a control message. The value must be 1 in a control message. The value must be 0 in a control message. The value must be 0 in a control message. The value is 2 if L2TPv2 is enabled. The value must be 0 in a Hello control message because the Hello control message is globally valid. It is a reserved field in data messages. -
x S
Indicates the session ID, which is only locally valid. Indicates the sequence number of the current message. Indicates the sequence number of the next message expected to be received. Indicates the origin position of the payload. 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.
Issue 01 (2010-06-25)
3-7
3 L2TP Access
An 8-byte UDP header A 20-byte IP header, indicating the source and destination addresses of an L2TP tunnel Figure 3-4 shows the format of an L2TP data message. Figure 3-4 Format of an L2TP data message
20 bytes
New IP header
8 bytes
16 bytes
2 bytes
PPP header
20 bytes
Original header Data
The LAC encapsulates a PPP packet as follows: 1. 2. 3. Encapsulates the packet with an L2TP header. Encapsulates the packet with a UDP header. 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. 2. Decapsulates the IP header and the UDP header and then sends the packet to the L2TP module. 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.
3 L2TP Access
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 SCCRQ SCCRP SCCCN LNS
ZLB
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)
3-9
3 L2TP Access
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 Call Detected ICRQ ICRP ICCN ZLB ACK No messages waiting in queue LNS
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 CDN ZLB ACK LNS
3-10
Issue 01 (2010-06-25)
3 L2TP Access
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 StopCCN ZLB ACK LNS
3.
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. 5.
If tunnel authentication is successful, the LAC sends an SCCCN message carrying the local CHAP Response to the LNS. 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)
3-11
3 L2TP Access
IP Network
PSTN/ ISDN PC
Figure 3-10 shows the flowchart of establishing an L2TP call for tunnel authentication.
3-12
Issue 01 (2010-06-25)
3 L2TP Access
PC
LAC
LNS
LNS
(1) call setup (2) PPP LCP setup (3) PAP or CHAP authentication
(4) access request (5) access accept (6) tunnel establish (7) PAP or CHAP authentication (challenge/response) (8) authentication passes (9) user CHAP response, PPP negotiation parameter (10) access request (11) access accept
(12) CHAP authentication twice(challenge/response) (13) access request (15) authentication passes (14) access accept
1. 2. 3. 4. 5.
The PC initiates a request for establishing a call. The PPP LCP negotiation is performed between the PC and the LAC (Router A). The LAC authenticates the user information sent by the PC through PAP or CHAP. The LAC sends the user information (including the user name and password) to a RADIUS server for authentication. 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. The LAC sends a request for establishing a tunnel connection to the specified LNS. 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. Tunnel authentication succeeds. The LAC sends the user CHAP Response message, identifier of the Response message, and negotiated PPP parameters to the LNS.
6. 7.
8. 9.
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)
3-13
3 L2TP Access
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.
3-14
Issue 01 (2010-06-25)
3 L2TP Access
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.
IP Network
PSTN/ ISDN PC
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. Detecting that the endpoint of the session is the LNS, TUNLSW sends a request to the LNS for the establishment of a tunnel. TUNLSW switches the session along the tunnel between TUNLSW and the LAC to the tunnel destined for the LNS. 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) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3-15
2. 3. 4.
3 L2TP Access
tunnel switching technology. Figure 3-11 shows a simple networking scheme, whereas in practice, the session may be switched for multiple times before reaching the LNS. TUNLSW needs to be configured with two L2TP groups. One L2TP group, functioning as the LNS, receives the request initiated by the LAC for establishing a tunnel; the other L2TP group, functioning as the LAC, initiates a request for establishing a tunnel to another TUNLSW or LNS. Multiple protocols, including L2TP, can implement tunnel switching. Tunnel switching implemented through L2TP is also called multi-hop L2TP.
3.6 Applications
Two Typical L2TP Tunnel Modes
Figure 3-12 shows the mode of the tunnel between the remote system or the LAC client (the host running L2TP) and the LNS. Figure 3-12 Two typical L2TP tunnel modes LAC client
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-16
Issue 01 (2010-06-25)
3 L2TP Access
An L2TP tunnel is set up between the LAC and the LNS, and an L2TP tunnel can bear multiple sessions.
In NAS-initialized mode, as shown in Figure 3-12, LAN users are connected to a switch; the switch is connected to a router (or multiple users are directly connected to a router); the router is connected to the LAC through PPP or PPPoE. Figure 3-13 Users accessing the LAC through a router user
LAN Switch Router LAC PPP /PPPoE LNS Internet l2tp tunnel
Internal server
user
user
Client-initialized mode An LAC client that supports L2TP directly initiates a connection. The client needs to know the IP address of the LNS. The LAC client can directly send a request to the LNS for setting up a tunnel without the LAC. After receiving the request, the LNS authenticates the LAC client according to the user name and password. If the LAC client passes the authentication, the LNS assigns a private IP address to the LAC client. The client-initialized mode features the following:
Users need to install the L2TP dial-in software. Users can also dial in through the VPN dial-in software of the Windows operating system. There is no limitations of how and where users access the network, and no ISP is required. An L2TP tunnel is set up between the client and the LNS, and an L2TP tunnel can bear only one L2TP session. Users can choose a security protocol according to their requirements for data transmission security. If data to be transmitted needs high security, users can use IPSec.
Generally, both the NAS-initialized mode and the client-initialized mode can be used on a network. On certain networks, only the client-initialized mode is adopted. Such networks have strict requirements for the number of tunnels set up on the LNS because in client-initialized mode, an L2TP tunnel bears only one L2TP session.
Issue 01 (2010-06-25)
3-17
3 L2TP Access
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 user1@isp1
access network
CX-A
PC2
access network
LAC
L2TP Tunnel
user1@isp2
Users in a VPN accessing other VPNs You can use a multi-role host to help a VPN user access another VPN. The multi-role host is not suitable for the scenario where there are multiple VPNs and each VPN has multiple users that need to access other VPNs. VPN access through L2TP can address this problem. For example, users in VPN1 dial in to a PE through L2TP, and the PE assigns IP addresses of VPN2 to the users and adds the addresses to the routing table of VPN2. In this manner, users in VPN1 can access servers in VPN2. If the users attempt to access VPN3, the users can dial in by using the VPN3 user name to obtain IP addresses of VPN3. Then, the users can access VPN3.
Multi-hop L2TP
If no L2TP tunnel can be directly set up between the user and the LNS, and a PPP session needs to traverse multiple tunnels to reach the LNS, you can use L2TP tunnel switching, which is also called multi-hop L2TP.
3-18
Issue 01 (2010-06-25)
3 L2TP Access
IPv6 addresses to remote access users to allow them to access the IPv6 network, with the L2TP tunnel set up between the LAC and the LNS being still over an IPv4 network. For users that need to access both IPv4 and IPv6 networks, the LNS must be capable of assigning both IPv4 and IPv6 addresses to the users and then connecting the users to IPv4 and IPv6 networks separately. Figure 3-15 Application of IPv6 network access through L2TP on the carrier's network
DNS Server IPV4 IPv4 network IPV4/IPV6 access network PPPoX IPV6 LAC AAA Server
DNS Server
AAA Server
3.7 Impact
3.7.1 On the System Performance 3.7.2 On Other Features 3.7.3 Defects
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)
3-19
3 L2TP Access
3-20
Issue 01 (2010-06-25)
4 IPoEv4
4
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
IPoEv4
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.
Issue 01 (2010-06-25)
4-1
4 IPoEv4
4.2 References
The following table lists the references of this document. Document RFC 1541 RFC 2131 RFC 2132 RFC 3046 Description Dynamic Host Configuration Protocol Dynamic Host Configuration Protocol DHCP Options and BOOTP Vendor Extensions DHCP Relay Agent Information Option Remarks -
4.3 Availability
Version Support
Product CX600 Version V600R002
Feature Dependency
The relation between IPoE and other protocols is as follows: IPoE and DHCP snooping are mutually exclusive.
4.5 Principles
4.5.1 Basic Principle of IPoEv4 4.5.2 Basic Principle of DHCP
4-2
Issue 01 (2010-06-25)
4 IPoEv4
4 IPoEv4
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-4
Issue 01 (2010-06-25)
4 IPoEv4
IPoE
IPoEoVLAN
IPoEoA
DHCP Client
DHCP Relay
DHCP Server
4.DHCPACK
Obtain IP address Extend address lease
4.DHCPACK
6.DHCPACK
7.DHCP Request( broadcast) 7.DHCP Request(unicast)
8.DHCPACK 8.DHCPACK
The DHCP client communicates with the DHCP server in any of three modes.
Issue 01 (2010-06-25)
4-5
4 IPoEv4
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. 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. 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.
2.
The DHCP client accesses the network for the second time.
3.
4-6
Issue 01 (2010-06-25)
4 IPoEv4
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)
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)
4-7
4 IPoEv4
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. 2. 3. 4. The DHCP server unicasts a FORCERENEW packet to the DHCP client. The DHCP client sets its own status to "renew" and sends a DHCP Request packet to the DHCP server requesting for lease update. If the DHCP server intends to allocate a new IP address to the DHCP client, the DHCP server responds with a DHCP NAK packet. 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.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-06-25)
4-8
4 IPoEv4
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)
4-9
4 IPoEv4
Table 4-1 Usages of DHCP options Option ID Option 60 Usage 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. 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.
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 Lease renewal timer Rebinding timer Lease expiration timer Default Value 50% of the overall lease 87.5% of the overall lease 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-10
Issue 01 (2010-06-25)
4 IPoEv4
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)
4-11
4 IPoEv4
Figure 4-4 Networking diagram of local address allocation for Layer 2 access users
DHCP/IP/ARP VLAN 1001 IPv4 user IPv4 network LSW BRAS WEB Server DNS Server AAA Server
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
BRAS
AAA Server
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-12 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-06-25)
4 IPoEv4
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)
4-13
4 IPoEv4
packet. After receiving the DHCP Request packet, the DHCP server responds with a DHCP NAK packet to force the client to enter the initialized state. The DHCP client resends a DHCP Discover packet to apply for login. Both a static user and a user logged out abnormally can go online by sending IP or ARP packets. A static user has been assigned a fixed IP address on the client and does not need to be assigned an address on the BRAS. Therefore, the static user can go online only by sending IP or ARP packets. After receiving an IP or ARP packet from a user, the BRAS resolutes parameters such as the IP address and the MAC address and determines whether the user is legal. Then, the BRAS performs binding authentication for the user. After passing the authentication, the user can log in and access the network. The device can log a static user off through ARP probes or idle cutoff. Figure 4-6 Networking diagram of remote address allocation for a Layer 2 access user
DHCP/IP/ARP VLAN 1001 IPv4 user IPv4 network LSW BRAS WEB Server DNS Server AAA Server
DHCP Server
A DHCP access user can obtain an IP address from a remote DHCP server. In this case, the BRAS performs only user authentication, authorization, accounting, and forwarding control but does not manage IP addresses. The BRAS forwards the DHCP packet from a user to the remote DHCP server and sends the reply from the DHCP server to the DHCP client. Figure 4-6 shows the address allocation process through a remote DHCP server. Figure 4-7 shows the process of remote login of a DHCP user.
4-14
Issue 01 (2010-06-25)
4 IPoEv4
Client
BRAS
AAA Server
DHCP Server
DHCPDiscover
By applying a remote address pool in a domain, the BRAS can enable the remote DHCP server to allocate an address of an access user. A remote address pool does not contain any IP addresses but indicates the corresponding DHCP server. When a remote address pool is used, the BRAS replaces the user to send a DHCP Request packet to apply for an IP address from the DHCP server or extend the address lease, or relays the DHCP Request packet from the user. A remote address pool can be bound with a DHCP server group, which contains a maximum of two DHCP servers. The servers in a DHCP server group can work in active/standby or load balancing mode. By default, the servers in a DHCP server group work in active/standby mode. The server configured first acts as the active server. The active server takes priority of standby servers in address allocation. When the servers in a DHCP server group work in load balancing mode, a Layer 3 user accesses the BRAS through a Layer 3 device. A user can go online by sending a DHCP packet or an IP packet. Figure 4-8 Networking diagram of Layer 3 access users adopting Web authentication
RADIUS Server
Issue 01 (2010-06-25)
4-15
4 IPoEv4
The BRAS does not know the MAC address of a user accessing the network through a Layer 3 device. Therefore, the BRAS does not allocate an IP address to a user who adopts Web authentication. An RTA, a Layer 3 device, allocates an IP address to a user accessing the network through a Layer 3 device. After receiving an IP packet from a Layer 3 user, the BRAS checks whether it supports the Layer 3 user. If yes, the BRAS allows the user to perform Web authentication. After the client visits the web page and submits the user name and password, the Layer 3 user can access the network if it passes authentication. In the situation that a user accesses the network through a Layer 3 device, a Layer 3 router acts as a DHCP relay agent and relays the DHCP packet from the client to the BRAS. After authenticating the user, the BRAS allocates an idle IP address to the user according to the giaddr field. Alternatively, the RADIUS server can allocate an IP address to the user and send the DHCP Response packet to the client. The address pool selection mode for Layer 3 access is different from that for Layer 2 access. For a Layer 2 access user, the address pool searched is in the domain to which the user belongs. For a Layer 3 access user, the address pool of the same gateway IP address is searched according to the giaddr field in the DHCP packet. This ensures that the allocated address is on the same network segment with the gateway IP address. Figure 4-9 Networking diagram of Layer 3 DHCP users
AAA Server IPv4 user Layer2 network IPv4 user Router BRAS WEB Server IPv4 user 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-16
Issue 01 (2010-06-25)
4 IPoEv4
traffic passes through the leased line and the BRAS restricts the bandwidth of the leased line in a unified manner. Figure 4-10 shows Layer 2 leased line access. Figure 4-10 Networking diagram of Layer 2 leased line access
subscriber
subscriber
DSLAM
Layer 3 leased line Layer 3 leased line access refers to the access mode in which a user accesses a certain interface on the BRAS or a certain VLAN or PVC on a certain interface of the BRAS through a Layer 3 device such as a router. When this access mode is adopted, the BRAS performs the forwarding function of a router. The access router is in charge of assigning IP addresses to Layer 3 leased line users. The BRAS is in charge of only packet forwarding and validity inspection. A Layer 3 leased line is connected to the network when the protocol status on the interface is Up. Then, the users of the leased line can access the network without accessing the router. The services of the users of the Layer 3 leased line are controlled through the service control policy of the leased line. All the traffic passes through the leased line and the BRAS restricts the bandwidth of the leased line in a unified manner. Figure 4-11 Networking diagram of Layer 3 leased line access
Access network subscriber Router Internet BRAS Access network subscriber ATM Switch
Layer 2 VPN leased line The Layer 2 VPN leased line access mode is similar to the Layer 2 leased line access mode except that in this mode, each access interface is bound to a Layer 2 VPN. When the Layer 2 VPN leased line access mode is adopted, the BRAS functions as a UPE. A Layer 2 VPN leased line is connected to the network when the protocol status on the
Issue 01 (2010-06-25)
4-17
4 IPoEv4
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
RADIUSserver
Internet
4.7 Impact
4.7.1 4.7.2 Impact on the System Performance Impact on Other Features
4.7.3 Defects
4.7.3 Defects
None.
4-18
Issue 01 (2010-06-25)
4 IPoEv4
Access service
Acronyms
Acronym AAA ARP BRAS DHCP DSLAM IPoE IPoEoA IPoEoQ IPoEoVLAN QoS RADIUS UDP VPN Full Spelling Authentication, Authorization and Accounting Address Resolution Protocol Broadband Remote Access Server Dynamic Host Configuration Protocol Digital Subscriber Line Access Multiplexer IP over Ethernet IP over Ethernet over AAL5 IP over Ethernet over QinQ IP over Ethernet over VLAN Quality of Service Remote Authentication Dial-In User Service User Datagram Protocol Virtual Private Network
Issue 01 (2010-06-25)
4-19
5 IPoEv6
5
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
IPoEv6
Issue 01 (2010-06-25)
5-1
5 IPoEv6
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. Document RFC 2461 RFC 2462 RFC 3122 RFC 3315 RFC 3633 RFC 3646 RFC 3736 Description Neighbor Discovery for IP Version 6 (IPv6) IPv6 Stateless Address Autoconfiguration Extensions to IPv6 Neighbor Discovery Dynamic Host Configuration Protocol for IPv6 (DHCPv6) IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 Remarks
5.3 Availability
Involved Network Element
None.
License Support
None.
5-2
Issue 01 (2010-06-25)
5 IPoEv6
Version Support
Product CX600 Version V600R002
Feature Dependency
None.
Hardware Support
Board Supporting IPoEv6 Access LPUF-21 and LPUF-40 Board Supporting Access of IPv4/IPv6 Dual-Stack Users 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
Issue 01 (2010-06-25)
5-3
5 IPoEv6
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. The client sends a Router Solicitation (RS) message. The router replies with a Router Advertisement (RA) message, containing the following information:
3. 4.
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.
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-4
Issue 01 (2010-06-25)
5 IPoEv6
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)
5-5
5 IPoEv6
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-6
Issue 01 (2010-06-25)
5 IPoEv6
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)
5-7
5 IPoEv6
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.
5-8
Issue 01 (2010-06-25)
5 IPoEv6
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)
5-9
5 IPoEv6
N S ( r eqest s f or t he 1234: : 2/ 64 M AC addr ess) N A ( r epl i es w i t h t he 1234: : 2/ 64 M AC addr ess t hat bel ongs t o i nt er f ace A) D at a packet s dest i ned f or 1234: : 2/ 64
D at a packet s dest i ned f or 1234: : 2/ 64 N eeds t o send PC 1 dat a packet s N S ( r eqest s f or t he 1234: : 1/ 64 M AC addr ess) N A ( r epl i es w i t h t he 1234: : 1/ 64 M AC addr ess t hat bel ongs t o i nt er f ace B) D at 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-10
Issue 01 (2010-06-25)
5 IPoEv6
IPv4 Ba c kb o ne Ne tw o rk
IPv6
IPv6 PC
DSLAM
BRAS IPv6
Radius
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.
Issue 01 (2010-06-25)
5-11
5 IPoEv6
the authentication, the BRAS sends an RA message containing an IPv6 prefix to the user. If the message sent by the user is a DHCPv4 Discovery message and the user passes the authentication, the BRAS assigns an IPv4 address to the user. The user can then access the corresponding network by using the obtained address. After receiving an RS message or a DHCPv4 Discovery message from a user that has been authenticated, the BRAS assigns an address of another type to the user without authenticating the user. After obtaining the address, the user can access the corresponding network by using the address. Figure 5-4 Networking diagram for access of an IPv4/IPv6 dual-stack user running DHCPv4 and ND
Interface M=0
Radius
IPv6/IPv4 PC
DSLAM
BRAS IPv6/IPv4
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.
5-12
Issue 01 (2010-06-25)
5 IPoEv6
Figure 5-5 Networking diagram for access of a Layer 2 IPv6 user running DHCPv6 Interface M=1
IPv6 PC
DSLAM
BRAS IPv6
Radius
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.
Interface M=1
Radius
IPv6/IPv4 PC
DSLAM
BRAS IPv6/IPv4
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)
5-13
5 IPoEv6
Interface M=1
IPv6 PC
CX600
BRAS IPv6
Radius
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.
Radius
IPv6 PC
In the preceding scenario, both the HG and the BRAS must support DHCPv6-Prefix Delegation (DHCPv6-PD) for IPv6 prefix allocation. The HG can allocate IPv6 addresses to the IPv6 PCs through ND or DHCPv6. The BRAS interfaces that allow access to users must
5-14
Issue 01 (2010-06-25)
5 IPoEv6
be configured with binding authentication. The BRAS must be configured with the DHCPv6 DUID, IPv6 prefix pool, address pool, and other access configurations.
Radius
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)
5-15
5 IPoEv6
Figure 5-10 Schematic diagram of communication between users with the same prefix through the BRAS
1234::1/64
N D Pr oxy Enabl ed
BRAS IPv6
IPv6 PC2
1234::2/64
If PC1 and PC2 are connected to different interfaces of the BRAS, both interfaces must be enabled with ND proxy; otherwise, the PCs cannot communicate with each other.
5.7 Impact
5.7.1 On the System Performance 5.7.2 On Other Features 5.7.3 Defects
5.7.3 Defects
None.
5-16
Issue 01 (2010-06-25)
5 IPoEv6
Term ND
Description 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
Abbreviation ND DAD NS NA RS RA DHCPv6 DUID Full Spelling Neighbor Discovery Duplicate Address Detection Neighbor Solicitation Neighbor Advertisement Router Solicitation Router Advertisement Dynamic Host Configuration Protocol for IPv6 (DHCPv6) A DHCP Unique Identifier for a DHCP participant
Issue 01 (2010-06-25)
5-17
6 PPPoE Access
6
About This Chapter
6.1 Introduction 6.2 References 6.3 Availability 6.4 Principles 6.5 Applications 6.6 Impact
PPPoE Access
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.
Issue 01 (2010-06-25)
6-1
6 PPPoE Access
Figure 6-1 PPP in the protocol stack SNMP TELNET SOCKET TCP ICMP IP ARP PPP Physical Layer UDP FTP RADIUS
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-2
Issue 01 (2010-06-25)
6 PPPoE Access
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
Document RFC 1661 RFC 1877 RFC 1990 RFC 2472 RFC 2516 RFC 5072 Description The Point-to-Point Protocol (PPP) PPP Internet Protocol Control Protocol Extensions for Name Server Addresses The PPP Multilink Protocol (MP) IP Version 6 over PPP A Method for Transmitting PPP Over Ethernet (PPPoE) IP Version 6 over PPP
6.3 Availability
Involved Network Element
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 CX600 Version V600R002
Feature Dependency
None.
Issue 01 (2010-06-25)
6-3
6 PPPoE Access
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
PPPoE Negotiation
In PPPoE negotiation, the CX device assigns a unique session ID for a user that accesses the network through PPPoE. The session ID uniquely identifies a PPPoE link between the user and CX device over the Ethernet. The PPPoE negotiation process is as follows: Figure 6-2 PPPoE negotiation process
User CX
1. 2.
A host broadcasts a PPPoE Active Discovery Initiation (PADI) packet that contains information about the desired service. 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-4
Issue 01 (2010-06-25)
6 PPPoE Access
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. 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.
4.
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 Config-req Config-ack LCP negotiation Config-req Config-ack Server
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. 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.
2.
Issue 01 (2010-06-25)
6-5
6 PPPoE Access
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 Auth-req Auth-req PPP authentication Auth-ack Auth-ack Server Radius
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-6
Issue 01 (2010-06-25)
6 PPPoE Access
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 Challenge(CHAP) Auth-req PPP authentication Auth-ack Auth-req Auth-ack Server Radius
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)
6-7
6 PPPoE Access
Figure 6-6 NCP negotiation process Client Parmeter-req Parmeter-ack NCP negotiation Parmeter-req Parmeter-ack Server
1.PADI 2.PADO PPPoE negotiation 3.PADR 4.PADS PPP negotiation 5.LCP negotiationCHAP authentication 6.Challenge 7.Response 8.Access Request 9.Access Accept/Reject 10.Success/Failure 11 NCP negotiation User logs in
6-8
Issue 01 (2010-06-25)
6 PPPoE Access
Issue 01 (2010-06-25)
6-9
6 PPPoE Access
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-10
Issue 01 (2010-06-25)
6 PPPoE Access
State Transition
Figure 6-8 State transition
Up Dead Establish Opened Authenticate
Fail
Fail
Terminate Down
Closing
Network
Success/None
Link Dead phase: The link necessarily begins and ends with this phase. When an external event (such as carrier detection or network administrator configuration) detects that the physical layer gets ready, PPP will enter the Establishment phase. In this phase, the LCP state machine will be in the Initial or Starting state. An Up event will be sent to the LCP state machine when a link transits from either the Initial state or the Starting state to the Establishment state. The link returns to this phase automatically after being disconnected. Generally, this phase is very short, merely long enough to detect that the device is in service. Link Establishment phase: LCP is used to establish a connection by exchanging Configure packets. Once a Configure-Ack packet is sent and then received by the peer, LCP enters the Opened state. Only Configuration options which are independent of particular network-layer protocols are configured by LCP. Configuration of individual network-layer protocols is handled by separate Network Control Protocols (NCPs) during the Network-Layer Protocol phase. Any non-LCP packet received in this phase is directly discarded. Receipt of the LCP Configure-Request packet causes a return to the Link Establishment phase from the Network-Layer Protocol or Authentication phase. Authentication phase: A certain link may require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged. By default, authentication is not mandatory. If an application requires that the peer authenticate by using a certain authentication protocol, a request for the use of the authentication protocol must be sent in the Link Establishment phase. Authentication should take place immediately after link establishment. However, link quality determination may occur concurrently. An application must ensure that no delay during the exchange of link quality determination packets. The Authentication phase cannot transit to the Network-Layer Protocol phase until authentication is complete. If authentication fails, the authenticator should perform authentication again instead of entering the Link Termination phase. Only LCP, authentication protocol, and link quality monitoring packets can be transmitted in this phase. Other packets received in this phase are discarded Network-Layer Protocol phase: Once PPP goes through the previous phases, each network-layer protocol (such as IP or IPX) must be separately configured by an appropriate NCP. An NCP may be Opened or Closed at any time. After an NCP reaches the Opened state, PPP transmits corresponding network-layer protocol packets. Any network-layer protocol packet received when the corresponding NCP is not in the Opened state must be discarded. In
Issue 01 (2010-06-25)
6-11
6 PPPoE Access
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-12
Issue 01 (2010-06-25)
6 PPPoE Access
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 21 002b 002d 002f 57 8021 802b 8031 8057 C021 C023 C223 Protocol Type Internet Protocol Novell IPX Van Jacobson Compressed TCP/IP Van Jacobson Uncompressed TCP/IP IPv6 Internet Protocol Control Protocol Novell IPX Control Protocol Bridging NC IPv6CP Link Control Protocol Password Authentication Protocol 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)
6-13
6 PPPoE Access
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-14
Issue 01 (2010-06-25)
6 PPPoE Access
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 of Negotiation Packets Maximum-Receive-Unit Async-Control-Character-Map Authentication-Protocol Quality-Protocol Magic-Number RESERVED Protocol-Field-Compression Address-and-Control-Field-Compression
Type Value 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08
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)
6-15
6 PPPoE Access
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
subscriber
Lanswitch
CX
Point-to-Point Protocol over Ethernet over VLAN (PPPoEoV) In PPPoEoV services, the Ethernet interface card of a PC encapsulates PPP packets into PPPoE packets, and then sends them to a LAN switch. The LAN switch adds a VLAN tag to each of the PPPoE packets, which are then called PPPoEoV packets, and sends the PPPoEoV packets to the CX600. The following figure shows the typical networking model of PPPoEoV services. In this model, a PC accesses the Ethernet interface on the CX600 through a switch that complies with IEEE 802.1Q. Figure 6-11 Typical networking model of PPPoEoV services Eth PPPoE PPP IP Data Eth Q PPPoE PPP IP Data Internet subscriber LAN Switch CX
Point-to-Point Protocol over Ethernet over QinQ (PPPoEoQ) In PPPoEoQ services, the Ethernet interface card of a PC encapsulates PPP packets into PPPoE packets, and then sends them to a switch. The switch adds a VLAN tag to each of the PPPoE packets, which are then called PPPoEoV packets, and then sends the PPPoEoV packets to another switch that is adjacent to the CX600. The later switch adds another VLAN tag to each of the PPPoEoV packets, which are then called PPPoEoQ packets, and then sends the PPPoEoQ packets to the CX600. The following figure shows the typical networking model of PPPoEoQ services. In this model, a PC accesses the Ethernet interface on the CX600 through two switches that comply with IEEE 802.1Q.
6-16
Issue 01 (2010-06-25)
6 PPPoE Access
Figure 6-12 Typical networking model of PPPoEoQ services IP Data PPP PPPoE Eth IP Data PPP PPPoE Eth Q IP Data PPP PPPoE Eth Q Q Internet subscriber LAN Switch LAN Switch CX
Point-to-Point Protocol over ATM Adaptation Layer 5 (PPPoA) In PPPoA services, an Asymmetric Digital Subscriber Line (ADSL) modem that supports ATM Adaptation Layer 5 (AAL5) encapsulation encapsulates PPP packets into PPPoA packets, and then sends the PPPoA packets to a Digital Subscriber Line Access Multiplexer (DSLAM). The DSLAM sends the PPPoA packets to the CX600. The following figure shows the typical networking model of PPPoA services. In this model, a PC is connected to an ADSL modem over the LAN; the ADSL modem is connected to the DSLAM over the PSTN/ISDN; the DSLAM is connected to the CX600 over the ATM network. Serving as a PPP client, the ADSL modem automatically dials in after being powered on to establish a PPP connection with the CX600. This PPP connection is transparent for the PC, and thus it is unnecessary to install the client dial-in software on the PC. Figure 6-13 Typical networking model of PPPoA services AAL5 PPP IP Data AAL5 PPP IP Data Internet PC ADSL Modem DSLAM CX
Point-to-Point Protocol over Ethernet over ATM Adaptation Layer 5 (PPPoEoA) In PPPoEoA services, the Ethernet interface card of a PC encapsulates PPP packets into PPPoE packets, and then sends them to an ADSL modem. The ADSL modem that supports AAL5 encapsulation encapsulates the PPPoE packets into PPPoEoA packets, and then sends the PPPoEoA packets to the CX600. The following figure shows the typical networking model of PPPoEoA services. In this model, a PC is connected to an ADSL modem over the Ethernet; the ADSL modem is connected to the DSLAM over the PSTN/ISDN; the DSLAM is connected to the CX600 over the ATM network. The PC is installed with the PPPoE client dial-in software and sets up a PPP connection with the CX600. The ADSL modem provides only the Layer 2 bridging function to transparently transmit data.
Issue 01 (2010-06-25)
6-17
6 PPPoE Access
Figure 6-14 Typical networking model of PPPoEoA services Eth PPPoE PPP IP Data AAL5 Eth PPPoEPPP IP Data Internet PC ADSL DSLAM Modem CX
Internet
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.
6.6 Impact
6.6.1 On the System Performance 6.6.2 On Other Features 6.6.3 Other Defects
6-18
Issue 01 (2010-06-25)
6 PPPoE Access
Issue 01 (2010-06-25)
6-19
7 802.1x Access
7
About This Chapter
7.1 Introduction to 802.1x Access 7.2 References 7.3 Availability 7.4 Feature Enhancement 7.5 Principle 7.6 Applications 7.7 Impact
802.1x Access
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.
Issue 01 (2010-06-25)
7-1
7 802.1x Access
7.2 References
Document Name RFC 2284 RFC 3748 IEEE Std 802.1X-2001 Description PPP Extensible Authentication Protocol (EAP) Extensible Authentication Protocol (EAP) IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control Remarks -
7.3 Availability
License Support
None.
Version Support
Product CX600 Version 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).
7-2
Issue 01 (2010-06-25)
7 802.1x Access
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
Client
Client PAE
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)
7-3
7 802.1x Access
In the 802.1x authentication system, the authentication server and client exchange authentication information through EAP. Between the client Port Access Entity (PAE) and the device PAE, EAPoL encapsulation is adopted for EAP packets. Between the device PAE and the RADIUS server, EAP packets can adopt EAP over RADIUS (EAPoR) encapsulation and be borne by RADIUS. EAP packets can be terminated on the device PAE. In this case, Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) packets are transmitted between the device PAE and the RADIUS server. The device PAE is isolated from the authentication function. The RADIUS server can authenticate the client PAE through any of several authentication mechanisms such as MD5-challenge, PAP, and EAP-PEAP. The device PAE determines the status (authorized/unauthorized) of the controlled interface according to the instructions (accept/reject) from the RADIUS server. Figure 7-2 Protocol structure of the 802.1x authentication system
RADIUS-bearing EAP/PAP/CHAP packet exchange
Client PAE
EAPOL
Device PAE
Authentication server
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.
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-4
Issue 01 (2010-06-25)
7 802.1x Access
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.
Issue 01 (2010-06-25)
7-5
7 802.1x Access
Figure 7-3 Basic process of the IEEE 802.1x authentication system (1)
C l i ent PAE
EAPoL EAPoL-Start
Device PAE
RADIUS
RADIUSserver
RADIUSAccess-Request EAP-Response/MD5 Challenge (EAP-Response/MD5 Challenge) EAP-Success RADIUSAccess-Accept (EAP-Success) Interface authorized [ EAP- R equest / I dent i t y] [ EAP- R esponse/ I dent i t y] ...... EAPoL- Logof f Interface unauthorized
Handshake reply H andshake r equest
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-6
Issue 01 (2010-06-25)
7 802.1x Access
Figure 7-4 Basic process of the IEEE 802.1x authentication system (2)
Client PAE
EAPoL EAPoL-Start
Device PAE
RADIUS
RADIUSserver
EAP-Request/Identity EAP-Response/Identity EAP-Request/MD5Challenge RADIUSAccess-Request EAP-Response/MD5 Challenge (EAP-Response/MD5 Challenge) EAP-Success RADIUSAccess-Accept (EAP-Success) Interface authorized Handshake request [EAP-Request/Identity] Handshake reply [EAP-Response/Identity] Handshake timer times out
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)
7-7
7 802.1x Access
Terminal
AP
BRAS
AAA Server
1.broadcast probe
12.Radius-Access802.1X EAP 13.EAP-request/Identity Challenge authenticatio 15.Radius-Accessn 14.EAP-response/Identity Request 17.BRAS saves PMK and sends EAP-success 18.EAPOL-nonce 19.calculate PTK and send to AC 16.Radius-AccessAccept
20.Check the PTK and deliver the GTK 21.Key is usable AP interface usable 23.DHCP Discover, apply for address 22.KEY delivered
Userdata forwarding
7.6 Applications
Typical Applications of 802.1x Access
The networking mode for 802.1x access is similar to that for IPoE, IPoEoV, and IPoEoQ. An EAP packet is converted into an EAPoL packet after passing through an Ethernet interface on
7-8
Issue 01 (2010-06-25)
7 802.1x Access
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
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
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
Issue 01 (2010-06-25)
7-9
7 802.1x Access
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
7.7 Impact
7.7.1 7.7.2 Impact on the System Performance Impact on Other Features
7.7.3 Defects
7.7.3 Defects
None.
7-10
Issue 01 (2010-06-25)
7 802.1x Access
Abbreviation
Abbreviation EAP EAPoL EAPoR Full Spelling Extensible Authentication Protocol EAP over LAN EAP over RADIUS
Issue 01 (2010-06-25)
7-11
8 WLAN
8
About This Chapter
8.1 Introduction to WLAN 8.2 References 8.3 Availability 8.4 Principles 8.5 Applications 8.6 Impact
WLAN
Issue 01 (2010-06-25)
8-1
8 WLAN
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-2
Issue 01 (2010-06-25)
8 WLAN
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)
8-3
8 WLAN
When radio signals are propagated, they are greatly affected by surroundings. Specifically, due to multipath options, radio signals encounter complex attenuation in different directions. Therefore, thorough network planning is performed before build-out of a WLAN network. After a WLAN network is deployed, radio signal propagation may also be affected by much interference arising from constant change of the wireless environment, moving obstacles, and operating microwave. Therefore, it is inevitable to adjust parameters. In this case, RF resources such as channel and transmit power must be dynamically adjusted to adapt to changes of application environments. RF management is to apply a set of systematic real-time intelligent RF methods (including data collection, data analysis, decision making, and decision execution) to the wireless network, so as to quickly adapt to changes of the wireless environment and maintain the optimal status of RF resources.Figure 8-2 shows the RF management process. Figure 8-2 RF management process
Data collection: APs collect RF environment information in real time according to policies provided by the AC. Data analysis: The AC analyzes and assesses data collected by the APs.
Decision execution: APs execute configurations set by the AC and adjust RF resources.
Decision making: According to the analysis result, the AC assigns channels and transmit power.
Service set management (ESS profile) Service set management is to manage certain attributes of a service set, including creating, deleting, modifying, and querying the service set. Configuration auto-provisioning management Configuration auto-provisioning management is to manage the creation, modification, deletion, and query of the configuration auto-provisioning rules. Configuration auto-provisioning rules are pre-defined. In this manner, APs can obtain necessary configurations and perform configurations automatically. Centralized BSSID management Basic service set (BSS) is a basic component over the 802.11 network, and comprises a group of stations (STAs) that can communicate with each other. Every BSS is assigned a BSSID to uniquely identify the BSS (the BSSID is a binary 48-bit identifier used by all STAs in a BSS). Centralized BSSID management is a process in which the AC automatically assigns a unique BSSID over the entire network to every VAP, eliminating any need of manual operations. Load balancing Load balancing is a method to load the excess STAs on an AP to other APs within the same group as the AP when the quantity of STAs on the AP exceeds the preset user quantity and user traffic threshold. WLAN STA roaming
8-4
Issue 01 (2010-06-25)
8 WLAN
When a STA moves at a small area within a deployed WLAN network, the STA may roam from one AP to another. For this scenario, the WLAN STA roaming function is provided. WLAN STA roaming is a process in which an STA moves from one AP to another. Currently, Huawei's products support quick WLAN STA roaming within a same AP. That is, if an STA uses 802.1x authentication, 802.1x authentication and key exchange are not performed after the client moves from one AP to another, thus speeding up roaming. In short, when an STA roams from one AP to another (the two APs are within the same AC), the STA does not need to log in or be authenticated again. Figure 8-3 shows quick WLAN STA roaming. Figure 8-3 Quick WLAN STA roaming
AC ESS
AP2
STA
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)
8-5
8 WLAN
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-6
Issue 01 (2010-06-25)
8 WLAN
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 RFC 5415 RFC 5416 Description CAPWAP protocol CAPWAP protocol binding IEEE 802.11
Issue 01 (2010-06-25)
8-7
8 WLAN
Document Name RFC 5417 RFC 4347 RFC 4118 RFC 4564
Description CAPWAP AC DHCP option Datagram Transport Layer Security CAPWAP Architecture Taxonomy Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)
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 CX600 Version V600R002
Feature Dependency
N/A
8-8
Issue 01 (2010-06-25)
8 WLAN
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)
8-9
8 WLAN
Principle of AC Auto-Discovery
After an AP is powered on, it can automatically discover an AC in either static or dynamic mode. Figure 8-4 shows the operation flow. Figure 8-4 Flowchart of AC auto-discovery
Start
End End
As shown in Figure 8-4, if a static AC IP address list is pre-configured, the AP directly connects to the AC with the specified IP address. If no AC IP address list is pre-configured, the AP enables the dynamic AC auto-discovery mechanism to associate with the AC. Figure 8-5 shows the topology of the AC and the AP. Figure 8-5 Topology of the AC and the AP
AC DHCP/DNS server
Switch
AP
An AP can implement AC auto-discovery by pre-configuring a static AC IP address list or dynamically obtaining an AC IP address through the DHCP server or the DNS server. AC auto-discovery by pre-configuring a static AC IP address list:
8-10
Issue 01 (2010-06-25)
8 WLAN
When the AP is started, it sends a DHCP discovery packet to obtain an IP address. Then, the AP pre-configures a static AC IP address list. The AP sends a discovery request to all the ACs whose IP addresses are contained in the pre-configured list. If the AP receives a discovery response from an AC, the AP automatically sets up a management connection to the AC. If the AP does not receive a response from any AC, the AP waits for 30s before initiating the discovery process again. AC auto-discovery by dynamically obtaining an AC IP address through the DHCP server: When no AC IP address list is pre-configured, the AP enables the dynamic AC auto-discovery mechanism. Then, the AP dynamically obtains the IP address of an AC through the DHCP server. Figure 8-6 shows the registration flow. Figure 8-6 Registration flowchart of the AP obtaining an AC IP address through the DHCP server
AP DHCP server AC
AP obtains IP address and DHCP server domain name 1 AP sends discovery request
2
3
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. 2. 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. 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)
8-11
8 WLAN
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. The AP downloads the latest software version from the AC. The AP downloads the latest configuration from the AC. The AP starts to run in the normal state and exchanges user data packets with the AC.
4. 5. 6.
AC auto-discovery by dynamically obtaining an AC IP address through the DNS server The AP can also dynamically obtain the IP address of an AC through the DNS server. Figure 8-7 shows the registration flow. Figure 8-7 Registration flowchart of the AP obtaining an AC IP address through the DNS server
AP DHCP server DNS server AC
AP obtains IP address and DHCP & DNS server domain names 1 2 AP sends discovery request AP does not receive a response over a long time AP obtains IP address of switch 3 Switch sends discovery response 4 AP downloads version 5 AP downloads configuration 6 AP and AC transfer user data 7
As shown in Figure 8-7, the registration flow of the AP dynamically obtaining an AC IP address through the DHCP server and DNS server is as follows: 1. The AP obtains its own IP address, and obtains the AC IP address (through DHCP Option 43), DHCP server domain name, and DNS server domain name through the DHCP server. 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:
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-06-25)
2.
8-12
8 WLAN
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. The AC sends a discovery response indicating that the discovery is successful. The AP downloads the latest software version from the AC. The AP downloads the latest configuration from the AC. The AP starts to run in the normal state and exchanges user data packets with the AC.
4. 5. 6. 7.
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)
8-13
8 WLAN
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-14
Issue 01 (2010-06-25)
8 WLAN
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
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)
8-15
8 WLAN
Set up DTLS
Restart
Join AC
Yes
Previous Version
No
Download configuration Operation
During operation, the AC dynamically changes the configuration of the WTP through control packets and obtains the operation status of the WTP and information about stations and radio frequencies. All the data is processed on the AC. Therefore, the AC can perform QoS management and dynamic RF monitoring on the entire network.
8.4.2 RF Management
This topic describes the principles, methods, and advantages of channel adjustment and power adjustment. RF adjustment involves two modes: global optimization and individual periodic optimization. Global optimization is based on the RF domain. That is, ACs within a same RF coordinate RF parameters of all relevant APs in a unified manner to achieve optimal performance. The use of the RF domain zooms out the applicable scope of the RF optimization algorithm and therefore speeds up optimization. The signal coverage of the RF domain must be the same as that of the AP domain. Individual periodic optimization is to make adjustments on a single AP. RF optimization (global optimization and individual periodic optimization) is triggered in any of the following modes: Individual periodic optimization is triggered according to the air-interface performance indexes detected periodically (the indexes include conflict rate threshold and packet loss/error packet threshold). Global optimization can be triggered at the preset time. That is, global optimization starts when the preset time is due. Global optimization can be triggered manually.
Channel Adjustment
Within a WLAN network, channel resources are scarce and non-overlapping channels over which every AP works are very limited. For example, for a 2.4G network, there are only three non-overlapping channels. Thus, it is very crucial for wireless applications to assign channels
8-16
Issue 01 (2010-06-25)
8 WLAN
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)
8-17
8 WLAN
AP1
AP2
AC
Switch
AP3
When AP4 is added, the neighbor quantity of each AP reaches the default upper limit 3 (this limit is configurable). In this case, the power of every AP becomes smaller.
AP1
AP2
AC
Switch
AP3 AP4 Channel 1 Channel 6 Channel 11
As shown in Figure 8-12, if AP4 goes offline, the power of each of the other three APs will be increased to eliminate "black hole" of signal coverage.
8-18
Issue 01 (2010-06-25)
8 WLAN
AP1
AP2
AC
Switch
AP3 AP4
AP1
AP2
AC
Switch
AP3
Issue 01 (2010-06-25)
8-19
8 WLAN
Layer 2 user isolation User association timeout period Service set type
Controls Layer 2 isolation of users associated with the service set. 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. 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.
Indicates the IGMP status that can be off, proxy, or snooping. Indicates the ID of the VLAN mapping the service set.
8-20
Issue 01 (2010-06-25)
8 WLAN
Description Indicates the traffic policies implemented by the service set. Indicates the security policies (such as authentication and encryption) implemented by the service set.
Issue 01 (2010-06-25)
8-21
8 WLAN
Table 8-3 AC ID Parameter AC ID Description Used to uniquely identify an AC managed by a carrier. The AC ID ranges from 0 to 4095.
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-22
Issue 01 (2010-06-25)
8 WLAN
Figure 8-13 4-way handshake during the AC's processing quick roaming
AP
AC
Roam request Roam response Request of associating with a new AP Response to the request of associating with a new AP
Quick roaming of IPoE STAs at Layer 3. The process is similar to the preceding process at Layer 2. The difference is that the AC determines that the STA requires a roaming across Layer 3, and then the AC directly uses the original service IP address and implements re-leasing in the original IP address domain for the STA through proxy. Figure 8-14 shows the principle of quick roaming by a STA within a same AC.
Issue 01 (2010-06-25)
8-23
8 WLAN
(2)
(3)
AP2 Channel 6
SSID: Huawei
SSID: Huawei
(2) Deassociate between STA and AP1 (3) Set up association between STA and AP2
As shown in Figure 8-14, the AC has associated with AP1. If an STA roams to AP2 from AP1, the AC processes the STA's roaming as follows: 1. The STA sends the 802.11 request frame to every channel. After receiving the STA's 802.11 request frame in channel 6 (a channel used by AP2), AP2 sends a response frame in channel 6. After the STA receives the response frame, it assesses the response frame and determines which AP is best for the STA to associate with. 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. 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.
2.
3.
8-24
Issue 01 (2010-06-25)
8 WLAN
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.
OPEN-SYS Authentication
OPEN-SYS authentication is the default authentication mechanism. It is the simplest authentication algorithm, that is, null authentication. If the authentication type is set to OPEN-SYS, it indicates that any STA that transmits an authentication request will pass the authentication. OPEN-SYS authentication involves two stages: authentication request and authentication result return. If the authentication is successful, the STA and the AP are declared mutually authenticated. Figure 8-15 shows the process of OPEN-SYS authentication. Figure 8-15 Process of OPEN-SYS authentication
STA AP
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)
8-25
8 WLAN
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.
WEP encryption must be adopted for the encryption of shared key authentication. Figure 8-16 Process of shared key authentication
STA
AP
Authentication request PSK Randomly generate a "challenge text" Use the key to encrypt the plain text Cipher text with "challenge text" encrypted Successful authentication response Compare the decrypted cipher text with the plain text PSK
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. 2. Poor extensibility. Each STA must be configured with a long key character string. 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-26
Issue 01 (2010-06-25)
8 WLAN
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.
Issue 01 (2010-06-25)
8-27
8 WLAN
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.
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-28
Issue 01 (2010-06-25)
8 WLAN
STA
AP
Authentication activation Identity authentication process Communica tion process Access authentication request Access authentication response
Unicast Key negotiation request Unicast Key negotiation response Unicast key confirmation
Multicast key notification Multicast key response
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)
8-29
8 WLAN
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-30
Issue 01 (2010-06-25)
8 WLAN
STA
AP
AC
OPEN-SYM authentication Associate EAP start EAP request for user identification EAP response to user indentification Verify the server certificate, and use the public key to encrypt the master key to generate PMK Server certificate (public key) STA certificate (master key encrypted by the public key) Authentication success Check PMK consistency, and generate other keys 4-way handshake key negotiation Encrypt data packet User identification Server certificate (public key)
STA certificate (master key encrypted by the public key) Authentication success PMK is generated Check PMK consistency, and generate other keys
Verify the STA certificate, and use the private key to decrypt the master key to generate PMK
8.4.9 QoS
This topic describes the principle of QoS management.
Issue 01 (2010-06-25)
8-31
8 WLAN
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 Parameter WMM switch Permission control switch EDCA Description Enables or disables the WMM function. Determines whether an STA that does not support the WMM function can access the AP that supports the WMM function. 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.
8-32
Issue 01 (2010-06-25)
8 WLAN
packets, and upstream/downstream tunnel priority configuration. Table 8-5 lists parameters of the traffic profile. Table 8-5 Parameters of the traffic profile Parameter rate-limit Configuration of the 802.3 packet priority Description Limits the upstream packet rate on the STA or the entire VAP. 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. 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. 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. Configures mapping between the 802.1p priority of the downstream 802.3 packet and the UP priority of the 802.11 packet.
Configuration of the upstream tunnel priority Configuration of the downstream tunnel priority UP priority configuration
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)
8-33
8 WLAN
Wireless Modem
Terminal
Access
AC
CORE
As shown in Figure 8-19, in addition to accessing Multi-service Edge (MSE) users, the ACs, together with hotspot APs, provide WLAN accesses for users. In this case, the ACs can manage APs (plug-and-play, RF management, load balancing, and roaming management), WLAN user access, and AP QoS.
8-34
Issue 01 (2010-06-25)
8 WLAN
Figure 8-20 Networking diagram of the scheme of channel access across the Layer 2 network
AC
GE1/0/1.1 VLAN 2 BAS VE2/0/2.1 VLAN 1
Layer 2 network
AP
PC
Phone
When users directly access the BAS or AC, the access interface is a real physical interface. User packets are thus forwarded across the Layer 2 network to the AC for processing.
Issue 01 (2010-06-25)
8-35
8 WLAN
Figure 8-21 Networking diagram of the scheme of direct access across the Layer 2 network
AC
AP BAS GE1/0/2.2 STA BAS GE1/0/2.1
Layer 2 network
AP
PC
Phone
8.6 Impact
8.6.1 On the System Performance 8.6.2 On Other Features 8.6.3 Defects
8-36
Issue 01 (2010-06-25)
8 WLAN
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.
Issue 01 (2010-06-25)
8-37
8 WLAN
Description 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. An STA refers to a terminal such as a laptop or a PC with a wireless network interface card (NIC). 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. 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 is a medium used for transmitting data frames between wireless users. The WLAN uses RF as transmission medium. 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. 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. 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.
Station (STA) Access point (AP) Access controller (AC) Wireless medium CAPWAP
WMM
EDCA
8-38
Issue 01 (2010-06-25)
8 WLAN
Acronym & Abbreviation BSS ESS EAP WAPI MFHO DS DTLS LAN MAN WAN LWAPP WEP OPEN-SYS DCF CSMA/CA EDCA AIFSN
Full Spelling Basic Service Set Extended Service Set Extensible Authentication Protocol Wireless LAN Authentication and Privacy Infrastructure Manageable Fast Handover Distribution System Datagram Transport Layer Security Local Area Network Metropolitan Area Network Wide Area Network Lightweight access point protocol Wired equivalent privacy Open system authentication Distributed coordination function Carrier sense multiple access with collision avoidance Enhanced distributed channel access Arbitration inter frame spacing number
Issue 01 (2010-06-25)
8-39