Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing
Reexamination Certificate
2000-05-03
2004-03-09
Najjar, Saleh (Department: 2157)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
C709S230000, C709S231000, C713S152000, C713S152000
Reexamination Certificate
active
06704789
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to methods for authenticating users (terminals in data networks) and the assignment of addresses to terminals which access data networks.
2. Description of the Prior Art
The dynamic host configuration protocol (DHCP) proposes authentication (auth) extension to guarantee that only authorized users have access to a packet data network (IP networks). The service provider network providing connectivity for a user to a packet data network has to authenticate the user (wireless terminal) during the network registration and address allocation procedure. Typically, mobile networks utilize a dynamic addressing scheme which is implemented using the DHCP protocol to connect users to network devices which connect the user to the packet data network. However, it should be understood that utilization of the DHCP protocol is not limited to wireless networks. The DHCPv4 and the DHCPv6 protocols enable dynamic configuration of IP addresses and options and use the User Data Protocol (UDP) as the communication protocol. The network entities utilized in the DHCPv4 and DHCPv6 protocols are the server, the user and an optional relay. The server is the entity that distributes network addresses and information to the users. The optional relay provides forwarding of DHCP messages so that one DHCP server serves many subnetworks instead of one server being assigned to each subnetwork. All communications between the DHCP user and the DHCP server take place utilizing a request-reply style message exchange. All DHCP messages may also contain one or more options (DHCPv4)/extensions (DHCPv6) that carry additional useful parameters between the DHCP user and server.
The communications involved with the DHCPv4 protocol are illustrated in FIG.
1
. While not illustrated, an optional relay may be used to forward DHCP messages so that the server serves plural subnetworks. When a DHCPv4 user connects to a network and wishes to acquire an IPv4 address and other work information, it first broadcasts a DHCP discover message to the network in order to discover the presence of any DHCP server which may provide connectivity of the user to a packet data network. The user receives a DHCP offer message from all of the servers that received its DHCP discover message which were configured to answer to the user. The DHCP offer message includes the server's IP address and all other network information which the server assumes the user will need. The user selects the DHCP server whose DHCP offer message is the first one received and discards the rest. The user informs the server whose DHCP offer message was accepted with a DHCP request transmitted to the server to begin the user's use of the IP address. The server acknowledges the request by sending the DHCP acknowledgment to the user which then may start using the assigned IP address.
Whenever the user wants to deallocate its IP address, it sends a DHCP release message to the server. After the DHCP release message, the user may not use the IP address any more. If the user needs to use the address for a longer time than that was specified, the user has to try to renew the use of the assigned IP address. This has to be done no later than when half of the specified time allocated to the user has been used to have the address renewed. The user renews the address by sending a new DHCP request message to the DHCP server. If the server accepts the renewal of the IP address, it sends a DHCP acknowledgment containing new timer values to the user. The server may also deny the renewal of the address by sending a DHCP non-acknowledgment to the user which forces the user to immediately stop using the IP address and revert to an initial state where restarting of the DHCP address acquisition process and authentication begins. If the server does not respond, the user has the option of sending all of the DHCP servers a DHCP request message that includes the user's IP address. Any DHCP server that is configured to provide the IP address to the user may either renew the address by sending a DHCP acknowledgment or deny the address with a DHCP non-acknowledgment. If no replies are sent, the user stops using the IP address when the timer expires and has thereafter to restart the DHCP protocol from the initial state.
The communications involved with the DHCPv6 protocol are illustrated in FIG.
2
. When a user contacts the network, it will first generate a link-local IPv6 address according to the rules of stateless auto configuration as described in RFC 2462 which specifications are incorporated herein by reference in their entirety. Thereafter, the user will receive a router advertisement and if the router advertisement tells the user to use stateful auto configuration, (i.e. DHCPv6), the user will send a DHCP solicit message to all DHCP agents multicast address to obtain one or more DHCP server addresses. The solicit message may be forwarded by a DHCP relay to the all-DHCP-server multicast address of another network. If the user has been preconfigured with the IP address of a server or a relay and the server or relay is on the same network link as the user, the user may skip the solicit message and select the DHCP protocol with the request message. A DHCP server receiving the solicit message will respond with DHCP advertisement message to inform the user about the server. The advertisement message contains a preference field that informs how interested the server is in serving the particular user. If the user and the server are on the same link, the server replies directly to the user, otherwise, the advertised message is sent by the same DHCP relay that forwarded the solicit message to the server.
The user waits a predefined amount of time so that it has a chance to receive the DHCP advertisement messages from different servers. The DHCP user makes the selection between the DHCP servers based on the preference value by selecting the server that specifies the highest value of interest. If the user receives an advertisement message with the maximum preference value of 255, it may select the respective server immediately and ignore any later received advertisement messages.
The user sends a DHCP address request message to the server it selected in order to request the network configuration parameters from the server. The user requests these parameters by adding an extension concerning those parameters to the request message. By setting the ‘C’ bit field in the request message, the user may request a deallocation of its resources except those explicitly listed in the extensions. By setting the ‘R’ bit field, the user requests a deallocation of all of the resources it had previously required. These deallocation requests are very useful when a user restarts because the user may have lost some or all of its previous state in the restarting process. The request message contains a transaction ID field which is a monotonically increasing unsigned integer number that is used to identify the request message and combines it with the DHCP reply.
The server sends one DHCP reply message in response to every received DHCP request message. The reply message carries all the important network information as message extensions which provides flexibility to information exchange. The transaction ID field is copied from the request message in order to associate the reply message with the correct request.
Whenever the DHCP user wants to deallocate some parameters it has received, it may do so by sending a DHCP release message directly to the server. The parameters that are to be released are listed as extensions. A release message without extension causes the server to release all the resources the user has acquired. Releasing parameters using the release message is preferable to the aforementioned ‘C’ and ‘R’ bit fields in the request message which should only be used for cleaning up user parameters at start time.
Servers may notify the users that some of their parameters need to be updated by sending a DHCP reconfigure mes
Ala-Laurila Juha
Asokan Nadarajah
Flykt Patrik
Antonelli Terry Stout & Kraus LLP
Halim Sahera
Najjar Saleh
Nokia Corporation
LandOfFree
SIM based authentication mechanism for DHCPv4/v6 messages does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with SIM based authentication mechanism for DHCPv4/v6 messages, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and SIM based authentication mechanism for DHCPv4/v6 messages will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3242393