WO2009009972A1

WO2009009972A1 - Method and system for implementing authentication

Info

Publication number: WO2009009972A1
Application number: PCT/CN2008/070977
Authority: WO
Inventors: Amy Zhao
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-07-19
Filing date: 2008-05-15
Publication date: 2009-01-22
Also published as: CN101350809A

Abstract

A method and system for implementing authentication, the network side receiving a DHCP request message or a DHCP finding message taking a fasting validating option information coming from a dynamic host configuration protocol (DHCP) client, authenticating the DHCP client, and sending back the response message of successful authentication or not to the DHCP client, if the authentication is successful, then the network side sending back a DHCP validating message to the DHCP client, if the authentication is failed, then sending a DHCP un-validating message to the DHCP client.

Description

Method and system for realizing authentication

The present invention relates to Internet Protocol (IP) network technology, and in particular, to a method and system for implementing authentication in a Dynamic Host Configuration Protocol (DHCP). Background technique

In an all-IP network, user-based access authentication is essential, but some existing protocols do not provide authentication functions, such as DHCP. The existing DHCP is mainly used to assign an IP address to the user at the request of the user. Figure 1 shows the workflow of the existing DHCP. As shown in Figure 1, the following steps are included:

Step 101: The DHCP client sends a DHCP Discovery (DISCOVER) message to the DHCP server. When the DHCP client logs in to the network for the first time, it broadcasts a DHCP to the DHCP server on the network.

DISCOVER message to find the DHCP server.

Step 102: The DHCP server sends a DHCP Offer (OFFER) packet to the DHCP client. Each DHCP server with a free address in the network responds to the DHCP DISCOVER message sent by the DHCP client, and sends a DHCP OFFER message to the DHCP client, and the DHCP OFFER message "Your address (yiaddr) "The domain carries the provided network IP address and some DHCP options (options) configuration parameter information associated with the IP address.

Step 103: The DHCP client sends a DHCP Request (REQUEST) message to the DHCP server. The DHCP client selects a DHCP OFFER message from the received DHCP OFFER message sent by the multiple DHCP servers, for example, selecting the DHCP OFFER message sent by the first arriving DHCP server, and broadcasting a DHCP REQUEST message to Tell each DHCP server in the network that the DH CP client will specify which DHCP server provides the IP address.

Step 104: The DHCP server selected by the DHCP client sends DHCP to the DHCP client. Acknowledge (ACK) or DHCP unacknowledged (NAK).

If the IP address is configured successfully, the DHCP server sends a DHCP ACK packet to the DHCP client to confirm that the IP lease is valid. The DHCP ACK packet also carries some configuration parameters related to the IP address, and it is necessary to ensure that the configuration parameters in this step cannot conflict with the configuration parameters mentioned in step 102.

If the DHCP server cannot satisfy the DHCP client's request because the IP address requested by the DHCP client has been assigned to other DHCP clients, the DHCP server will send a DHCP NAK 4 message to the DHCP client to notify DHCP. The client IP address configuration failed.

After receiving the DHCP ACK message, the DHCP client can also send an Address Resolution Protocol (ARP) packet to the network to check whether there are other devices in the network that use the IP address. Yes, a DHCP DECLINE message is sent to the DHCP server, the configured IP address is rejected, and the D HCP DISCOVER message is resent.

In addition, except for the DHCP server selected by the DHCP client, other DHCP servers will reclaim the IP address they provided.

The DHCP workflow shown in Figure 1 is illustrated by DHCP version 4 (v4). If it is DHCPv6, except for the different types of packets, DHCP DISCOVER, DHCP OFFER, DHCP REQUEST and DHCP ACK are shown in Figure 1. In addition to the request (SOLICIT), ADVE RTISE, REQUEST, and REPLY messages, other workflows, such as message interaction and the functions of each message, are the same as DHCPv4.

As can be seen from the above description, there is no authentication function in the existing DHCP. Therefore, in order to improve security, it is desirable to introduce an existing authentication mechanism into DHCP.

Authentication Protocol, EAP ). EAP is an authentication framework that can support multiple authentication modes. EAP packets can be carried by different protocols, such as authentication, authorization, and accounting (AAA). The industry standard that carries EAP for authentication is defined in the Remote Authentication Dial In User Service (Radius) and the next-generation AAA protocol Diameter. EAP mainly includes four message formats, namely request, response, success, and failure (fai lure). FIG. 2 is a schematic diagram of an existing EAP message interaction manner. As shown in Figure 2, the EAP request and the EAP response are always in pairs. Moreover, the number of EAP request and EAP response pairs and the information carried by them are not fixed, and need to be determined according to the authentication method used in the actual application. .

A method of combining the DHCP and the EAP to implement user authentication has been proposed in the prior art. The method is to carry the EAP payload by adding a new DHCP format DHCPEAP, and the EAP method is used for authentication, and after the authentication succeeds. , assign the IP address and related parameters to the client.

FIG. 3 is a schematic diagram of a method for implementing user authentication in DHCP through EAP. As shown in Figure 3, the following steps are included:

Step 301: The DHCP client sends a DHCP DISCOVER message to the network access server (N AS).

The DHCP Discovery (DHCP DISCOVER) message in this step carries the DHCP_AUTH_pro to option, which is used to identify that the subsequent steps will use ΕΑΡ for authentication.

Step 302: The NAS sends a DHCPEAP packet to the DHCP client, where the payload carries an EAP request message.

Step 303: The DHCP client sends a DHCPEAP message to the NAS, and the payload carries an EAP response message.

Step 304: The NAS strips the EAP payload in the DHCP EAP, and carries the EAP payload in the AAA protocol, such as Radius, to the AAA server.

Depending on the EAP authentication method used, you may need to perform multiple information exchanges between the DHCP client, NAS, and AAA server in this step.

Step 305: The AAA server sends an authentication success packet to the NAS, such as an Access-Accept message in the Radius protocol. Step 306: The NAS sends a DHCP Offer (DHCP OFFER) message to the DHCP client.

The DHCP OFFER packet carries the IP address provided by the NAS to the DHCP client and related configuration parameter information.

The subsequent processing is the same as step 1 03 and step 1 04 shown in FIG. 1 and will not be described again. Although the method shown in Figure 3 implements user authentication in DHCP through EAP, this method has the following drawbacks:

First, in theory, after the DHCP client sends a DHCP DI SCOVER message, multiple DHCP servers will respond. In the existing DHCP protocol, the DHCP client selects from multiple OFF ERs received, but the method shown in Figure 3 does not address how this should be handled. Imagine that if all DHCP servers send OFFER after the authentication is completed and the DHCP client makes a selection, it will undoubtedly cause waste of resources, because authentication is a very time-consuming task. However, if the selection is made before the authentication, that is, when the DHCP client receives the first DHCPEAP message, then this is done after the DHCP client shown in FIG. 1 receives the OFFER message. Inconsistent selections require large changes to existing state machines and implementations, increasing the complexity of implementation.

In addition, if the authentication fails, the failure message also needs to be carried by the OFFER message. Thus, the "yi addr" field in the OFFER message loses its meaning. The DHCP client needs to check whether the authentication succeeds or fails before it can be checked. OFFER message, the same problem, is the need to make major changes to the existing state machine and implementation, increasing the complexity of the implementation.

Further, the method shown in Fig. 3 does not take into account the case of re-authentication, and the so-called re-authentication refers to repeated authentication due to various needs after the first authentication. Summary of the invention

The embodiment of the invention provides three methods for implementing authentication, which can implement the authentication mechanism in DHCP.

The embodiment of the invention simultaneously provides three systems for implementing authentication, which can be implemented in a single DHCP. Certification mechanism.

The technical solution of the embodiment of the present invention is implemented as follows:

A method of implementing authentication, the method comprising:

The network side receives the DHCP request packet from the DHCP client of the dynamic host configuration protocol, authenticates the DHCP client, and sends a response message to the DHCP client for the success or failure of the authentication.

A method of implementing authentication, the method comprising:

The network side authenticates the DHCP client that sends the packet to the DHCP client. If the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client. If the authentication fails, the DHCP client sends a DHCP unacknowledgment message to the DHCP client.

A method of implementing authentication, the method comprising:

The network side receives the DHCP discovery packet from the DHCP client, and the DHCP discovery packet carries the quick confirmation option information; the network side authenticates the DHCP client, and sends back the authentication success to the DHC P client. The response is 4 essays.

A system for implementing authentication, the system comprising: a DHCP client and a network side;

The DHCP client is configured to send a DHCP request message to the network side, and receive a response text of the authentication success or not sent by the network side;

The network side is configured to authenticate the DHCP client after receiving the DHCP request from the DHCP client, and send back a response to the DHCP client.

The DHCP client is configured to send a message to the network side, and receive a response message that the network side sends back the authentication success or not;

The network side is configured to authenticate the DHCP client, and if the authentication succeeds, send a DHCP confirmation message to the DHCP client; if the authentication fails, send back D to the DHCP client.

HCP did not confirm 4 essays. A system for implementing authentication, the system comprising: a DHCP client and a network side;

The DHCP client is configured to send, to the network side, a D HCP discovery message carrying the fast acknowledgment option information, and receive a response message that the network side sends back the authentication success or not; After receiving the discovery file from the DHCP client, the DHC P client is authenticated, and the response of the authentication success or not is sent back to the DHCP client.

It can be seen that, by adopting the technical solution of the embodiment of the present invention, after receiving the D HCP request message from the DHCP client or the DHCP discovery message carrying the fast acknowledgment option information, the network side authenticates the DHCP client and sends it back to the DHCP client. Response message for successful authentication. After the DHCP request packet is received or the DHCP discovery packet carrying the fast acknowledgment option information is received, the authentication process is triggered. That is, the DHCP client has obtained the address information or the DHCP client does not need to obtain the address according to the selected mode. In the case of information, the authentication process is triggered, so there is no problem of resource waste due to the use of the address information selection method in the prior art and the need to modify the existing state machine corresponding to this step. Further, in the solution of the embodiment of the present invention, if the authentication succeeds, the network side sends a DHCP acknowledgement message to the DHCP client. If the authentication fails, the network side sends a DHCP unacknowledged message to the DHCP client, that is, the current use. The result of the DHCP protocol confirms that the packet is sent back to the authentication result information, and the original message format does not need to be changed as in the prior art, thereby reducing the complexity of the implementation. DRAWINGS

Figure 1 is a schematic diagram of an existing DHCP workflow;

2 is a schematic diagram of an existing EAP message interaction manner;

FIG. 3 is a schematic diagram of a method for implementing user authentication in DHCP through EAP;

4 is a flow chart of a first embodiment of a method of the present invention;

Figure 5 is a flow chart of a second embodiment of the method of the present invention;

Figure 6 is a flow chart of a third embodiment of the method of the present invention;

Figure 7 is a flow chart of a fourth embodiment of the method of the present invention; Figure 8 is a schematic view showing the structure of a first embodiment of the system of the present invention. detailed description

The present invention will be further described in detail below with reference to the accompanying drawings.

In the embodiment of the present invention, the network side receives the DHCP request message from the DHCP client, authenticates the DHCP client, and sends a response message to the DHCP client for the success or failure of the authentication.

The above solution can be applied in different environments for authenticating DHCP clients:

(1) Initial authentication of the DHCP client:

Before receiving the DHCP request packet from the DHCP client, the network side further includes: D

The HCP client obtains the address information from the network side, and the specific information includes: the DHCP client sends a DHC P-discovery message to the network side; the network side sends a DHCP-provided message to the DHCP client, and the DHCP-provided message carries the information provided to the DHCP client. IP address and configuration parameter information.

(2) Re-authenticate the DHCP client:

In actual applications, re-authentication can be triggered by the DHCP client or by the DHCP server. Generally, the DHCP client needs to trigger re-authentication, including the following two types:

A. The DHCP client restarts. The details are divided into two cases:

The DHCP client records the IP address before the restart. The DHCP client sends a DHCP REQUEST to the DHCP server and carries the IP address to continue to use it. At the same time, it requests relevant configuration parameters.

Or, the DHCP client does not record the IP address before the restart. This situation is the same as the first authentication. It needs to send a DHCP DISCOVER to the DHCP server.

B, address update (renew):

When the DHCP client performs address update, it needs to be re-authenticated for security reasons or a means of periodic authentication.

The situation in which the DHCP server needs to trigger re-authentication mainly includes:

A. The DHCP server changes the policy of the accessed user for some specific reasons, or recovers the original The certification that comes.

B. The DHCP server needs to periodically request the DHCP client to re-authenticate for security reasons.

If the DHCP client triggers the re-authentication, the DHCP client will send a DHCP Request message to the network. After receiving the DHCP Request message, the network side authenticates the DHCP client.

If the network side triggers the re-authentication, the network side first sends a mandatory update message to the DHCP client. After receiving the forced update message, the DHCP client sends a DHCP request message to the network side. After receiving the DHCP request packet, the DHCP client is authenticated.

In the above process, the specific implementation process of authenticating the DHCP client on the network side will be different depending on the EAP authentication mode used.

After the authentication is complete, the network sends a response message indicating whether the authentication succeeds to the DHCP client. For example, if the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client. If the authentication fails, the DHCP client sends a DHCP acknowledgement message to the DHCP client. Text.

The invention will now be further described in detail by means of preferred embodiments:

4 is a flow chart of a first embodiment of a method of the present invention. Assume that E is adopted by the network side in this embodiment.

The AP authentication mode is the one-time pas sword (OTP) authentication method. Then, as shown in Figure 4, the following steps are included:

Step ⁴ 01: The DHCP client sends a DHCP discovery (DHCP DI SCOVER) to the NAS. In this embodiment, for convenience of description, the network side is specifically divided into two parts, a NAS and an AAA server according to its actual composition. Relative to the DHCP client, the NAS is a DHCP server or a DHCP proxy, and the NAS is an AAA client relative to the AAA server.

Step 402: The NAS sends a DHCP provision (DHCP OFFER) to the DHCP client.

The DHCP OFFER packet carries the IP address and related configuration parameter information provided to the DHCP client.

Since there may be multiple DHCP servers on the network side, each DHCP server may respond after receiving the DHCP DISCOVER from the DHCP client, that is, send DHCP back to the DHCP client. The OFFER packet, therefore, in this step, the DHCP client may receive multiple DHCP OFFE R packets at the same time.

Step ⁴ 0 ³ : The DHCP client sends a DHCP request (DHCP REQUEST) to the NAS.

The DHCP client sends a DHCP REQUEST message to the NAS to request the IP address and related configuration parameters.

If the DHCP client receives multiple DHCP OFFER messages in step 402, in this step, the DHCP client needs to select multiple DHCP OFFERs first, and select one of the IP addresses provided by the DHCP OFFER as its own IP address. How to select a DHCP client is the same as the prior art, and is not described here.

Step 404: The NAS sends a DHCPEAP packet to the DHCP client.

Because the DHCP client needs to be authenticated, the NAS sends a DHCPE AP message to the DHCP client, and carries an EAP Request message to request the ID of the DHCP client.

Step 405: The DHCP client sends a DHCPE AP^ message to the NAS.

The DHCP client carries its own ID in the EAP Response, and carries the EAP Response (EAP Resp onse) in the DHCPEAP and sends it to the NAS.

The process of requesting IDs in steps 404 and 405 is the process specified in the EAP authentication protocol.

Step 406: The NAS strips the EAP Response message in the DHCPEAP and sends it to the AAA server in the existing AAA protocol.

For example, an access request (Access-Request) in the existing AAA protocol Radius can be used to carry an EAP Response message.

Step 407: The AAA server generates an EAP Request (EAP Req uest) message carrying the challenge word information of the OTP, and carries the message to the NAS in the existing AAA protocol.

For example, an Access-Challenge message in the existing Radius protocol can be used to carry an EAP Request message.

Step 408: The NAS strips out the EAP Request message and sends it to the DHCP EAP packet to the D.

HCP client. Step 409: The DHCP client generates a response according to the received challenge word information, and carries the message in the EAP_Response message, and sends the message to the NAS through the DHCPEAP.

Step 410: The NAS strips the EAP-Response message in the DHCPEAP, and carries the message to the AAA server in the existing AAA protocol.

t匕: 3⁄4 port, you can use the existing AAA ten-handed Radius access request (Access_Request) to carry EAP Response (EAP Response) message.

Step 411: The AAA server authenticates the DHCP client according to the received challenge word response information, and sends back a response message indicating whether the authentication succeeds or not to the NAS.

The method for the AAA server to authenticate the DHCP client according to the challenge word response information is a prior art, and details are not described herein again.

According to the authentication result, the AAA server generates an EAP-Success message indicating that the authentication is successful or an EAP-Failure message indicating that the authentication is failed, and carries the message in the existing AAA protocol, such as access-accept or access. Access-Reject is sent to the NAS in the text.

Step 412: The NAS sends a DHCPAC K packet indicating that the authentication succeeds or a DHCPNAK packet indicating that the authentication is successful according to the authentication result.

Of course, according to the prior art, after the NAS is informed that the authentication is successful, the NAS needs to further confirm whether the DHCP client can use the IP address requested in step 403. If yes, send a DHCP ACK. If not, send the DHCPNAK4 message. .

For the person skilled in the art, the embodiments of the present invention are only specific ways of implementing the solution of the present invention, but are not intended to limit the technical solutions of the present invention. For example, for the foregoing embodiment, the EAP Request and the EAP Response message are not only allowed to be carried through the DHCPEAP packet, and other methods are also available as long as the same purpose can be achieved. For example, two separate packet types, DHCPEAPREQUEST and DHCPEAPRESPONSE, can be newly defined to carry EAP Request and EAP Response messages.

It should be noted that, in the embodiment shown in FIG. 4, the EAP authentication mode adopted by the network side is the OTP authentication mode. If other authentication modes are used, the EAP message interaction mode shown in FIG. 4 may be different. For example, the steps 404-405 are optional steps, which may be omitted. If the steps 404-405 are omitted, the NAS will carry the EAP-S tart message in the existing AAA protocol packet and send it to the AAA server. Steps 407 ~ 41 0 may need to be repeated multiple times. For example, in the authentication method such as Extended Protocol Authentication EEAP - Transport Layer Security TLS (Transport Layer TLS), it may be necessary to repeat the processes described in steps 407 ~ 41 0 .

The embodiment shown in FIG. 4 is an implementation flow when the DHCP client performs authentication for the first time. The following two embodiments are used to describe the implementation process when the DHCP client performs re-authentication.

Figure 5 is a flow chart of a second embodiment of the method of the present invention, in which re-authentication is triggered by a DHCP client. When the DHCP client needs to update the address or with the address request allocation parameter, it sends a DGCP request (DHCP REQUEST) message directly to the NA S.

Compared with FIG. 4, the difference between this embodiment and FIG. 4 is that the steps 401 and 402 in FIG. 4 are missing, that is, the process of discovering and providing an IP address, and steps 501 to 510 are the same as steps 403-412 shown in FIG. No longer.

Figure 6 is a flow chart of a third embodiment of the method of the present invention. The re-authentication in this embodiment is triggered by the network side, that is, in step 601, the network side sends a forced update (F0RCERENEW) message to the DHCP client; in step 602, 0? Received by the client? 0 £1^ After 4艮, send a DHCP REQUEST message to the NAS. Subsequent steps 603 - 61 1 are the same as steps 404 - 412 shown in Figure 4, and will not be described again.

Generally, the embodiments shown in FIG. 5 and FIG. 6 are used to implement re-authentication, but in some special cases, for example, the DHCP client does not need or does not need to perform authentication when initially accessing the network, and only needs to perform the diagram. The normal DHCP process shown in 1. When the DHCP client needs to be authenticated for the reasons mentioned in the DHCP client re-authentication situation, or the DHCP server needs to be authenticated for the reasons mentioned in the DHCP server re-authentication situation, although the authentication in these two cases belongs to The first certification, but the certification process is performed according to the process shown in Figure 5 or Figure 6.

Although the above three embodiments are different in specific implementation, there is a common point that the DHCP client sends a DHCP REQUEST to the network side to trigger the network side to perform authentication. Another authentication mode is provided in the embodiment of the present invention: The network side receives the DH from the DHCP client. The CP finds the packet, and the DHCP discovery packet carries the fast acknowledgment option information. The network side authenticates the DHCP client and sends a response to the DHCP client to verify the success or failure of the authentication. The method for the network side to send a response message to the DHCP client for the success or failure of the authentication includes: sending a DHCP acknowledgement message to the D HCP client if the authentication succeeds; and sending the DHCP unacknowledgment to the DHCP client if the authentication fails. Message. Moreover, the DHCP acknowledgement message further carries the address information provided by the network side to the DHCP client. The specific implementation is shown in Figure 7.

Figure 7 is a flow chart of a fourth embodiment of the method of the present invention. Compared with the embodiment shown in FIG. 4, the difference is: in the DHCP DI SCOVER message sent by the DHCP client to the NAS, the fast acknowledgment (rap id commi t) option information is carried in the step 701; after receiving the DHCP DI SCOVER, the NAS That is, authentication is performed, and the information exchange process of steps 401 and 402 shown in FIG. 4 is no longer needed. Moreover, before the NAS sends an acknowledgement packet to the DHCP client in step 71 0, it is necessary to confirm whether the IP address can be provided for the DHCP client. If the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client, and carries the address information provided to the DHCP client in the DHCP confirmation message. The remaining steps 702 ~ 709 are the same as steps 404 - 411 shown in Figure 4, and will not be described again.

Each of the above embodiments is described in the case where the default DHCP is DHCPv4, if DH is

The CPv4 is replaced by DHCPv6. The foregoing embodiments are equally applicable. The difference is that the packet type may be different. For example, in the embodiment in which the network side triggers re-authentication in FIG. 6, steps 601, 602, and 61 1 are changed accordingly. Re-created (Reconf i gure), Renew and Rep ly.

Based on the above method, FIG. 8 is a schematic structural diagram of a first embodiment of the system of the present invention. As shown in Figure 8, the system includes: a DHCP client 801 and a network side 802:

The DHCP client 801 is configured to send a DHCP request message to the network side 802, and receive a response message that the network side sends back the authentication success or not.

The network side 802 is configured to authenticate the DH CP client 801 after receiving the DHCP request message from the DHCP client 801, and send a response message to the DHCP client 801 for the success or failure of the authentication.

When the DHCP client 819 is initially authenticated by using the system shown in FIG. 8, the DHCP client 810 is further used to send the discovery message to the network side 802, and receive the address letter sent back by the network side 802. The network side 802 is further configured to receive the discovery packet of the DHCP client 801 and send back the address information to the DHCP client 801.

When the DHCP client 801 is re-authenticated by using the system shown in FIG. 8, the network side 802 may be further configured to send a mandatory update message to the DHCP client 801; accordingly, the DHCP client 801 receives the mandatory update report. After the text, the DHCP request message is sent to the network side 802.

After the network side 802 completes the authentication of the DHCP client 801, it sends a response message to the DHCP client 801, for example, if the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client. The DHCP unacknowledged message is sent back to the DHCP client.

On the basis of the technical solution of the embodiment, the DHCP client can also be used to send a DHCP discovery message carrying the fast acknowledgment option information to the network side 802, and receive the response of the authentication succeeded by the network side.

The specific configuration and workflow of the system embodiment shown in FIG. 8 are the same as the corresponding method embodiments, and will not be described again.

It can be seen that the technical solution of the embodiment of the present invention not only solves the problem of performing authentication and re-authentication on the DHCP client, but also implements the authentication, and basically does not need to modify the existing message format, compared to the prior art. , reducing the difficulty and complexity of implementation.

In conclusion, the above is only a preferred embodiment of the present invention and is not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and scope of the invention are intended to be included within the scope of the invention.

Claims

Claim

A method for implementing authentication, characterized in that the method comprises:

Receiving a DHCP request message from a dynamic host configuration protocol DHCP client DHCP REQUEST; authenticating the DHCP client;

Sending a response packet indicating whether the authentication succeeds or not to the DHCP client.

The method of claim 1, wherein the receiving the DHCP request from the DHCP client before the DHCP REQUEST further comprises: obtaining, by the DHCP client, the address information provided by the network side from the network side.

The method according to claim 2, wherein the step of obtaining, by the DHCP client, the address information provided by the network side from the network side comprises:

The DHCP client sends a DHCP discovery message to the network side, DHCP DISCOVER;

The network side sends back a DHCP provisioning DHCP OFFER to the DHCP client, and the D HCP provides a packet carrying an IP address and configuration parameter information provided to the DHCP client.

The method according to claim 3, wherein when the network side sends back more than one DHCP OFFER to the DHC P client, the method further includes:

The DHCP client selects an IP address from more than one IP address carried by the one or more DHCP providers, and the DHCP request is the address requested by the DHCP REQUEST.

The method according to claim 1, wherein before receiving the DHCP request message from the DHCP client, the method further includes:

Send a mandatory update message to the DHCP client.

The method according to claim 1, wherein the step of authenticating the DHCP client comprises:

The DHCP client is authenticated by using the extensible authentication protocol EAP authentication mode.

The method according to claim 1, wherein the step of sending back a response message of the authentication success to the DHCP client comprises: If the authentication is successful, sending a DHCP confirmation message to the DHCP client;

If the authentication fails, the DHCP unacknowledged message DHCP NAK is sent to the DHCP client.

The method according to claim 7, wherein the DHCP request message carries an address requested by the DHCP client;

Sending the DHCP confirmation message to the DHCP client specifically includes: confirming whether the DHCP client can use the requested address;

If yes, and the authentication is successful, a DHCP confirmation is sent to the DHCP client.

9. A method for implementing authentication, the method comprising:

The DHCP client that sends the packet is authenticated. If the authentication succeeds, the DHCP acknowledgement packet DHCP ACK is sent back to the DHC P client. If the authentication fails, the DHCP client is sent back to the DHCP client. DHCP NAK.

The method according to claim 9, wherein the DHCP client sends an address requested by the DHCP client;

The sending the DHCP acknowledgement message to the DHCP client specifically includes: confirming whether the DHCP client can use the requested address;

If yes, and the authentication is successful, a DHCP acknowledgment is sent back to the DHCP client.

11. A method for implementing authentication, the method comprising:

Receiving a DHCP discovery message DHCP DISCOVER from the DHCP client, the DHCP discovery message carries a quick confirmation option information;

Authenticating the DHCP client;

The method according to claim 11, wherein the step of sending a response message to the DHCP client for successful authentication includes:

If the authentication is successful, sending a DHCP acknowledgement message DHCP ACK to the DHCP client;

13. The method according to claim 11, wherein the method further comprises: determining whether an address can be provided for the client;

If the authentication succeeds, the DHCP client sends a DHCP confirmation message to the DHCP client, and carries the address information provided to the DHCP client in the DHCP confirmation message.

14. A system for implementing authentication, the system comprising: a DHCP client and a network side;

The DHCP client is configured to send a DHCP request to the network side, and receive a response from the network side, and receive a response from the network side.

The network side is configured to authenticate the DHCP client after receiving the DHCP request message from the DHCP client, and send a response message to the DHCP client for successful authentication.

The system according to claim 14, wherein the DHCP client is further configured to send a DHCP discovery message to the network side, and receive the address information provided by the network side;

The network side is further configured to receive DHCP discovery from the DHCP client.

DI SCOVER, and provides address information to the DHCP client.

The system according to claim 14, wherein the network side is further configured to send a forced update to the DHCP client.

After receiving the mandatory update text, the DHCP client sends a DHC P request to the network side. REQUEST.

17. A system for implementing authentication, the system comprising: a DHCP client and a network side;

The network side is configured to perform authentication on the DHCP client, and if the authentication succeeds, the

The DHCP client sends back a DHCP confirmation message; if the authentication fails, it sends a D back to the DHCP client. HCP did not confirm 4 essays.

18. A system for implementing authentication, the system comprising: a DHCP client and a network side;

The DHCP client is configured to send, to the network side, a D HCP discovery message carrying the fast acknowledgment option information, and receive a response message that the network side sends back the authentication success or not;

The network side is configured to: after receiving the discovery packet from the DHCP client, authenticate the DHCP client, and send a response packet of the authentication success to the DHCP client.