· Bind authentication—The BRAS automatically generates usernames and passwords for users based on the user access location. Users are not required to enter usernames and passwords.

· Web authentication—The BRAS requires users to enter usernames and passwords on the Web authentication page.

· 802.1X authentication—The BRAS requires users to enter usernames and passwords on an 802.1X client. To access a Layer 3 interface through 802.1X, configure the 802.1X authentication method.

As shown in Figure 1, a BRAS connects hosts over IPoE connections, and provides AAA, security, DHCP, and portal services for the hosts. The host can be a browser running HTTP or HTTPS or a cellphone running the H3C iNode client.

Figure 1 IPoE network diagram

‌

IPoE access modes

IPoE supports Layer 2 and Layer 3 access modes.

· Layer 2 access mode—Hosts directly access the BRAS. The hosts connect to the BRAS directly or through Layer 2 devices. The BRAS uses MAC addresses to identify the hosts.

· Layer 3 access mode—Hosts use routing to access the BRAS. The hosts connect to the BRAS directly or through Layer 3 devices. On a Layer 3 device between the hosts and BRAS, the source MAC address of packets received by the BRAS is the MAC address of the Layer 3 device. Therefore, the BRAS uses IP addresses or VLAN IDs to identify hosts.

IPoE CUPS mode

About this task

On a traditional BRAS, the control plane capabilities might not match the forwarding plane capabilities, the resources cannot be shared, and new services cannot be deployed in time. The vBRAS CP and UP separation (CUPS) solution is introduced to solve this problem.

In this solution, the forwarding plane and control plane are completely decoupled and are independent of each other. The solution contains control plane (CP) roles and user plane (UP) roles, which together implement the BRAS functionality.

· CP—Performs control plane services, including user identification and address allocation and management. Typically, a CP is a vBRAS.

· UP—Performs the forwarding plane services, including data packet forwarding and traffic control. A UP can be a router, or vBRAS.

The following three channels are established between the CP and UP to implement CUPS.

· Management channel—Deploys configuration between the CP and UP.

· Control channel—Deploys entries between the CP and UP.

· Protocol tunnel—Transmits protocol packets between the CP and UP.

Operating modes

In a CUPS network, a BRAS can operate in one of the following modes:

· Common mode—A BRAS operating in this mode performs both control and forwarding services. A device operating in this mode is called a unified device.

· Control plane mode—Also known as session mode. This mode implements the CP function based on remote interfaces. When the UP connected to a CP supports IPoE, you can configure the session mode. In this mode, the CP sends BRAS sessions to the UP. The UP performs data packet forwarding according to the received sessions. For more information about remote interfaces, see CP-UP connection management in the vBRAS-CP configuration guides.

· User plane mode—A BRAS operating in this mode performs only the forwarding service. A BRAS operating in user plane mode is a UP.

The control plane mode and user plane mode are collectively referred to as the CUPS mode.

NOTE:

· Unless otherwise specified, a BRAS in this document operates in common mode.

· In CUPS mode, this device can only act as a UP and cannot act as a CP.

‌

IPoE user types

IPoE sessions can be initiated by IP, ARP, NS, NA, ND RS, or DHCP packets. Depending on whether an IPoE user has independent service attributes, IPoE users include individual users and leased users.

Individual users

Individual users use independent IPoE services. The BRAS authenticates, authorizes, and accounts individual users based on user location and packet information. Individual users include dynamic and static individual users.

· Dynamic individual users

IPoE defines the following dynamic individual users:

¡ DHCP user—Sends DHCP packets to initiate IPoE sessions and obtains an IP address from the DHCP server.

¡ IPv6 ND RS user—Sends IPv6 ND RS packets to initiate IPoE sessions and obtains an IP address from the BRAS.

¡ Unclassified-IP user—Sends packets other than DHCP and IPv6 ND RS packets to initiate IPoE sessions.

· Static individual users

Static individual users initiate IPoE sessions by sending IP, ARP, NS, or NA packets. If an IP packet matches a manually configured IPoE session, the BRAS authenticates the user and establishes an IPoE session.

NOTE:

A DHCP or IPv6 ND RS user is abnormally logged out if the IPoE session of the user is deleted for a reason except the user actively releases its IP address. With the function of allowing abnormally logged out IPoE users to come online again enabled, when the device receives IP, ARP, or NS/NA packets from the user, the device can restore the IPoE session for the user. The restored IPoE session is a DHCP or IPv6 ND RS session. For more information about re-logging in abnormally logged out IPoE users, see "Allowing abnormally logged out IPoE users to come online again through packet initiation."

‌

Leased users

Leased users include the following types:

· Interface-leased user—Represents hosts that rent the same interface.

· Subnet-leased user—Represents hosts that rent a subnet of an interface.

· L2VPN-leased user—Represents hosts that rent the same interface on an L2VPN network.

· Static leased user—A static leased user is a special type of leased line in the following aspects:

¡ Independent service attributes—Similar to an interface-leased line, unified authentication, authorization, and accounting are performed for all users on an interface. When a static leased session comes online, packets with any source IP address can pass through the leased interface.

¡ Packet initiation—Similar to a global static individual session, with IPoE enabled on an access interface in up state, when IP, ARP, NS, or NA packets pass through the access device, the access interface will try to initiate authentication by using the configured username and password. If a user passes authentication, a static leased session is established. If a user fails to pass authentication, no static leased session is established.

NOTE:

Because static leased sessions are special, leased users include only interface-leased users, L2VPN-leased users, and subnet-leased users and do not include static leased users unless otherwise specified.

‌

IPoE session

An IPoE session represents all network connections of one IPoE client or a group of IPoE clients. An IPoE session can be identified by the IP packet characteristics or access location of clients. An IPoE session records the identification information, authentication status, authorization attributes, and DHCP address assignment information of IPoE clients.

Depending on the IPoE user types, IPoE sessions include individual sessions and leased sessions. .

Individual sessions

Depending on how a session is initiated, IPoE individual sessions include IPoE dynamic individual sessions and IPoE static individual sessions.

· IPoE dynamic individual session

IPoE sessions established for dynamic individual users are IPoE dynamic individual sessions.

The BRAS deletes a dynamic individual session in one of the following cases:

¡ The AAA-authorized session duration expires.

¡ The AAA server logs out the user.

¡ The user traffic is less than the AAA-authorized traffic during the idle-timeout time.

¡ The BRAS cannot detect the user after the number of detection attempts reaches the maximum.

- For a single-stack user, the session is deleted when the number of detection attempts reaches the maximum.

- For a dual-stack user, the session is deleted when the number of detection attempts reaches the maximum for both stacks.

¡ The IP address lease expires for IPoE sessions initiated by DHCP packets.

- For a single-stack user, the session is deleted when the IP address lease expires.

- For a dual-stack user, the session is deleted when the IP address leases of both stacks expire.

¡ The access interface goes down.

· IPoE static individual session

An IPoE static individual session represents all network connections of an IPoE client with the specified IP address (IPv6 or dual-stack global static sessions can contain IPv6 delegation prefixes). Typically, IPoE static individual sessions provide stable access services for clients with known IP addresses.

On an IPoE-enabled interface in up state, the BRAS initiates authentication based on the configured username and password upon receiving IP, ARP, NS, or NA packets from users. The BRAS creates a static individual session only when the authentication succeeds.

IPoE leased sessions

IPoE leased sessions are IPoE sessions established for IPoE leased users. IPoE leased sessions include the following types:

· Interface-leased session—Represents network connections of all IPoE clients on an interface.

· Subnet-leased session—Represents network connections of all IPoE clients in a subnet of an interface.

· L2VPN-leased session—Represents network connections of all IPoE client on an interface.

· Static leased session—Represents network connections of all IPoE clients on an interface.

For leased users, the BRAS initiates user authentication based on the configured username and password after you enable IPoE on an interface in up state. Authentication does not need to be initiated by user traffic. If the authentication succeeds, a leased session is established. If the authentication fails, no leased session is established.

A static leased session is a special type of leased line in the following aspects:

· Independent service attributes—Similar to an interface-leased line, unified authentication, authorization, and accounting are performed for all users on an interface. When a static leased session comes online, packets with any source IP address can pass through the leased interface.

· Packet initiation—Similar to a global static individual session, with IPoE enabled on an access interface in up state, when IP, ARP, NS, or NA packets pass through the access device, the access interface will try to initiate authentication by using the configured username and password. If a user passes authentication, a static leased session is established. If a user fails to pass authentication, no static leased session is established.

NOTE:

‌

IPoE addressing

IPoE addressing varies with user types.

A DHCP user obtains IP addresses in the following sequence:

1. Obtains an IP address from the AAA-authorized IP address pool.

2. Obtains an IP address from the IP address pool configured in the ISP domain if the AAA server does not authorize any IP address pools.

3. Obtains an IP address in the same network segment as the interface IP address if no IP address pool is configured in the ISP domain.

On an IPv6 network, a host can get an IPv6 global unicast address through the following methods:

· NDRA—The host obtains an IPv6 prefix in an RA message if the host sends RS packets to initiate authentication and successfully passes authentication. The host then generates an IPv6 global unicast address based on the IPv6 prefix. IPv6 prefixes include the following types in descending order of priority: AAA-authorized IPv6 prefix, prefix in the AAA-authorized ND prefix pool, RA prefix configured on an interface, and IPv6 global unicast address prefix configured on an interface. Among these prefixes:

¡ The following three prefix methods apply to the prefix sharing scenario: AAA-authorized IPv6 prefix, RA prefix configured on an interface, and IPv6 global unicast address prefix configured on an interface. In this scenario, multiple users share one IPv6 prefix.

¡ The AAA-authorized ND prefix pool or ND prefix pool group applies to the scenario of one prefix per user. In this scenario, each user has an exclusive IPv6 prefix.

· DHCPv6 (IA_NA)—The host requests an IPv6 global unicast address through DHCPv6. After an IPv6 address pool is authorized to users, IA_NA also supports authorizing the specified 128-bit IPv6 global unicast addresses to DHCP users through the following methods:

¡ Authorizing 128-bit IPv6 global unicast addresses by an AAA server through the Framed-IPv6-Address attribute.

¡ Authorizing 128-bit IPv6 global unicast addresses by using the authorization-attribute ipv6 command in local user view.

Make sure the 128-bit IPv6 global unicast addresses authorized by using the two methods above are within the authorized IPv6 address pool. Otherwise, the 128-bit IPv6 global unicast addresses authorized by using the two methods above are not used, and IPv6 addresses in the IPv6 address pool are randomly allocated to users.

· DHCPv6 (IA_PD)—A CPE requests prefixes through DHCPv6 and assigns them to downstream hosts. The hosts then use the prefixes to generate IPv6 global unicast addresses. This method uses the same principle of selecting address pools as the DHCPv6 (IA_NA) method.

You can configure the combination of NDRA+IA_PD or IA_NA+IA_PD methods as needed to meet the address allocation requirements in different scenarios.

If an ND prefix pool is used to allocate prefixes to users (in the one prefix per user scenario), the following restrictions apply to these users:

· These users cannot be leased users, including interface-leased users, subnet-leased users, and L2VPN-leased users.

· The ICMPv6 detection method is not supported.

· Prefixes of these users cannot be configured for static IPoE users.

· On an access interface of these users, you cannot configure an IPv6 global unicast address.

· On an access interface of an IPoE user exclusively using a prefix, you cannot configure an IPv6 global unicast address.

In DHCPv6 (IA_PD) method, you cannot configure an IPv6 global unicast address on the access interface of a user.

Other users use static IP addresses or obtain IP addresses from the DHCP server without using IPoE.

IPoE access procedure by using bind authentication in common mode

IPoE access by using bind authentication in common mode includes the following steps:

1. The BRAS initiates authentication.

The BRAS obtains information from user packets or IPoE sessions statically configured, and sends authentication requests.

2. The AAA server authenticates users.

The AAA server completes user authentication and sends the result to the BRAS. The security server, if configured, completes security authorization and sends the result to the BRAS.

3. (Optional.) DHCP allocates IP addresses and IPoE allocates IPv6 prefixes.

The DHCP server assigns an IP address to a DHCP user and the IPoE assigns an IPv6 prefix to an IPv6 ND RS user.

4. The BRAS performs access control.

The BRAS permits the user to get online and performs access control and accounting based on the authorized result.

Access procedure for DHCP single-stack users

This section uses a DHCPv4 user as an example to illustrate the access procedure for DHCP single-stack users. The BRAS acts as a DHCP relay agent.

Figure 2 Access procedure for a DHCPv4 user

‌

1. The DHCP client sends a DHCP-DISCOVER message to the BRAS.

2. The BRAS inserts Option 82 in the DHCP-DISCOVER message, and creates an IPoE session.

3. The BRAS sends the AAA server an access request that includes user information, such as the client ID and source MAC address.

4. The AAA server returns an Access-Accept packet that contains authorization information to the BRAS if the authentication succeeds. If the authentication fails, the AAA server returns an Access-Reject message.

5. The BRAS marks the IPoE session state as success and forwards the DHCP-DISCOVER message to the DHCP server if the authentication succeeds. If the authentication fails, the BRAS marks the session as failure and drops the DHCP-DISCOVER message.

6. The DHCP server sends a DHCP-OFFER message to the BRAS.

7. The BRAS forwards the DHCP-OFFER message to the DHCP client.

8. The DHCP client sends a DHCP-REQUEST message to the BRAS.

9. The BRAS forwards the DHCP-REQUEST message to the specified DHCP sever.

10. The DHCP server sends a DHCP-ACK message containing the assigned IP address to the BRAS.

11. The BRAS performs the following operations:

a. Obtains address information from the DHCP-ACK message.

b. Assigns a user profile.

c. Updates the IPoE session information.

d. Forwards the DHCP-ACK message to the client.

e. Marks the session state as online.

If the authentication fails, the BRAS marks the session as failure and drops the DHCP-DISCOVER message.

12. The DHCP client obtains configuration information from the DHCP-ACK message.

13. The BRAS sends the AAA server a message to start accounting.

Access procedure for DHCP dual-stack users

This section illustrates the access procedure for DHCP dual-stack users. The BRAS acts as a DHCP relay agent. DHCPv6 packet initiation include IA_NA and IA_PD methods. IA_NA assigns global unicast IPv6 addresses to hosts through DHCPv6. IA_PD assigns PD prefixes to clients through DHCPv6.

Figure 3 Access procedure for a DHCP dual-stack user

‌

1. The DHCPv4 client sends a DHCP-DISCOVER message.

2. The DHCPv4 relay agent inserts Option 82 in the DHCP-DISCOVER message, and creates an IPoE session.

3. The relay agent sends the AAA server an access request including user information, such as the client ID and source MAC address in DHCPv4 packets.

4. The AAA server returns an Access-Accept packet that contains authorization information to the DHCPv4 relay agent if the authentication succeeds. If the authentication fails, the AAA server returns an Access-Reject message.

5. The DHCPv4 relay agent obtains the user authentication and authorization result, and updates the session status to success or failure.

6. The DHCPv4 relay agent forwards the DHCP-DISCOVER message to the DHCP server if the authentication succeeds. If the authentication fails, the DHCPv4 relay agent drops the DHCP-DISCOVER message.

7. The DHCPv4 server sends a DHCP-OFFER message to the DHCPv4 relay agent. The DHCPv4 relay agent forwards the DHCP-OFFER message to the DHCP client.

8. The DHCPv4 client sends a DHCP-REQUEST message to the DHCPv4 relay agent. The DHCPv4 relay agent forwards the DHCP-REQUEST message to the specified DHCP sever.

9. The DHCP server sends a DHCP-ACK message containing the assigned IP address to the DHCPv4 relay agent.

10. The DHCPv4 relay agent performs the following operations:

a. Obtains address information from the DHCP-ACK message.

b. Assigns a user profile.

c. Updates the IPoE session information.

d. Marks the session state as online.

11. The DHCPv4 relay agent forwards the DHCP-ACK message to the client. The DHCP client obtains configuration information from the DHCP-ACK message.

12. The DHCPv4 relay agent sends the AAA server a message to start accounting.

13. The DHCPv6 client sends a Solicit message. The DHCPv6 relay agent updates IPoE session information based on the Solicit message. The IA_NA field in packets corresponds to the obtained global unicast IPv6 address. The IA_PD field in packets corresponds to the obtained IPv6 address prefix.

14. The DHCPv6 server responds with an Advertise message. Then, the DHCPv6 relay agent forwards the Advertise message to the DHCPv6 client.

15. The DHCPv6 client select a DHCPv6 server according to the Advertise message and sends a request. The DHCPv6 relay agent forwards the request to the DHCPv6 server.

16. The DHCPv6 server responds with a reply message.

17. The DHCPv6 relay agent parses the IPv6 address, IPv6 address prefix, and other address parameters in the reply message, and updates the IPoE session.

18. The DHCPv6 relay agent forwards the reply message to the DHCPv6 client. The DHCPv6 client obtains the IPv6 address and related address parameters.

Access procedure for IPv6 ND RS users

This example uses a Layer 2 device as the BRAS.

Figure 4 Access procedure for IPv6 ND RS users

‌

1. The host sends an IPv6 ND RS packet to the BRAS.

2. The BRAS initiates an IPoE session and sends the AAA server an access request that contains user information, such as the source MAC address.

3. The AAA server returns an Access-Accept packet that contains authorization information to the BRAS if the authentication succeeds. If the authentication fails, the AAA server returns an Access-Reject message.

4. The BRAS performs the following operations:

a. Generates an IPv6 address based on the host's MAC address and the IPv6 prefix.

b. Updates the IPoE session information.

c. Marks the session as success.

If the authentication fails, the BRAS marks the session as failure and drops the IPv6 ND RS packet.

5. The BRAS assigns a user profile and sends the host an IPv6 ND RA packet containing the IPv6 prefix.

6. The host generates an IPv6 address based on the received IPv6 prefix.

7. The BRAS sends the AAA server a message to start the service accounting.

Access procedure for unclassified-IP users

Figure 5 Access procedure for unclassified-IP users

‌

1. The host sends an IP packet to the BRAS.

2. The BRAS obtains user information from the IP packet, and compares the user information with existing IPoE sessions.

¡ If no match is found, the BRAS initiates an IPoE session for the user. (This section uses this case as an example.)

¡ If the information matches an authenticated session, the BRAS forwards the IP packet.

¡ If the information matches an unauthenticated session, the BRAS drops the IP packet.

3. The BRAS sends the AAA server an access request containing the obtained information, such as the source IP address or source MAC address.

4. The AAA server returns an Access-Accept packet that contains authorization information if the authentication succeeds. If the authentication fails, the AAA server returns an Access-Reject message.

5. The BRAS assigns a user profile and marks the IPoE session state as online.

6. The BRAS sends the AAA server a message to start the service accounting.

Access procedure for static and leased users

The access procedure for static users is the same as that for unclassified-IP users except in the following aspects:

· The IPoE static session is configured at the CLI.

· The IPoE static session can be initiated by IP, ARP, NS, or NA packets.

If you specify a global static user with an IPv6 delegation prefix, after the user comes online, the traffic matching the IPv6 delegation prefix network segment can also be directly forwarded.

The access procedure for leased users is the same as that for unclassified-IP users except in the following aspects:

· The IPoE leased session is configured at the CLI.

· The IPoE leased session does not need to be initiated by packets. Users are not required to send IP packets to trigger authentication. The BRAS initiates user authentication based on the configured username and password.

IPoE access procedure by using Web authentication in common mode

IPoE Web authentication applies to DHCP users, IPv6 ND RS users, and static individual users. The authentication process includes two phases: preauthentication and Web authentication (also known as postauthentication).

Preauthentication access procedure

The access procedure in the preauthentication phase is the same as the access procedure by using bind authentication for users in common mode. For more information about the access procedure, see "Access procedure for DHCP single-stack users," "Access procedure for IPv6 ND RS users," and "Access procedure for static and leased users."

Web authentication access procedure

In the Web authentication phase, the authentication procedure is basically the same for users. This section uses a DHCPv4 user as an example to illustrate the access procedure by using Web authentication. The BRAS acts as a DHCP relay agent.

Figure 6 Web authentication access procedure

The user can perform Web authentication through the Web browser or the iNode client. This section uses the Web browser as an example.

1. The DHCP client initiates an HTTP/HTTPS GET message.

2. The BRAS checks the destination IP address of the HTTP/HTTPS GET message.

¡ If the message is destined for the portal Web server, the BRAS forwards the message to the portal Web server. The DHCP client directly accesses the Web authentication page of the portal Web server. .

¡ If the message is not destined for the portal Web server, the BRAS sends the message containing the Web server URL information to the DHCP client.

3. The DHCP client automatically accesses the redirected URL based on configured Web server URL information.

4. The portal Web server sends the Web authentication page to the DHCP client.

5. The user enters a username and password on the Web authentication page.

6. The portal server forwards the Web authentication information to the BRAS.

7. The BRAS sends the AAA server an access request based on the Web authentication information.

8. The AAA server returns to the BRAS one of the following results:

¡ An Access-Accept packet that contains authorization information if the authentication succeeds.

¡ An Access-Reject message if the authentication fails.

9. The BRAS performs one of the following operations based on the received result:

¡ Updates the IPoE session state as failed upon receiving an Access-Reject message.

¡ Updates the IPoE session state as authorized upon receiving an Access-Accept packet.

10. If the authentication succeeds, the BRAS sends the AAA server a message to start accounting.

NOTE:

When the user performs Web authentication through the iNode client, the user can directly open the client authentication page and enter the authentication information. The remaining steps 6 through 10 are the same.

‌

IPoE quick Web authentication in common mode

In an IPoE Web environment, IPoE Web authentication supports quick authentication. With quick authentication, users that access the network frequently do not need to enter authentication information each time they come online in the Web authentication phase.

For valid users that access the network frequently, you can implement MAC-based quick authentication. It allows users to pass authentication without entering authentication information. MAC-based quick authentication is also called transparent authentication. Based on the location where the usernames, passwords, and MAC-to-account bindings of users are stored, transparent authentication includes the following types:

· Transparent MAC-trigger authentication—To use transparent MAC-trigger authentication, you must deploy a MAC binding server in the network. The MAC binding server records the MAC-to-account bindings of users for authentication.

· Transparent MAC authentication—To use transparent MAC authentication, you must deploy an AAA server that can bind the Web authentication information of users to MAC addresses of user endpoints for authentication.

Depending on the IP address allocation methods, transparent MAC authentication includes the following types:

¡ Common transparent MAC authentication—Only one IP address allocation is performed in the whole authentication and coming online process. A user triggers transparent MAC authentication in the Web authentication phase. After the user passes transparent MAC authentication, the user comes online in the Web authentication phase.

¡ Re-DHCP transparent MAC authentication—Two IP address allocations are performed in the whole authentication and coming online process. A user triggers transparent MAC authentication in the preauthentication phase. After the user passes transparent MAC authentication, the user comes online in the preauthentication phase.

When transparent MAC-trigger authentication or common transparent MAC authentication is configured, IPoE queries the MAC bindings for a user when receiving any IP packets of the user in the preauthentication domain. For a user that uses Web access for the first time, the authentication procedure includes the querying process.

When re-DHCP transparent MAC authentication is configured, IPoE triggers preauthentication and queries the MAC binding for a user when receiving DHCP-DISCOVER (IPv4) or Solicit (IPv6) packets.

Transparent MAC-trigger authentication procedure

IMPORTANT:

Transparent MAC-trigger authentication supports only Web authentication that is triggered through the Web browser.

‌

1. The client initiates HTTP/HTTP requests after coming online in the preauthentication domain.

2. The BRAS checks the destination IP of the HTTP/HTTPS request.

3. If the message is destined for the portal Web server, the BRAS forwards the message to the portal Web server.

4. If the message is not destined for the portal Web server, the BRAS sends a binding query request to the portal server. The portal server returns the query result.

If the query result shows that the user has not been bound, the following operations are performed:

a. The BRAS redirects the subsequent HTTP/HTTPS requests to the Web authentication page of portal Web server. The BRAS sends HTTP/HTTPS messages containing the Web authentication page URL of the portal Web server to the client.

b. The client browser automatically accesses the Web authentication page of the portal Web server.

c. The portal Web server sends the Web authentication page contents to the client.

d. The user enters the username and password and click Log in to send the authentication information to the portal server.

If the query result shows that the user has been bound, the BRAS waits for the Web authentication information from the portal server.

5. The portal Web server sends the Web authentication information to the BRAS.

6. The BRAS sends the AAA server an access request based on the Web authentication information.

7. The AAA server returns to the BRAS one of the following results:

¡ An Access-Accept packet that contains the authorization information if the authentication succeeds.

¡ An Access-Reject message if the authentication fails.

8. The BRAS performs one of the following operations based on the received result:

¡ Updates the IPoE session state as failed upon receiving an Access-Reject message.

¡ Updates the IPoE session state as authorized upon receiving an Access-Accept packet.

9. If the authentication succeeds, the BRAS sends the AAA server a message to start accounting.

10. (Applicable only to users that perform Web authentication the first time.) After the user comes online, the BRAS notifies the portal server of the event. After receiving the notification, the portal server notifies the MAC binding server to add a MAC binding for the user.

When the user accesses the network the next time, the user can come online through quick authentication based on the queried MAC binding entry after the BRAS receives any IP packets of the user.

Common transparent MAC authentication procedure

IMPORTANT:

Common transparent MAC authentication supports only Web authentication that is triggered through the Web browser.

‌

The common transparent MAC authentication procedure is as follows (take the first login as an example):

1. The client initiates HTTP/HTTP requests after coming online in the preauthentication domain.

2. The BRAS checks the destination IP of the HTTP/HTTPS request.

3. If the message is destined for the portal Web server, the BRAS forwards the message to the portal Web server.

4. If the message is not destined for the portal Web server, the BRAS uses the MAC address of the user as the username to send authentication requests to the AAA server. Because the user logs in for the first time, the AAA server fails to query the binding of the user based on the MAC address and returns authentication failure.

a. The BRAS redirects the subsequent HTTP/HTTPS requests to the Web authentication page of portal Web server.

b. The client browser automatically accesses the Web authentication page of the portal Web server.

c. The portal Web server sends the Web authentication page contents to the client.

d. The user enters the username and password and click Log in to send the authentication information to the portal server.

5. The portal Web server sends the Web authentication information to the BRAS.

6. The BRAS sends the AAA server an access request based on the Web authentication information.

7. The authentication succeeds. The AAA server returns to the BRAS an Access-Accept packet that contains the authorization information.

8. The BRAS updates the IPoE session state as authorized upon receiving an Access-Accept packet.

9. The authentication succeeds. The BRAS sends the AAA server a message to start accounting.

10. After the user comes online, the BRAS notifies the AAA server of the event. After receiving the notification, the AAA server adds a MAC binding for the user.

When the user accesses the network the next time, the BRAS uses the MAC address of the user as the username to send authentication requests to the AAA server after receiving any IP packets of the user. The AAA server can query the MAC binding for the user and returns authentication success. Then, the user can come online without entering the username and password.

Re-DHCP transparent MAC authentication procedure

IMPORTANT:

· Re-DHCP transparent MAC authentication is only supported by DHCP users (including IPv4 and IPv6 users). For a dual-stack user to support re-DHCP transparent MAC authentication, make sure the user is a DHCP user in at least one protocol stack.

· Re-DHCP transparent MAC authentication supports only Web authentication that is triggered through the Web browser.

‌

The re-DHCP transparent MAC authentication procedure is as follows (take the first login as an example):

1. When the device receives DHCP-DISCOVER (IPv4) or Solicit (IPv6) packets from a user, the device triggers preauthentication and uses the user MAC address as the username to initiate authentication on the AAA server. (In this phase, suppose ISP domain dm1 is used, which is configured by using the ip subscriber pre-auth domain command.)

2. Because the user logs in for the first time, the AAA server fails to query the binding of the user based on the MAC address and returns authentication failure. After the user fails authentication, the user uses the reauthentication domain dm2 to trigger preauthentication again. Domain dm2 is configured not to perform authentication by using the none keyword. The user comes online in the preauthentication domain and obtains a temporary IP address. (In this phase, suppose reauthentication domain dm2 is used, which is configured by using the authen-fail online domain command.)

3. After the user comes online in the preauthentication domain, the user initiates HTTP/HTTPS requests and comes online in the Web authentication phase through the common Web authentication process. Then, the AAA server adds a MAC binding entry for the user. (In this phase, suppose ISP domain dm3 is used, which is configured by using the ip subscriber web-auth domain command.)

4. After the device receives accounting response packets from the AAA server, the device clears session information for the DHCP user and forcibly logs out the user. For a dual-stack user, the user will be forcibly logged out in both stacks only if it is a DHCP user in one protocol stack. If the user wants to come online again, the user needs to trigger preauthentication again (if the user is not a DHCP user in a protocol stack, the user must come online again based on the original configuration). Later, if the device receives DHCP lease renewal requests from the user, the device directly replies with NAK, so that the user can come online as soon as possible through transparent MAC authentication in the preauthentication domain.

5. When the device receives DHCP-DISCOVER (IPv4) or Solicit (IPv6) packets from the user again, the device triggers preauthentication and uses the user MAC address as the username to initiate authentication on the AAA server. The AAA server queries the MAC binding for the user based on the user MAC address and returns authentication success packets carrying the authorization domain (dm4 in this example). The device allocates a public network IP address to the user according to the IP address pool in the authorization domain.

6. If the authentication success packets returned by the AAA server do not carry an authorization domain, authorize an IP address pool in authentication domain dm1. Then, the device allocates a public network IP address in the authorized IP address pool to the user.

IPoE 802.1X authentication user access procedure in common mode

NOTE:

In the current software version, IPoE 802.1X authentication is supported only in common mode.

IPoE 802.1X authentication supports DHCP users, IPv6 ND RS users, and static users. The authentication process includes two phases, including preauthentication and postauthentication. For a user configured with a static IP address to come online through 802.1X authentication without configuring the corresponding IPoE static user access on the BRAS, you can enable the static 802.1X user authentication feature. For more information, see the ip subscriber static-dot1x-user enable command.

When 802.1X authentication is not prioritized, an 802.1X user must perform IPoE preauthentication and 802.1X postauthentication to come online. When 802.1X authentication is prioritized, an 802.1X user only needs to perform one authentication on the 802.1X client. Select whether to prioritize 802.1X authentication as needed.

When 802.1X authentication is not prioritized, an IPoE comes online in the following process:

· In the preauthentication phase:

The user access procedure in the preauthentication phase is the same as the user access procedure in the bind authentication mode. This phase does not involve 802.1X authentication.

· In the postauthentication phase:

After an IPoE user comes online in the preauthentication domain, the system determines the processing method in the postauthentication domain according to the authentication result of the 802.1X client as follows:

¡ If the 802.1X client of the user is already online, IPoE uses the 802.1X authentication result to have the user come online directly in the postauthentication domain. In this case, the recorded user information is the 802.1X user information, including the 802.1X username, authentication domain, and authorized attributes.

¡ If the 802.1X client of the user is not online, the IPoE user stays in the preauthentication phase. When the 802.1X client of the user comes online, the processing is the same as that in the previous step.

¡ When both 802.1X authentication and Web authentication are configured on an interface, the following rules apply:

- If an IPoE user has come online in the postauthentication domain through Web authentication before the 802.1X client comes online, the device will force the user to return to the preauthentication domain from the postauthentication domain of Web authentication after the 802.1X client comes online, and then the user uses 802.1X authentication to come online in the postauthentication domain of 802.1X authentication.

- After an IPoE user uses 802.1X authentication to come online in the postauthentication domain, the user cannot use Web authentication to come online in the postauthentication domain.

When 802.1X authentication is prioritized, the following rules apply when an IPoE user tries to come online in the preauthentication phase:

· If the 802.1X client of the IPoE user is not online, the IPoE user will stay in the state before the preauthentication phase. After the 802.1X client of the user comes online, IPoE uses the 802.1X authentication result to have the user come online directly in the postauthentication domain. In this case, the recorded user information is the 802.1X user information, including the 802.1X username, authentication domain, and authorized attributes.

· If the 802.1X client of the IPoE user is already online, IPoE uses the 802.1X authentication result to have the user come online directly in the postauthentication domain. In this case, the recorded user information is the 802.1X user information, including the 802.1X username, authentication domain, and authorized attributes.

· If the 802.1X client of the IPoE user fails to pass authentication, the IPoE user continues to come online through the IPoE authentication process. In this case, the recorded user information is the IPoE user information, including the IPoE username, authentication domain, and authorized attributes.

IPoE access procedure by using bind authentication in CUPS mode

Access procedure for DHCP single-stack users

This section uses a DHCPv4 user as an example to illustrate the access procedure for DHCP single-stack users.

Figure 7 Access procedure for a DHCPv4 user

‌

1. The DHCP client sends a DHCP-DISCOVER message to the UP.

2. The UP sends the message to the CP over the VXLAN tunnel.

3. The CP sends the AAA server an access request that includes user information, such as the client ID and source MAC address.

4. The AAA server returns an Access-Accept packet that contains authorization information to the CP if the authentication succeeds.

If the authentication fails, the AAA server returns an Access-Reject message.

5. The CP marks the IPoE session state as success and forwards the DHCP-DISCOVER message to the DHCP server if the authentication succeeds.

If the authentication fails, the CP marks the session as failure and drops the DHCP-DISCOVER message.

6. The DHCP server sends a DHCP-OFFER message to the CP.

7. The CP forwards the DHCP-OFFER message to the UP over the VXLAN tunnel. The UP forwards the DHCP-OFFER message to the DHCP client.

8. The DHCP client sends a DHCP-REQUEST message to the UP.

9. The UP forwards the DHCP-REQUEST message to the CP. The CP forwards the DHCP-REQUEST message to the specified DHCP sever.

10. The DHCP server sends a DHCP-ACK message containing the assigned IP address to the CP.

11. The CP performs the following operations:

a. Obtains address information from the DHCP-ACK message.

b. Assigns a user profile.

c. Updates the IPoE session information.

d. Marks the session state as online.

If the authentication fails, the CP marks the session as failure and drops the DHCP-DISCOVER message.

12. The CP forwards the DHCP-ACK message to the UP over the VXLAN tunnel.

13. The UP sends the DHCP-ACK message to the client.

14. The DHCP client obtains configuration information from the DHCP-ACK message.

15. The CP synchronizes the IPoE session information to the UP over the CUPS channel. The UP periodically collects traffic statistics, and sends the traffic statistics to the CP over the CUPS channel.

16. The CP sends the AAA server a message to start accounting.

Access procedure for DHCP dual-stack users

This section illustrate the access procedure for DHCP dual-stack users.

Figure 8 Access procedure for a DHCP dual-stack user

‌

1. The DHCPv4 client sends a DHCP-DISCOVER message to the UP.

2. The UP sends the message to the CP over the VXLAN tunnel.

3. The CP creates an IPoE session. The CP sends the AAA server an access request that includes user information, such as the client ID and source MAC address in DHCP packets.

4. The AAA server returns an Access-Accept packet that contains authorization information to the CP if the authentication succeeds.

If the authentication fails, the AAA server returns an Access-Reject message.

5. The CP obtains the user authentication and authorization result, and updates the session status to success or failure.

6. The CP forwards the DHCP-DISCOVER message to the DHCP server if the authentication succeeds.

If the authentication fails, the CP drops the DHCP-DISCOVER message.

7. The DHCP server sends a DHCP-OFFER message to the CP. The CP forwards the DHCP-OFFER message to the UP over the VXLAN tunnel. The UP forwards packets to the DHCP client.

8. The DHCP client sends a DHCP-REQUEST message to the UP. The UP forwards the DHCP-REQUEST message to the CP. Then, the CP forwards the DHCP-REQUEST message to the specified DHCP sever.

9. The DHCP server sends a DHCP-ACK message containing the assigned IP address to the CP.

10. The CP performs the following operations:

a. Obtains address information from the DHCP-ACK message.

b. Assigns a user profile.

c. Updates the IPoE session information.

d. Marks the session state as online.

11. The CP forwards the DHCP-ACK message to the UP.

12. The UP forwards the DHCP-ACK message to the DHCP client. The DHCP client obtains configuration information from the DHCP-ACK message.

13. The CP synchronizes the IPoE session information to the UP over the CUPS channel. The UP periodically collects traffic statistics, and sends the traffic statistics to the CP over the CUPS channel.

14. The CP sends the AAA server a message to start accounting.

15. The DHCPv6 client sends a Solicit message to the UP. The UP forwards the message to the CP over the VXLAN tunnel. The CP updates IPoE session information based on the Solicit message.

16. The DHCPv6 server responds with an Advertise message. The CP forwards the Advertise message to the UP over the VXLAN tunnel. Then, the UP forwards the Advertise message to the DHCPv6 client.

17. The DHCPv6 client select a DHCPv6 server according to the Advertise message and sends a request to the UP. The UP forwards the request to the CP over the VXLAN tunnel. The CP forwards the request to the DHCPv6 server.

18. The DHCPv6 server responds with a reply message.

19. The CP parses the IPv6 address and other address parameters in the reply message, and updates the IPoE session.

20. The CP forwards the reply message to the UP. The UP forwards the reply message to the DHCPv6 client. The DHCPv6 client obtains the IPv6 address and related address parameters.

21. The CP synchronizes the IPoE sessions information to the UP through the CUPS channel.

Access procedure for IPv6 ND RS users

This example uses a Layer 2 device as the BRAS.

Figure 9 Access procedure for IPv6 ND RS users

‌

1. The host sends an IPv6 ND RS packet to the UP. The UP sends the packet to the CP.

2. The CP initiates an IPoE session and sends the AAA server an access request that contains user information, such as the source MAC address.

3. The AAA server returns an Access-Accept packet that contains authorization information to the CP if the authentication succeeds.

If the authentication fails, the AAA server returns an Access-Reject message, and the CP marks the session as failure and drops the IPv6 ND RS packet.

4. The CP performs the following operations:

a. Generates an IPv6 address based on the host's MAC address and the IPv6 prefix.

b. Updates the IPoE session information.

c. Marks the session as success.

5. The CP sends the UP an IPv6 ND RA packet containing the IPv6 prefix. The UP sends the IPv6 ND RA packet to the host.

6. The host generates an IPv6 address based on the received IPv6 prefix.

7. The CP synchronizes the IPoE session information to the UP over the CUPS channel. The UP periodically collects traffic statistics, and sends the traffic statistics to the CP over the CUPS channel.

8. The CP sends the AAA server a message to start the service accounting.

Access procedure for unclassified-IP users

Figure 10 Access procedure for unclassified-IP users

‌

1. The host sends an IP packet to the UP.

2. The UP obtains user information from the IP packet, and compares the user information with existing IPoE sessions.

¡ If no match is found, the UP sends the IP packet to the CP. (This section uses this case as an example.)

¡ If the information matches an authenticated session, the UP forwards the IP packet.

¡ If the information matches an unauthenticated session, the UP drops the IP packet.

3. The CP creates an IPoE session and records user information based on the received IP packet.

4. The CP sends the AAA server an access request containing the obtained information, such as the source IP address or source MAC address.

5. The AAA server returns an Access-Accept packet that contains authorization information if the authentication succeeds.

If the authentication fails, the AAA server returns an Access-Reject message.

6. The CP assigns a user profile and marks the IPoE session state as online.

7. The CP synchronizes the IPoE session information to the UP over the CUPS channel. The UP periodically collects traffic statistics, and sends the traffic statistics to the CP over the CUPS channel.

8. The CP sends the AAA server a message to start the service accounting.

Access procedure for static and leased users

The access procedure for static users is the same as that for unclassified-IP users except in the following aspects:

· The IPoE static session is configured at the CLI.

· The IPoE static session can be initiated by IP, ARP, NS, or NA packets.

The access procedure for interface/subnet-leased users is the same as that for unclassified-IP users except in the following aspects:

· The IPoE interface/subnet-leased session is configured at the CLI.

· The IPoE interface/subnet-leased session does not need to be initiated by packets. Users are not required to send IP packets to trigger authentication. The BRAS initiates user authentication based on the configured username and password.

IPoE access procedure by using Web authentication in CUPS mode

NOTE:

· IPoE Web authentication users support only session mode.

· In all access procedures in this section, a CP operates in session mode.

‌

IPoE Web authentication applies to DHCP users, IPv6 ND RS users, and static individual users. The authentication process includes two phases: preauthentication and Web authentication.

Preauthentication access procedure

The access procedure in the preauthentication phase is the same as the access procedure by using bind authentication for users in CUPS mode. For more information about the access procedure, see "Access procedure for DHCP single-stack users," "Access procedure for IPv6 ND RS users," and "Access procedure for static and leased users."

Web authentication access procedure

In the Web authentication phase, the authentication procedure is basically the same for users. This section uses a DHCP user as an example to illustrate the access procedure by using Web authentication.

Figure 11 Web authentication access procedure

The user can perform Web authentication through the Web browser or the iNode client. This section uses the Web browser as an example.

1. The DHCP client initiates an HTTP/HTTPS GET message to the UP.

2. The UP checks the destination IP address of the HTTP/HTTPS GET message.

¡ If the message is destined for the portal Web server, the UP forwards the message to the portal Web server. The DHCP client directly accesses the Web authentication page of the portal Web server.

¡ If the message is not destined for the portal Web server, the UP sends the message to the Web authentication page of the portal Web server. The UP sends the message that contains the Web server URL information obtained to the DHCP client.

3. The DHCP client automatically accesses the Web server URL based on configured Web server URL information.

4. The portal Web server sends the Web authentication page to the DHCP client.

5. The user enters a username and password on the page and clicks Log in to send the authentication information to the portal Web server.

6. The portal Web server forwards the Web authentication information to the CP.

7. The CP sends the AAA server an access request based on the Web authentication information.

8. The AAA server returns to the CP one of the following results:

¡ An Access-Accept packet that contains authorization information if the authentication succeeds.

¡ An Access-Reject message if the authentication fails.

9. The CP updates the IPoE session state based on the received result.

10. The CP synchronizes the IPoE session information to the UP over the CUPS channel. The UP periodically collects traffic statistics, and sends the traffic statistics to the CP over the CUPS channel.

11. If the authentication succeeds, the CP sends the AAA server a message to start accounting.

NOTE:

‌

IPoE quick Web authentication in CUPS mode

Depending on the IP address allocation methods, transparent MAC authentication includes the following types:

When re-DHCP transparent MAC authentication is configured, IPoE triggers preauthentication and queries the MAC binding for a user when receiving DHCP-DISCOVER (IPv4) or Solicit (IPv6) packets.

Transparent MAC-trigger authentication procedure

IMPORTANT:

Transparent MAC-trigger authentication supports only Web authentication that is triggered through the Web browser.

‌

1. The client initiates HTTP/HTTP requests after coming online in the preauthentication domain.

2. The BRAS checks the destination IP of the HTTP/HTTPS request. For ease of description, the BRAS refers to the CUPS system formed by CP and UP.