WO2008010184A2

WO2008010184A2 - Ip address assignment method based on dhcp extension options

Info

Publication number: WO2008010184A2
Application number: PCT/IB2007/052836
Authority: WO
Inventors: Xiaofeng Peng
Original assignee: Utstarcom Telecom Co., Ltd
Priority date: 2006-07-17
Filing date: 2007-07-16
Publication date: 2008-01-24
Also published as: WO2008010184A3; CN100539595C; CN1889577A

Abstract

The present invention discloses an IP address assignment method based on DHCP extension options, and relates to the broadband communication and computer network field, and is applicable to an IP address assignment system comprising a DHCP+ client, a DHCP+ server and a AAA server. The present invention uses a manufacturer self-defined option field, i.e. Option 60, among a plurality of extension options provided by the standard DHCP to achieve a secure authentication function of the DHCP, including a discovering process, an authenticating and checking process on the Option 60 field, a provision process, an Option information extracting and checking process, a selecting process, an authentication control process by use of the Option 60 and an acknowledging process, so as to achieve the object of securely and reliably assigning the network IP addresses. The present invention can achieve controlled IP assignment protocols besides PPP, and can replace the BRAS devices so as to reduce the dependence of the network on the BRAS and greatly reduce the cost of rebuilding the network.

Description

IP Address Assignment Method Based on DHCP Extension Options

FIELD OF THE INVENTION

The present invention relates to an IP address assignment method in a broadband communication and computer network field, and more particularly, to an IP address assignment method based on DHCP (Dynamic Host Configuration Protocol) extension options.

BACKGROUND OF THE INVENTION

With the popularity of the Internet, the IP network has been extremely developed in recent years, and use of the IP protocol as a basic protocol for network communication gradually becomes a common knowledge in the broadband communication network field and the computer network field.

The IP network communication must be performed by first obtaining an IP address, and the IP network resource cannot be used without the IP address. However, the IP address is a limited, precious resource in the broadband network and is a base for providing broadband services. Thus, a reasonable, ordered assignment and distribution of the IP addresses is often combined with the communication network access grant control, to collectively control the IP network usage grant of the user. The issues concerning how to securely, reliably and conveniently assign the IP addresses to improve an assignment utilization efficiency of the IP address as far as possible and perform access control on the user and reduce the influence of the IP address assignment mechanism on the operation and cost of the IP network communication as far as possible, is always an important factor to influence usage and deployment of the IP network and becomes a focal problem of the most attention in the IP network technical field and an important task of the technical innovation.

The existing IP address assignment and access control generally comprises various modes such as PPP (Point-to-Point Protocol), DHCP, DHCP+WEB, 802. Ix and the like. However, due to restriction of usage occasions of some protocols and limitation of the protocols, at present, only PPP and DHCP (and its extension, e.g. DHCP+WEB) are most popular.

The PPP protocol, which is developed by Redback network Corporation, client software developer RouterWare Corporation and a sub-corporation of Worldcom, i.e. UUNET Technologies Corporation, based on the IETF RFC system, has a very good user management and control protocol, can perform user authorization access and authentication well, and can perform accurate and rich access grant control on the user through the support of the extension protocol of i Radius/Radius+. However, the use of the PPP protocol has the following defects: 1) the protocol per se consumes about 3% bandwidth overhead on average (in the model such as a continuous video streaming service, the accumulating effect of the bandwidth overhead is very obvious), and PPP will generate a large amount of broadcasting flow in the discovering stage, which will greatly influences the network performance; 2) the protocol needs expensive BRAS devices, and traffic data streams must flow through the BRAS devices after authentication, which readily results in single-point bottleneck and fault, and has insufficient capability of support of newly emerging services (e.g. video streaming media services). In particularly, the existing mainstream BRAS devices have a certain deficiency with respect to the performance and function of the streaming media services; 3) the operator are required to provide a client software, which results in too large maintenance amount. Therefore, the PPP has a seriously low performance-price ratio when facing newly emerging services.

The DHCP protocol (see RFC document RFC2131/RFC2132 for details) that is designed by the IETF (Internet Engineering Task Force) is an extension of BOOTP (Bootstrap Protocol, see RFC951 for details), is based on a C/S (Client/Server) model and provides a mechanism for dynamically designating IP addresses and network configuration. In the dynamic configuration mechanism, after the DHCP client leases an IP address from the DHCP server for the first time, it does not permanently use this address and will release this IP address as soon as the due date of the lease comes. DHCP allows the DHCP client to dynamically assign an IP address for the DHCP client from an IP address database at the DHCP server in the local network, so as to avoid a configuration effort possibly caused by manually inputting an IP address at each computer, improve the configuration efficiency, help to prevent the configured IP addresses from conflicting with each other, and greatly reduce the time required for configuring and re-configuring the IP address of the computer.

Although DHCP is a relatively simple IP address assignment manner convenient in management and use without extra message packaging overhead, the standard DHCP protocol does not verify the qualification of the terminal user, thus it is not a very reliable and secure IP address assignment method. Further, the standard DHCP protocol cannot give suitable network right control based on user information features, saying nothing of the authorized access. The extension of DHCP, e.g. DHCP+WEB, solves the problem of the authorized access by taking a certain measure, which extension cannot be truly secure and reliable, because it still fails to solve the reliability of IP assignment and is complex and not standard. SUMMARY OF THE INVENTION

The object of the present invention is to provide an IP address assignment method based on DHCP extension options to achieve a secure and reliable assignment of the IP address and efficiently achieve IP network access grant authentication of users in combination with various gateway devices. The present invention makes sure that this extension have a largest downward compatibility with the standard DHCP protocol and IP network.

Relevant protocol improvements proposed in the invention will be referred to as DHCP+ protocol below, to show that the present invention is an extension based on the standard DHCP.

The object of the invention is achieved as follows: an IP address assignment method based on DHCP extension options, which method is applicable to an IP address assignment system comprising a DHCP+ client with an authentication function added, a DHCP+ server with an authentication authorization support added and a AAA server, characterized in that said method comprises:

(1) a discovering process, in which the DHCP+ client sends a DHCPDISCOVER message containing an Option 60 field to the network by means of broadcasting, to find the DHCP+ server;

(2) an authenticating and checking process, in which the DHCP+ server receives the DHCPDISCOVER message and determines whether or not the message contains the Option 60 field, if yes, then checks whether or not the Option 60 field contains agreed identification information, otherwise, discards the DHCPDISCOVER message or processes it in the standard DHCP;

(3) a provision process, in which, if it is found by the checking that the Option 60 field contains the agreed identification information, the DHCP+ server selects one IP address from IP addresses which have not been assigned and sends an IP address release (DHCPOFFER) message containing the selected IP address and the Option 60 field to the DHCP+ client;

(4) an information extracting and checking process, in which the DHCP+ client extracts information from the Option 60 field in the DHCHOFFER message, and then checks whether the agreed field sent from the DHCP+ server is legal, and discards it if it is illegal;

(5) a selecting process, in which, if the Option 60 field contained in the DHCPOFF is determined to be legal by the checking, the DHCP+ client sends a DHCPREQUEST message containing the Option 60 field to the DHCP+ server by means of broadcasting, and requests the selected DHCP+ server to assign an IP address;

(6) an authentication control process, in which the DHCP+ server sends the user identification information contained in the Option 60 field in the received DHCPREQUEST message to the AAA server, the AAA server performs authentication control according to the user information and returns corresponding success/failure control information to the DHCP+ server, and

(7) an acknowledging process, in which, if what is returned is the success control information, the DHCP+ server sends to the DHCP+ client the DHCPPACK message containing the assigned IP address and the Option 60 field, and if what is returned is the failure control information, the DHCP+ server sends a DHCPNACK message and inserts success/failure code information into the Option 60 field.

The present invention uses the manufacturer self-defined option field Option 60, among a plurality of extension option supports (see RFC2132, etc.) provided by the standard DHCP to achieve the secure authentication function of the DHCP, so as to achieve the secure and reliable assignment of the network IP address. Further, the invention can be further combined with various gateway devices to efficiently achieve IP network access grant authentication of users, and makes sure that this extension has a largest downward compatibility with the standard DHCP protocol and IP network. Compared with the prior art, the present invention achieves a controlled IP assignment protocol besides PPP, and can replace the BRAS devices so as to reduce dependence of the network on the BRAS and greatly reduce the cost of rebuilding the network, thereby promoting the IP network operators to rebuild the network and actively developing IPTV services.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig.1 is a flowchart of the invention showing the IP address assignment for the first time; and

Fig.2 is a flowchart showing reletting and releasing of the IP address in the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A standard DHCP protocol provides many extension option supports (see RFC2132, etc.). These extension options enable various manufacturers to extend usage functions of the DHCP protocol to take particular actions such as carrying participation identifier, carrying user information and carrying position information, and thus can function as a channel for delivering control information, which provides us with a possibility to rebuild the DHCP protocol and provide the authentication mechanism. If extension functions defined by the Option have been recognized and accepted by the industries, they are acknowledged in the form of RFC to be recommended or established standards, for example, Option 82 is one of standards acknowledged in RFC3046.

In view of many extension fields of the Standard DHCP, by taking the compatibility of DHCP+ with DHCP as far as possible into consideration, Option 60 is chosen as the extension. Option 60 is set to an option field self-defined by the manufacturer in RFC, whose contents and functions can be self-determined by the manufacturers, thus, the compatibility of Option 60 is the best.

The present invention uses the extension option of Option 60 to achieve the secure authentication function of the DHCP.

Fig.1 is a flowchart of the invention showing the IP address assignment for the first time. As shown in the figure, the method of the invention can be applied in an IP address assignment system comprising a DHCP+ client, a DHCP+ server and a AAA server, wherein the DHCP+ client is a client with an authentication function added, the DHCP+ server is a server with the authentication authorization support added and comprises a standard DHCP processing module and an AAA processing module that is a software module responsible for processing authentication and authorization in the DHCP+ server, and the AAA server is an authentication server mainly responsible for storing user information and providing it to the DHCP+ server for authentication inquiry.

AAA refers to Authentication, Authorization and Accounting, wherein:

Authentication: the AAA server compares user information stored in the database with user identity contained in an authentication request from the terminal user to determine whether or not the user identity is legal;

Authorization: defines rights and services that can be enjoyed by the user after being granted to access the network;

Accounting: collects information on the use of the resources of the user for accounting.

As shown in Fig.1, processes A, B, C and D are flows of a standard DHCP , and processes 1-15 are flows of a DHCP+ extension protocol , which will be explained below.

In the process 1, the DHCP+ client generates manufacturer identification information, or generates identification information agreed with the DHCP+ server, through which identification information the server can identify whether or not the DHCP+ client supports the DHCP+ authentication, so as to form an Option 60 field and insert it into a DHCPDISCOVER message to be sent to the server.

The process A is a discovering process in the standard DHCP, in which the DHCP+ client sends the DHCPDISCOVER message containing the Option 60 field to the network by means of broadcasting, to find the DHCP+ server. In the process 2, the DHCP+ server receives the DHCPDISCOVER message sent from the DHCP+ client and uses the standard DHCP processing module to authenticate whether or not there exists the Option 60 field in the message. If the message does not carry the Option 60 field, the message is discarded, or in the case that the DHCP+ server is compatible with the standard DHCP, processing is performed according to the standard DHCP.

Then in the process 3, after authentication, if the DHCPDISCOVER message contains the Option 60 field, the standard DHCP processing module sends the DHCPDISCOVER message to the AAA processing module and registers an MAC address of the corresponding DHCP+ client.

In the process 4, the AAA processing module identifies the Option 60 field information in the DHCPDISCOVER message to check whether it is the manufacturer identifier or the previously agreed identification field.

If the result of the check is positive, the flows proceed to the process 5, in which the AAA processing module generates an encrypting key and returns it to the standard DHCP processing module. The key corresponds to the MAC address of the DHCP+ client one-to-one to handle with the situation where many DHCP+ clients are processed simultaneously. If the result of the check is negative, the AAA processing module returns an error code information to the standard DHCP processing module. If the system is compatible with the standard DHCP protocol, a success message or a specially defined code message can also be returned.

In the process 6, if the standard DHCP processing module obtains the error code information, it discards the message; otherwise, the obtained key is inserted into the Option 60 field in the DHCPDISCOVER message to be sent to the DHCP+ client. The server identifier can also be carried in the Option 60 at the same time to facilitate the DHCP+ client to judge whether the DHCPOFFER message is sent by the agreed DHCP+ server.

The processes 2-6 in fact form an authentication and check process in the invention.

The process B is a standard DHCP provision process, in which the DHCP+ server selects one IP address from IP addresses which have not been assigned and sends an IP address release (DHCPOFFER) message containing the selected IP address and the Option 60 field to the DHCP+ client.

The subsequent process 7 is an information extracting and checking process, in which the DHCP+ client extracts information from the Option 60 in the DHCHOFFER message, and if the Option 60contains an agreed field sent from the server, then the field is checked to determine whether or not it is legal, and discards it if it is illegal. If the Option 60 field is legal, the DHCP+ client obtains the key therein, and uses the key to encrypt the user name/cryptogram information stored in the DHCP+ client according to a predetermined encrypting algorithm, to obtain an encrypted information filed and write it into the Option 60 field in the DHCPREQUEST message to be sent to the server.

For the selection of the encrypting algorithm, a plurality of preset algorithms can be provided and stored in the client and server, and one of the algorithms is randomly selected by the client when the authentication is performed. In the previous process 1, the code name of the algorithm is sent to the sever which then registers the code name and selects an encrypting algorithm.

The process C is a selecting process in the standard DHCP, in which the DHCP+ client sends a DHCPREQUEST message containing the Option 60 field to the DHCP+ server by means of broadcasting, and requests the selected DHCP+ server to assign an IP address.

In the process 8, the standard DHCP processing module extracts the Option 60 field from the sent DHCPREQUEST message and sends it to the AAA processing module.

The subsequent process 9 is a decrypting process, in which the AAA processing module uses the key generated in the previous process 5 to decrypt the encrypted information in the Option 60 field, so as to restore the user name and cryptogram information in a plain text.

The process 10 and the process 11 are authentication control processes in the invention. In the process 10, the AAA processing module sends user identification information such as the user name, cryptogram and MAC to the AAA server (using Radius protocol or other protocols). In the process 11, the AAA server performs authentication control according to the user information and returns corresponding control information such as success and failure to the AAA processing module of the DHCP+ server. This process can define detailed codes to distinguish different situations.

In the process 12, the AAA processing module receives the information returned by the AAA server, takes necessary actions such as local log registration, and returns a success/error code to the standard DHCP processing module, wherein this error code is not necessarily the same as the code between the AAA server and the AAA module.

In the subsequent process 13, the standard DHCP processing module decides whether a DHCPPACK message or a DHCPNACK message is sent to the DHCP+ client according to the returned success/failure information, and inserts the error code information into the Option 60 field.

The process D is an acknowledging process in the standard DHCP. That is, if what is returned is the success control information, the DHCP+ server sends to the DHCP+ client the DHCPPACK message containing the assigned IP address, and if what is returned is the failure control information, the DHCP+ server sends the DHCPNACK message. Finally, as shown in the process 14, if the DHCP+ client receives the DHCPNACK message, the DHCP+ client displays to the final user the cause of the error according to the error information contained in the Option 60 field.

Fig.2 shows an IP address reletting flow and an IP address releasing flow in the invention. As shown in Fig.2, the reletting flow Sl comprises the processes 7-14 that are the same as the above described IP address assignment for the first time, except that if there is an error (e.g. failed authentication), a different error code and information are returned and different information is displayed by the client with respect to the error description.

The IP address releasing flow S2 comprises the processes 15-18.

The process 15: the DHCP+ client initiatively sends an IP releasing request.

The process E: the DHCP+ client sends a DHCPRELEASE message to the DHCP+ server.

The process 16: the standard DHCP processing module reclaims the IP address according to the MAC address information of the client, and delivers the release information and the MAC information of the client to the AAA processing module.

The process 17: the AAA processing module sends user identification information such as MAC, user name and cryptogram of the client to the AAA server, and removes user online information saved by itself and take corresponding actions such as log registration.

The process 18: the AAA server registers user offline information, and generates log and a list of call, etc..

The above DHCP+ flow is a common embodiment. In actual implementation, some processes may be flexibly cancelled according to specific applications, for example, if the encryption of the user name and cryptogram is not required, the encrypting process can be omitted.

The problem on whether or not the invention can support Option 82 now will be described. Option 82 is an extended definition for locating user positional information, determined by RFC3046, and the authentication function can be achieved to a certain extent by means of defining positional options of the user by the Option 82. The Option 82 is generally inserted by a network device (e.g. DSLAM) to the Option field in the DHCP message. Therefore, if only the AAA server supports Option 82 information authentication, the invention can also support Option 82 authentication. For example, if only the corresponding interface and information are well-defined, the DHCP+ server can select one from the Option 60 and Option 82, or send them together to the AAA server to be authenticated by the AAA server.

The invention may also be compatible with the standard DHCP flow. The DHCP+ server and the DHCP+ terminal, if only provided with a configuration command switch, can select to support the standard DHCP flow or a compatible mode in which both the standard DHCP flow and the DHCP+ flow can run. If the DHCP+ server selects the standard mode, then it may not process the Option 60 or Option 82, and the AAA processing module does not operate at this time. Similarly, the DHCP+ client does not send a message carrying the Option 60 and does not detect the agreed information in the Option 60 information. If the DHCP+ server and the DHCP+ client are set to the compatible mode uses both the standard DHCP flow and the DHCP+ flow, how to process the message is decided according to whether or not the Option 60 is an agreed identification. If it is the standard DHCP, the message is processed according to the DHCP flow and if it is the agreed DHCP+, the message is processed according to the DHCP+ flow.

If the DHCP+ protocol is integrated into a Router and L3 Switch in the IP communication network and achieves the combination of the DHCP+ and network access authorization by the following manner, a complete access grant management function of the user can be achieved to reach the control effect of using the PPP protocol by BRAS:

(1) the router or L3 acts as a gateway for the user to access the network resource and supports the DHCP+ server function;

(2) the user uses the DHCP+ protocol to request an IP;

(3) If the DHCP+ authentication is failed, then the gateway does not assign an IP address to the user and does not give the user any right (or partial right) to access the network.

Claims

1. An IP address assignment method based on DHCP extension options, which method is applicable to an IP address assignment system comprising a DHCP+ client with an authentication function added, a DHCP+ server with an authentication authorization support added and a AAA server, characterized in that said method comprises:

2. An IP address assignment method according to Claim 1, characterized in that, the DHCP+ server used by the method comprises a standard DHCP processing module and an AAA processing module responsible for processing authentication and authorization.

3. An IP address assignment method according to Claim 2, characterized in that, before the discovering process, the DHCP+ client generates manufacturer identification information, or generates identification information agreed with the DHCP+ server, through which identification information the server can identify whether or not the DHCP+ client supports the DHCP+ authentication, so as to form an Option 60 field and insert it into the DHCPDISCOVER message to be sent to the server.

4. An IP address assignment method according to Claim 3, characterized in that, in the authenticating and checking process, after the DHCP+ server receives the DHCPDISCOVER message sent from the DHCP+ client, the standard DHCP processing module determines whether or not there exists the Option 60 field in the message.

5. An IP address assignment method according to Claim 4, characterized in that, in the authenticating and checking process, if the DHCPDISCOVER message contains the Option 60 field, the standard DHCP processing module sends the DHCPDISCOVER message to the AAA processing module and registers an MAC address of the corresponding DHCP+ client.

6. An IP address assignment method according to Claim 1, characterized in that, in the authenticating and checking process, the AAA module identifies the Option 60 field information in the DHCPDISCOVER message, and checks whether or not it contains the manufacturer identifier or the previously agreed identification field.

7. An IP address assignment method according to Claim 6, characterized in that, in the authenticating and checking process, if the result of the checking of the Option 60 field is positive, the AAA processing module generates an encrypting key one-to-one corresponding to the MAC address of the DHCP+ client; otherwise, the AAA processing module returns an error code information to the standard DHCP processing module.

8. An IP address assignment method according to Claim 7, characterized in that, in the authenticating and checking process, if the standard DHCP processing module obtains the error code information, it discards the message; otherwise, it inserts the obtained key into the Option 60 field in the DHCPDISCOVER message to be sent to the DHCP+ client.

9. An IP address assignment method according to Claim 1 or 8, characterized in that, in the provision process, the Option 60 field in the DHCPOFFER message sent by the DHCP+ server can further comprise the DHCP+ server identifier to facilitate the DHCP+ client to judge whether or not the DHCPOFFER is sent by the agreed DHCP+ server.

10. An IP address assignment method according to Claim 9, characterized in that, in the information extracting and checking process, if the Option 60 field is legal, then the DHCP+ client obtains the key, and uses the key to encrypt the user name and cryptogram information stored in the DHCP+ client according to a predetermined encrypting algorithm, to obtain an encrypted information filed and write it into the Option 60 field in the DHCPREQUEST message to be sent to the DHCP+ server.

11. An IP address assignment method according to Claim 10, characterized in that, in the authentication control process, after the DHCP+ server receives the DHCPREQUEST message sent by the DHCP+ client, the standard DHCP processing module extracts the Option 60 field therein and sends it to the AAA processing module, and the AAA processing module uses the key to decrypt the encrypted information to restore the user name and cryptogram information in a plain text.

12. An IP address assignment method according to Claim 11, characterized in that, in the authentication control process, the AAA server sends the user identification information such as user name, cryptogram and the MAC and the like to the AAA server to perform authentication control and returns corresponding success/failure control information.

13. An IP address assignment method according to Claim 12, characterized in that, in the acknowledging process, the AAA processing module receives the information returned by the AAA server, takes actions such as local log registration and the like, and returns a success/error code to the standard DHCP processing module.

14. An IP address assignment method according to Claim 13, characterized in that, in the acknowledging process, the standard DHCP processing module decides whether a DHCPPACK message or a DHCPNACK message is sent to the DHCP+ client according to the returned success/failure information, and inserts the error code information into the Option 60 field.

15. An IP address assignment method according to Claim 1, characterized in that, the method further comprises an IP address releasing process in which: the DHCP+ client initiatively sends an IP releasing request message DHCPRELEASE; the DHCP+ server reclaims the IP address according to the MAC address information of the client and delivers the release information and the MAC information of the client to the AAA processing module; the AAA processing module sends the user identification information such as the MAC, user name and cryptogram of the client and the like to the AAA server, and removes user online information saved by itself and take actions such as corresponding log registration and the like; and the AAA server registers user offline information, and generates a log and a list of call.

16. An IP address assignment method according to Claim 1, characterized in that, the AAA server used by the method also supports Option 82 information authentication, and the DHCP+ server can select one from the Option 60 and the Option 82, or send them together to the AAA server to be authenticated by the AAA server.