US20120151091A1 - Network address allocation using a user identity - Google Patents
Network address allocation using a user identity Download PDFInfo
- Publication number
- US20120151091A1 US20120151091A1 US13/402,715 US201213402715A US2012151091A1 US 20120151091 A1 US20120151091 A1 US 20120151091A1 US 201213402715 A US201213402715 A US 201213402715A US 2012151091 A1 US2012151091 A1 US 2012151091A1
- Authority
- US
- United States
- Prior art keywords
- node
- user identity
- network address
- permanent
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
- H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4523—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using lightweight directory access protocol [LDAP]
Definitions
- IP addresses are assigned randomly, or based on a host computer address.
- DHCP Dynamic Host Configuration Protocol
- network administrators may find it onerous to track and control the network address usage of various users. It may also be difficult to assign special privileges to clients in the network based on their role in the organization, for example, since many firewalls operate using IP address-based rules.
- FIG. 1 is a flow diagram illustrating methods of network address allocation according to various embodiments of the invention.
- FIG. 2 is a flow diagram illustrating additional methods of network address allocation according to various embodiments of the invention.
- FIG. 3 is a block diagram of apparatus and systems according to various embodiments of the invention.
- FIG. 4 is a block diagram of an article of manufacture, including a specific machine, according to various embodiments of the invention.
- an identifier associated with a user identity may be generated responsive to detecting access to a network by a node associated with the user identity.
- the node may be assigned a temporary network address.
- the identifier associated with the user identity may be sent to the node.
- At least one permanent network address may be allocated to the node as a replacement for the temporary network address responsive to receiving an allocation request including the identifier from the node.
- the at least one permanent network address may be selected from one or more permanent network addresses previously assigned to the user identity. Additional embodiments are described, and along with the foregoing examples, will be set forth in detail below.
- a unique set of IP addresses is also assigned to them. Thereafter, when a user logs in to a client computer, the DS reassigns any one of the given IP addresses to the client computer that matches its network sub-network. This is done with the help of a DHCP server. For example, assume that a user has been assigned three permanent IP addresses as shown in Table I below when the user account is created in the DS. In this case, the user has been given two IP addresses for the 192.168.0.0 sub-network and one IP address for the 192.168.1.0 sub-network.
- a process which runs along with the authentication service can operate to create a user identifier that is associated by the DS with a list of IP addresses, such as the list shown in Table I, so that the list can later be fetched by a DHCP server.
- the task can operate to send a message, such as a DHCPRelease message, to release the assigned temporary IP address.
- the task may then operate to send a DHSPRequest message, along with the client identifier (obtained from the DS), to obtain one of the permanent IP addresses shown in Table I.
- the DHCP server can process the client identifier to fetch the permanent IP address from the DS that matches the network address of the client computer. After the DHCP server fetches the list from the DS, if a matching IP address is found for the client, the DHCP server can send a DHCPACK message to the client machine. When the user of the client computer logs out, the permanent IP address is released, and the DHCP server again assigns a temporary IP address to the client computer.
- the DHCP server is configured to use the Lightweight Directory Access Protocol (LDAP), where client configuration information is stored in the DS.
- LDAP Lightweight Directory Access Protocol
- the DHCP server can read configuration information dynamically from any DS operating according to an x.500 standard.
- the permanent IP addresses allocated to a user identity can be stored in the DS and associated with the identity of a particular user.
- the addresses assigned via Table I can be included in configuration information that is made available in a directory on the DS for “user1”, as follows:
- a user identifier can be assigned, perhaps as a random number comprising a series of hexadecimal digits. For example, the random number can be added to the dhcp-client-identifier variable above, to provide the identifier “user1XyaZ . . . ”. This modified value is then made available to the user as a unique identifier that is associated with the authenticated user identity (e.g., via log-in activity).
- each request for a permanent IP address should be accompanied by a different, random identifier—so that a DHCP request that includes only a username will be rejected. Only requests to replace a temporary IP address that have the correct username and the random number generated by the DS will be accepted by the DHCP server. In this way, the DHCP server has some assurance that the correct person is requesting the permanently assigned IP address.
- the client computer can operate to send a DHCPRequest message with the generated string “user1XyaZ . . . ” as the client identifier to the DHCP server.
- the DHCP server in turn can then operate to dynamically query the DS for the dhcp-client-identifier variable matching this string, so that any one or more of the permanent IP addresses can be delivered to the DHCP server, perhaps in the form of a list of addresses, with the lease information stored in a lease database.
- the process may occur as follows.
- the client computer is authenticated to the DS, using log-in information supplied by a user, and the DS in turn generates and assigns a unique identifier to the DHCP configuration for that user identity, and sends the resulting identifier information to the client computer.
- the client computer can send a DHCPRelease message to the DHCP server to release the temporary IP address that was used for log-in activity.
- the client computer can then send a DHCPRequest message to the DHCP server to request a permanent IP address, in conjunction with the identifier it has received from the DS.
- the DHCP server then can operate to query the DS, using the identifier it has obtained from the client computer, to determine one or more permanent IP addresses that have been previously assigned to the user identity that is now associated with the client computer.
- the DS can return an IP address mapping list to the DHCP server.
- the DHCP server can then select one of the permanent IP addresses returned by the DS, and allocate this address to the client computer.
- the DHCP server can store the lease information for the allocated address, so that no other DHCP server generates a conflict by allocating the same IP address to another entity at the same time.
- FIG. 1 is a flow diagram illustrating methods 111 of network address allocation according to various embodiments of the invention.
- one or more permanent addresses are assigned to a user identity, and when that user identity attempts to access the network using a temporary address, a unique user identifier is generated. This identifier is sent to the accessing node so that one of the permanent addresses can be requested as a replacement for the temporary address.
- a “permanent” IP address is one that has been pre-assigned to a particular user identity (e.g., defined by a set of log-in credentials), and which is used to replace a temporary IP address in various embodiments of the invention.
- a permanent IP address is one that is intended to be associated with a particular user, regardless of the node used to log-in to a network. The permanent IP address may not be allocated unless the identity of the user is known to the DS.
- a “temporary” IP address is one that is assigned to a node, rather than a user identity, and normally enables any user that operates the node to log-in to a network if valid log-in credentials are supplied.
- the temporary IP address is not assigned to any particular user identity, and can be assigned to a node with no knowledge of the associated user identity.
- the methods 111 are implemented in a machine-accessible and readable medium and are operational over processes within and among networks.
- the networks may be wired, wireless, or a combination of wired and wireless.
- the methods 111 may be implemented as instructions, which when accessed by a specific machine, perform the processing depicted in FIG. 1 . Given this context, network address allocation is now discussed with reference to FIG. 1 .
- a processor-implemented method 111 that can be executed on one or more processors that perform the method may operate to allocate network addresses by assigning one or more permanent network addresses to a user identity at block 121 .
- the method 111 may go on to block 133 with detecting access to a network by a node associated with the user identity.
- the method 111 may operate in a loop at block 133 , waiting until a valid network access attempt by a client computer associated with the user identity is detected.
- a DS can detect valid attempts to access the network associated with the user identity by authenticating the user identity, perhaps via log-in credentials, such as a username/password, or a fingerprint, among other mechanisms.
- the activity at block 133 may comprise authenticating the user identity, and authenticating may in turn comprise determining that log-in credentials received from a particular node are associated with a known user identity.
- the method 111 may continue on to block 137 with generating an identifier associated with the user identity.
- the identifier is one that may be randomly generated by the DS.
- the activity at block 137 may comprise generating the identifier as a random identifier.
- the method 111 may continue on to block 141 with sending the identifier to the node, to enable the node to obtain replacement of a temporary network address (allocated to the node) with the permanent network address.
- the address management server e.g., a DHCP server
- the server can send a query to the DS to obtain the corresponding address mapping list.
- the method 111 may continue on to block 145 with receiving an address mapping request from an address management server, the request including the identifier.
- the DS can respond with a list of addresses that have been permanently assigned to the user identity.
- the method 111 may continue on to block 149 with sending an address mapping list including one or more permanent network addresses to an address management server in response to receiving a request from the address management server, the request including the identifier.
- a DS can be used as a repository for the lists of permanent addresses that have been assigned to various user identities.
- the activity at block 149 may comprise sending the address mapping list from a DS.
- Other embodiments may be realized.
- FIG. 2 is a flow diagram illustrating additional methods 211 of network address allocation according to various embodiments of the invention.
- the methods 211 operate from the perspective of the address management server (e.g., a DHCP server), where a temporary address release request is received from a node, and then an allocation request for a previously-assigned permanent network address is received from the same node, identified by an identifier unique to the node and the user identity. The permanent address is then allocated to the node, based on the user identity and the identifier.
- the address management server e.g., a DHCP server
- the methods 211 are implemented in a machine-accessible and readable medium, and are operational over processes within and among networks.
- the networks may be wired, wireless, or a combination of wired and wireless.
- the methods 211 may be implemented as instructions, which when accessed by a specific machine, perform the processing depicted in FIG. 2 .
- a processor-implemented method 211 that can be executed on one or more processors that perform the method may begin with waiting at block 221 to receive a release request from a node to release a temporary network address allocated to the node, wherein the node is associated with a user identity.
- the method 211 may continue on to block 225 with receiving an allocation request from the node to allocate a permanent network address previously assigned to the user identity, wherein the request includes an identifier generated in association with the node and the user identity.
- the node may send its allocation request to a DHCP server.
- the activity at block 225 may comprise receiving the allocation request at a DHCP server.
- the identifier is one that may be randomly generated by a DS.
- the activity at block 225 may comprise receiving the allocation request including the identifier comprising a randomly-generated identifier generated by a DS.
- Nodes may take the form of physical or virtual machines.
- the activity at block 225 may comprise receiving the allocation request from a virtual machine, a physical machine, or a combination of these.
- the DHCP server can request previously-determined, permanent address assignment information from a DS, based on the identifier that has been temporarily associated with the node and the user identity.
- the method 211 may continue on to block 229 with transmitting an address mapping request to a DS, the request including the identifier.
- the DS can operate to send the DHCP server one or more addresses, perhaps in the form of a list, that have been permanently assigned to the user identity, based on the identifier.
- the method 211 may continue on to block 233 to include receiving an address mapping list including one or more permanent network addresses, from a DS.
- the address mapping list may comprise multiple permanently-assigned network addresses associated with the user identity.
- the method 211 may continue on to block 237 with allocating one of the permanent network addresses to the node as a replacement for the temporary network address.
- the permanent addresses may be assigned or allocated to a specific user identity by a network administrator via the DS.
- the methods described herein do not have to be executed in the order described, or in any particular order. Moreover, various activities described with respect to the methods identified herein can be executed in repetitive, serial, or parallel fashion. The individual activities of the methods shown in FIGS. 1 and 2 can also be combined with each other and/or substituted, one for another, in various ways. Information, including parameters, commands, operands, and other data, can be sent and received in the form of one or more carrier waves. Thus, many other embodiments may be realized.
- FIGS. 1 and 2 can be implemented in various devices, as well as in a computer-readable storage medium, where the methods are adapted to be executed by one or more processors. Further details of such embodiments will now be described.
- FIG. 3 is a block diagram of apparatus 300 and systems 360 according to various embodiments of the invention.
- an apparatus 300 used to implement network address allocation may comprise one or more processing nodes 302 , one or more processors 320 , memory 322 , a transmission module 326 , a generator processor 328 , and a display 342 .
- the display 342 may be used to display a menu of permanent addresses 332 that are currently allocated to a particular user identity.
- the apparatus 300 may comprise a server, a client, or some other networked processing node.
- the processing nodes 302 may comprise physical machines or virtual machines, or a mixture of both.
- the nodes 302 may also comprise networked entities, such servers and/or clients. In some implementations, the operations described can occur entirely within a single node 302 .
- a system 360 that operates to implement network address allocation may comprise multiple instances of an apparatus 300 .
- the system 360 might also comprise a cluster of nodes 302 , including physical and virtual nodes. It should be noted that any one of the nodes 302 may include any one or more of the elements explicitly shown in nodes NODE_ 1 , . . . , NODE_N.
- a system 360 can operate using multiple nodes: one node (e.g., NODE_ 1 ) operating as a DS, another operating as a client (e.g., NODE_ 2 ), and still another (e.g., NODE_N) as a DHCP server.
- NODE_ 1 node operating as a DS
- NODE_ 2 another operating as a client
- NODE_N still another
- the storage of permanently allocated addresses 332 may occur in yet another node (e.g., NODE_ 3 ), completely apart from the DS, client, and DHCP nodes NODE_ 1 , NODE_ 2 , and NODE_N, in some embodiments.
- a system 360 comprises a first node (e.g., NODE_ 1 ) that provides unique identifiers 338 that enable a second node (e.g., NODE_ 2 ) to replace temporary addresses TMPADD with permanent ones PERMADD that are associated with a particular user identity.
- NODE_ 1 a first node
- NODE_ 2 a second node
- a system 360 may also comprise a first node (e.g., NODE_ 1 ) to access a storage unit 354 or memory 322 to store a plurality of mapping lists 340 , at least one of the plurality of mapping lists 340 including one or more permanent network addresses 332 assigned to a user identity.
- the system 360 may further comprise a generator module 328 to generate an identifier 338 associated with the user identity when access to a network 316 by a second node (e.g., NODE_ 2 ) associated with the user identity is detected.
- the system 360 may comprise, in addition, a transmission module 326 to send the identifier 338 to the second node (e.g., NODE_ 2 ) to enable the second node to obtain replacement of a temporary network address TMPADD allocated to the second node with one of the permanent network addresses 332 .
- a transmission module 326 to send the identifier 338 to the second node (e.g., NODE_ 2 ) to enable the second node to obtain replacement of a temporary network address TMPADD allocated to the second node with one of the permanent network addresses 332 .
- the first node (e.g., NODE_ 1 ) may comprise a DS server.
- the device used to store the mapping lists 340 can be separated from the first node, and thus, the system 360 may further comprise the storage unit 354 housed in a third node (e.g., NODE_ 3 ). Still further embodiments may be realized.
- a system 360 comprises a first node that provides address allocation to a second (client) node, to replace a temporary address held by the second node with a permanent address associated with a particular user identity.
- a system 360 may comprise a first node (e.g., NODE_N) to receive a release request 344 from a second node (e.g., NODE_ 2 ) to release a temporary network address TMPADD allocated to the second node, wherein the second node is associated with a user identity.
- the first node may further operate to receive an allocation request 346 from the second node to allocate a permanent network address PERMADD previously assigned to the user identity, wherein the allocation request 346 includes an identifier 338 generated in association with the second node and the user identity.
- the system 360 may further include an allocation module 356 to allocate the permanent network address PERMADD to the second node as a replacement for the temporary network address TMPADD.
- the system 360 may include a DHCP server to provide the services of the first node (e.g., NODE_N).
- the first node may comprise a DHCP server.
- the system 360 may include a DS as part of another node.
- the system 360 may comprise a third node (e.g., NODE_ 1 ) to couple to the first node and to provide a directory service to assign the permanent network address PERMADD to the user identity.
- the nodes 302 may exist as a device embedded within another structure (e.g., as an embedded device), or as a desktop or laptop computer that includes a display 342 to show the activities conducted while the node 302 is active.
- the system 360 may also comprise a display 342 coupled to the nodes 302 to display visible indications of the activities conducted at the nodes 302 .
- the apparatus 300 and system 360 may be implemented in a machine-accessible and readable medium that is operational over one or more networks 316 .
- the networks 316 may be wired, wireless, or a combination of wired and wireless.
- the apparatus 300 and system 360 can be used to implement, among other things, the processing associated with the methods 111 and 211 of FIGS. 1 and 2 , respectively. Modules may comprise hardware, software, and firmware, or any combination of these. Additional embodiments may be realized.
- FIG. 4 is a block diagram of an article 400 of manufacture, including a specific machine 402 , according to various embodiments of the invention.
- a software program can be launched from a computer-readable medium in a computer-based system to execute the functions defined in the software program.
- the programs may be structured in an object-orientated format using an object-oriented language such as Java or C++.
- the programs can be structured in a procedure-orientated format using a procedural language, such as assembly or C.
- the software components may communicate using any of a number of mechanisms well known to those of ordinary skill in the art, such as application program interfaces or interprocess communication techniques, including remote procedure calls.
- the teachings of various embodiments are not limited to any particular programming language or environment. Thus, other embodiments may be realized.
- an article 400 of manufacture such as a computer, a memory system, a magnetic or optical disk, some other storage device, and/or any type of electronic device or system may include one or more processors 404 coupled to a machine-readable medium 408 such as a memory (e.g., removable storage media, as well as any memory including an electrical, optical, or electromagnetic conductor) having instructions 412 stored thereon (e.g., computer program instructions), which when executed by the one or more processors 404 result in the machine 402 performing any of the actions described with respect to the methods above.
- a machine-readable medium 408 such as a memory (e.g., removable storage media, as well as any memory including an electrical, optical, or electromagnetic conductor) having instructions 412 stored thereon (e.g., computer program instructions), which when executed by the one or more processors 404 result in the machine 402 performing any of the actions described with respect to the methods above.
- the machine 402 may take the form of a specific computer system having a processor 404 coupled to a number of components directly, and/or using a bus 416 . Thus, the machine 402 may be similar to or identical to the apparatus 300 or system 360 shown in FIG. 3 .
- the components of the machine 402 may include main memory 420 , static or non-volatile memory 424 , and mass storage 406 .
- Other components coupled to the processor 404 may include an input device 432 , such as a keyboard, or a cursor control device 436 , such as a mouse.
- An output device 428 such as a video display, may be located apart from the machine 402 (as shown), or made as an integral part of the machine 402 .
- a network interface device 440 to couple the processor 404 and other components to a network 444 may also be coupled to the bus 416 .
- the instructions 412 may be transmitted or received over the network 444 via the network interface device 440 utilizing any one of a number of well-known transfer protocols (e.g., HyperText Transfer Protocol). Any of these elements coupled to the bus 416 may be absent, present singly, or present in plural numbers, depending on the specific embodiment to be realized.
- the processor 404 , the memories 420 , 424 , and the storage device 406 may each include instructions 412 which, when executed, cause the machine 402 to perform any one or more of the methods described herein.
- the machine 402 operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked environment, the machine 402 may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine 402 may comprise a personal computer (PC), a tablet PC, a set-top box (STB), a PDA, a notebook computer, a cellular telephone, a web appliance, a network router, switch or bridge, server, client, or any specific machine capable of executing a set of instructions (sequential or otherwise) that direct actions to be taken by that machine to implement the methods and functions described herein.
- PC personal computer
- PDA personal digital assistant
- notebook computer a cellular telephone
- web appliance a web appliance
- network router, switch or bridge server, client, or any specific machine capable of executing a set of instructions (sequential or otherwise) that direct actions to be taken by that machine to implement the methods and functions described herein.
- server any specific machine capable of executing a set of instructions (sequential or otherwise) that direct actions to be taken by that machine to implement the methods and functions described herein.
- machine shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to
- machine-readable medium 408 is shown as a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers, and or a variety of storage media, such as the registers of the processor 404 , memories 420 , 424 , and the storage device 406 that store the one or more sets of instructions 412 .
- machine-readable medium should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers, and or a variety of storage media, such as the registers of the processor 404 , memories 420 , 424 , and the storage device 406 that store the one or more sets of instructions 412 .
- machine-readable medium shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine 402 to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions.
- machine-readable medium or “computer-readable medium” shall accordingly be taken to include tangible media, such as solid-state memories and optical and magnetic media.
- Embodiments may be implemented as a stand-alone application (e.g., without any network capabilities), a client-server application or a peer-to-peer (or distributed) application.
- Embodiments may also, for example, be deployed by Software-as-a-Service (SaaS), an Application Service Provider (ASP), or utility computing providers, in addition to being sold or licensed via traditional channels.
- SaaS Software-as-a-Service
- ASP Application Service Provider
- utility computing providers in addition to being sold or licensed via traditional channels.
- Implementing the apparatus, systems, and methods described herein may operate to pre-allocate a set of IP addresses to users when user accounts are created by a DS. This assignment of permanent IP addresses to specific user identities can make it much easier for network administrators to monitor and control the activity of users within a network. Further, the mechanisms described herein can make it possible for individual users to receive the same IP address whenever they log in to a particular network, regardless of the device used to gain access. More efficient allocation of processing resources, and increased user satisfaction, may result.
Abstract
Description
- The present application is a continuation of U.S. patent application Ser. No. 12/604,714, entitled “NETWORK ADDRESS ALLOCATION USING A USER IDENTITY,” filed on Oct. 23, 2009, which is incorporated herein by reference in its entirety.
- Currently, Internet Protocol (IP) addresses are assigned randomly, or based on a host computer address. Thus, with some organizations having hundreds or thousands of computers using the Dynamic Host Configuration Protocol (DHCP) for dynamic IP allocation, network administrators may find it onerous to track and control the network address usage of various users. It may also be difficult to assign special privileges to clients in the network based on their role in the organization, for example, since many firewalls operate using IP address-based rules.
-
FIG. 1 is a flow diagram illustrating methods of network address allocation according to various embodiments of the invention. -
FIG. 2 is a flow diagram illustrating additional methods of network address allocation according to various embodiments of the invention. -
FIG. 3 is a block diagram of apparatus and systems according to various embodiments of the invention. -
FIG. 4 is a block diagram of an article of manufacture, including a specific machine, according to various embodiments of the invention. - In various embodiments, apparatus, systems, and methods that support network address allocation are provided. For example, in some embodiments, an identifier associated with a user identity may be generated responsive to detecting access to a network by a node associated with the user identity. The node may be assigned a temporary network address. The identifier associated with the user identity may be sent to the node. At least one permanent network address may be allocated to the node as a replacement for the temporary network address responsive to receiving an allocation request including the identifier from the node. The at least one permanent network address may be selected from one or more permanent network addresses previously assigned to the user identity. Additional embodiments are described, and along with the foregoing examples, will be set forth in detail below.
- To address some of the challenges described above, in various embodiments, when user accounts are created by a directory service (DS), a unique set of IP addresses is also assigned to them. Thereafter, when a user logs in to a client computer, the DS reassigns any one of the given IP addresses to the client computer that matches its network sub-network. This is done with the help of a DHCP server. For example, assume that a user has been assigned three permanent IP addresses as shown in Table I below when the user account is created in the DS. In this case, the user has been given two IP addresses for the 192.168.0.0 sub-network and one IP address for the 192.168.1.0 sub-network.
-
TABLE I IP Address NETWORK SUBNET 192.168.0.50 192.168.0.0 192.168.0.51 192.168.0.0 192.168.1.50 192.168.1.0 - When the user acts to log-in to a client computer in the 192.168.0.0 sub-network, it turns out that the client computer has already been assigned a temporary IP address by a DHCP server in the network. This temporary IP address can be used to log-in to the client computer (e.g., via DS logging). When the log-in action is authorized by the DS, a process which runs along with the authentication service (e.g., the Novell® NMAS (Novell Modular Authentication Service) directory service) can operate to create a user identifier that is associated by the DS with a list of IP addresses, such as the list shown in Table I, so that the list can later be fetched by a DHCP server.
- Therefore, when the client computer runs the startup task (e.g., Novell® Client™ workstation software application), the task can operate to send a message, such as a DHCPRelease message, to release the assigned temporary IP address. The task may then operate to send a DHSPRequest message, along with the client identifier (obtained from the DS), to obtain one of the permanent IP addresses shown in Table I.
- The DHCP server can process the client identifier to fetch the permanent IP address from the DS that matches the network address of the client computer. After the DHCP server fetches the list from the DS, if a matching IP address is found for the client, the DHCP server can send a DHCPACK message to the client machine. When the user of the client computer logs out, the permanent IP address is released, and the DHCP server again assigns a temporary IP address to the client computer.
- In some embodiments, the DHCP server is configured to use the Lightweight Directory Access Protocol (LDAP), where client configuration information is stored in the DS. In this case, the DHCP server can read configuration information dynamically from any DS operating according to an x.500 standard.
- Thus, in some embodiments, the permanent IP addresses allocated to a user identity (e.g., similar to or identical to the addresses shown in Table I) can be stored in the DS and associated with the identity of a particular user. For example, the addresses assigned via Table I can be included in configuration information that is made available in a directory on the DS for “user1”, as follows:
-
host1 { //The name is independent of the configuration ... dhcp-client-identifier “user1”; fixed-address 192.168.0.0, 192.168.1.0; } - When the DS authentication process operates to verify the identity of the user, a user identifier can be assigned, perhaps as a random number comprising a series of hexadecimal digits. For example, the random number can be added to the dhcp-client-identifier variable above, to provide the identifier “user1XyaZ . . . ”. This modified value is then made available to the user as a unique identifier that is associated with the authenticated user identity (e.g., via log-in activity).
- The resulting random identifier that is delivered to the client computer is useful to prevent other entities from stealing permanently assigned IP addresses by making a false claim to the user identity without authentication. Thus, each request for a permanent IP address should be accompanied by a different, random identifier—so that a DHCP request that includes only a username will be rejected. Only requests to replace a temporary IP address that have the correct username and the random number generated by the DS will be accepted by the DHCP server. In this way, the DHCP server has some assurance that the correct person is requesting the permanently assigned IP address. Thus, in this example, the client computer can operate to send a DHCPRequest message with the generated string “user1XyaZ . . . ” as the client identifier to the DHCP server.
- The DHCP server in turn can then operate to dynamically query the DS for the dhcp-client-identifier variable matching this string, so that any one or more of the permanent IP addresses can be delivered to the DHCP server, perhaps in the form of a list of addresses, with the lease information stored in a lease database.
- In summary, the process may occur as follows. The client computer is authenticated to the DS, using log-in information supplied by a user, and the DS in turn generates and assigns a unique identifier to the DHCP configuration for that user identity, and sends the resulting identifier information to the client computer. As part of this process, the client computer can send a DHCPRelease message to the DHCP server to release the temporary IP address that was used for log-in activity. The client computer can then send a DHCPRequest message to the DHCP server to request a permanent IP address, in conjunction with the identifier it has received from the DS.
- The DHCP server then can operate to query the DS, using the identifier it has obtained from the client computer, to determine one or more permanent IP addresses that have been previously assigned to the user identity that is now associated with the client computer. In response, the DS can return an IP address mapping list to the DHCP server.
- The DHCP server can then select one of the permanent IP addresses returned by the DS, and allocate this address to the client computer. The DHCP server can store the lease information for the allocated address, so that no other DHCP server generates a conflict by allocating the same IP address to another entity at the same time.
- Thus, many embodiments of the invention may be realized, and each can be implemented in a variety of architectural platforms, along with various operating and server systems, devices, and applications. Any particular architectural layout or implementation presented herein is therefore provided for purposes of illustration and comprehension only, and is not intended to limit the various embodiments.
-
FIG. 1 is a flow diagramillustrating methods 111 of network address allocation according to various embodiments of the invention. In some embodiments, as viewed from the perspective of the DS, one or more permanent addresses are assigned to a user identity, and when that user identity attempts to access the network using a temporary address, a unique user identifier is generated. This identifier is sent to the accessing node so that one of the permanent addresses can be requested as a replacement for the temporary address. - For the purposes of this document, a “permanent” IP address is one that has been pre-assigned to a particular user identity (e.g., defined by a set of log-in credentials), and which is used to replace a temporary IP address in various embodiments of the invention. Thus, a permanent IP address is one that is intended to be associated with a particular user, regardless of the node used to log-in to a network. The permanent IP address may not be allocated unless the identity of the user is known to the DS.
- A “temporary” IP address is one that is assigned to a node, rather than a user identity, and normally enables any user that operates the node to log-in to a network if valid log-in credentials are supplied. The temporary IP address is not assigned to any particular user identity, and can be assigned to a node with no knowledge of the associated user identity.
- The
methods 111 are implemented in a machine-accessible and readable medium and are operational over processes within and among networks. The networks may be wired, wireless, or a combination of wired and wireless. Themethods 111 may be implemented as instructions, which when accessed by a specific machine, perform the processing depicted inFIG. 1 . Given this context, network address allocation is now discussed with reference toFIG. 1 . - In some embodiments, a processor-implemented
method 111 that can be executed on one or more processors that perform the method may operate to allocate network addresses by assigning one or more permanent network addresses to a user identity atblock 121. Themethod 111 may go on to block 133 with detecting access to a network by a node associated with the user identity. Themethod 111 may operate in a loop atblock 133, waiting until a valid network access attempt by a client computer associated with the user identity is detected. - A DS can detect valid attempts to access the network associated with the user identity by authenticating the user identity, perhaps via log-in credentials, such as a username/password, or a fingerprint, among other mechanisms. Thus, the activity at
block 133 may comprise authenticating the user identity, and authenticating may in turn comprise determining that log-in credentials received from a particular node are associated with a known user identity. - Once an access attempt associated with a particular user identify has been detected, the
method 111 may continue on to block 137 with generating an identifier associated with the user identity. The identifier is one that may be randomly generated by the DS. Thus, the activity atblock 137 may comprise generating the identifier as a random identifier. - The
method 111 may continue on to block 141 with sending the identifier to the node, to enable the node to obtain replacement of a temporary network address (allocated to the node) with the permanent network address. - Once the address management server (e.g., a DHCP server) gets the address replacement request from the node, the server can send a query to the DS to obtain the corresponding address mapping list. Thus, the
method 111 may continue on to block 145 with receiving an address mapping request from an address management server, the request including the identifier. - Once the DHCP server sends the query with the identifier to the DS, the DS can respond with a list of addresses that have been permanently assigned to the user identity. Thus, the
method 111 may continue on to block 149 with sending an address mapping list including one or more permanent network addresses to an address management server in response to receiving a request from the address management server, the request including the identifier. - As noted previously, a DS can be used as a repository for the lists of permanent addresses that have been assigned to various user identities. Thus, the activity at
block 149 may comprise sending the address mapping list from a DS. Other embodiments may be realized. - For example,
FIG. 2 is a flow diagram illustratingadditional methods 211 of network address allocation according to various embodiments of the invention. In this case, themethods 211 operate from the perspective of the address management server (e.g., a DHCP server), where a temporary address release request is received from a node, and then an allocation request for a previously-assigned permanent network address is received from the same node, identified by an identifier unique to the node and the user identity. The permanent address is then allocated to the node, based on the user identity and the identifier. - The
methods 211 are implemented in a machine-accessible and readable medium, and are operational over processes within and among networks. The networks may be wired, wireless, or a combination of wired and wireless. Themethods 211 may be implemented as instructions, which when accessed by a specific machine, perform the processing depicted inFIG. 2 . - Thus, in some embodiments, a processor-implemented
method 211 that can be executed on one or more processors that perform the method may begin with waiting atblock 221 to receive a release request from a node to release a temporary network address allocated to the node, wherein the node is associated with a user identity. - Once the request is received, the
method 211 may continue on to block 225 with receiving an allocation request from the node to allocate a permanent network address previously assigned to the user identity, wherein the request includes an identifier generated in association with the node and the user identity. The node may send its allocation request to a DHCP server. Thus, the activity atblock 225 may comprise receiving the allocation request at a DHCP server. - The identifier is one that may be randomly generated by a DS. Thus, the activity at
block 225 may comprise receiving the allocation request including the identifier comprising a randomly-generated identifier generated by a DS. - Nodes may take the form of physical or virtual machines. Thus, the activity at
block 225 may comprise receiving the allocation request from a virtual machine, a physical machine, or a combination of these. - The DHCP server can request previously-determined, permanent address assignment information from a DS, based on the identifier that has been temporarily associated with the node and the user identity. Thus, the
method 211 may continue on to block 229 with transmitting an address mapping request to a DS, the request including the identifier. - The DS can operate to send the DHCP server one or more addresses, perhaps in the form of a list, that have been permanently assigned to the user identity, based on the identifier. Thus, the
method 211 may continue on to block 233 to include receiving an address mapping list including one or more permanent network addresses, from a DS. The address mapping list may comprise multiple permanently-assigned network addresses associated with the user identity. - The
method 211 may continue on to block 237 with allocating one of the permanent network addresses to the node as a replacement for the temporary network address. The permanent addresses may be assigned or allocated to a specific user identity by a network administrator via the DS. - The methods described herein do not have to be executed in the order described, or in any particular order. Moreover, various activities described with respect to the methods identified herein can be executed in repetitive, serial, or parallel fashion. The individual activities of the methods shown in
FIGS. 1 and 2 can also be combined with each other and/or substituted, one for another, in various ways. Information, including parameters, commands, operands, and other data, can be sent and received in the form of one or more carrier waves. Thus, many other embodiments may be realized. - The methods of network address allocation shown in
FIGS. 1 and 2 can be implemented in various devices, as well as in a computer-readable storage medium, where the methods are adapted to be executed by one or more processors. Further details of such embodiments will now be described. -
FIG. 3 is a block diagram ofapparatus 300 andsystems 360 according to various embodiments of the invention. Here it can be seen that anapparatus 300 used to implement network address allocation may comprise one ormore processing nodes 302, one ormore processors 320,memory 322, atransmission module 326, agenerator processor 328, and adisplay 342. Thedisplay 342 may be used to display a menu ofpermanent addresses 332 that are currently allocated to a particular user identity. Theapparatus 300 may comprise a server, a client, or some other networked processing node. - The
processing nodes 302 may comprise physical machines or virtual machines, or a mixture of both. Thenodes 302 may also comprise networked entities, such servers and/or clients. In some implementations, the operations described can occur entirely within asingle node 302. - In some embodiments, a
system 360 that operates to implement network address allocation may comprise multiple instances of anapparatus 300. Thesystem 360 might also comprise a cluster ofnodes 302, including physical and virtual nodes. It should be noted that any one of thenodes 302 may include any one or more of the elements explicitly shown in nodes NODE_1, . . . , NODE_N. - In some embodiments then, a
system 360 can operate using multiple nodes: one node (e.g., NODE_1) operating as a DS, another operating as a client (e.g., NODE_2), and still another (e.g., NODE_N) as a DHCP server. The storage of permanently allocated addresses 332, perhaps in the forms oflists 340, may occur in yet another node (e.g., NODE_3), completely apart from the DS, client, and DHCP nodes NODE_1, NODE_2, and NODE_N, in some embodiments. - Thus, in some embodiments, a
system 360 comprises a first node (e.g., NODE_1) that providesunique identifiers 338 that enable a second node (e.g., NODE_2) to replace temporary addresses TMPADD with permanent ones PERMADD that are associated with a particular user identity. - A
system 360 may also comprise a first node (e.g., NODE_1) to access astorage unit 354 ormemory 322 to store a plurality of mapping lists 340, at least one of the plurality of mapping lists 340 including one or more permanent network addresses 332 assigned to a user identity. Thesystem 360 may further comprise agenerator module 328 to generate anidentifier 338 associated with the user identity when access to anetwork 316 by a second node (e.g., NODE_2) associated with the user identity is detected. Thesystem 360 may comprise, in addition, atransmission module 326 to send theidentifier 338 to the second node (e.g., NODE_2) to enable the second node to obtain replacement of a temporary network address TMPADD allocated to the second node with one of the permanent network addresses 332. - The first node (e.g., NODE_1) may comprise a DS server. The device used to store the mapping lists 340 can be separated from the first node, and thus, the
system 360 may further comprise thestorage unit 354 housed in a third node (e.g., NODE_3). Still further embodiments may be realized. - In some embodiments, a
system 360 comprises a first node that provides address allocation to a second (client) node, to replace a temporary address held by the second node with a permanent address associated with a particular user identity. Thus, asystem 360 may comprise a first node (e.g., NODE_N) to receive arelease request 344 from a second node (e.g., NODE_2) to release a temporary network address TMPADD allocated to the second node, wherein the second node is associated with a user identity. The first node may further operate to receive anallocation request 346 from the second node to allocate a permanent network address PERMADD previously assigned to the user identity, wherein theallocation request 346 includes anidentifier 338 generated in association with the second node and the user identity. Thesystem 360 may further include anallocation module 356 to allocate the permanent network address PERMADD to the second node as a replacement for the temporary network address TMPADD. - The
system 360 may include a DHCP server to provide the services of the first node (e.g., NODE_N). Thus, the first node may comprise a DHCP server. Thesystem 360 may include a DS as part of another node. Thus, thesystem 360 may comprise a third node (e.g., NODE_1) to couple to the first node and to provide a directory service to assign the permanent network address PERMADD to the user identity. - The
nodes 302 may exist as a device embedded within another structure (e.g., as an embedded device), or as a desktop or laptop computer that includes adisplay 342 to show the activities conducted while thenode 302 is active. Thus, thesystem 360 may also comprise adisplay 342 coupled to thenodes 302 to display visible indications of the activities conducted at thenodes 302. - The
apparatus 300 andsystem 360 may be implemented in a machine-accessible and readable medium that is operational over one ormore networks 316. Thenetworks 316 may be wired, wireless, or a combination of wired and wireless. Theapparatus 300 andsystem 360 can be used to implement, among other things, the processing associated with themethods FIGS. 1 and 2 , respectively. Modules may comprise hardware, software, and firmware, or any combination of these. Additional embodiments may be realized. - For example,
FIG. 4 is a block diagram of anarticle 400 of manufacture, including aspecific machine 402, according to various embodiments of the invention. Upon reading and comprehending the content of this disclosure, one of ordinary skill in the art will understand the manner in which a software program can be launched from a computer-readable medium in a computer-based system to execute the functions defined in the software program. - One of ordinary skill in the art will further understand the various programming languages that may be employed to create one or more software programs designed to implement and perform the methods disclosed herein. The programs may be structured in an object-orientated format using an object-oriented language such as Java or C++. Alternatively, the programs can be structured in a procedure-orientated format using a procedural language, such as assembly or C. The software components may communicate using any of a number of mechanisms well known to those of ordinary skill in the art, such as application program interfaces or interprocess communication techniques, including remote procedure calls. The teachings of various embodiments are not limited to any particular programming language or environment. Thus, other embodiments may be realized.
- For example, an
article 400 of manufacture, such as a computer, a memory system, a magnetic or optical disk, some other storage device, and/or any type of electronic device or system may include one ormore processors 404 coupled to a machine-readable medium 408 such as a memory (e.g., removable storage media, as well as any memory including an electrical, optical, or electromagnetic conductor) havinginstructions 412 stored thereon (e.g., computer program instructions), which when executed by the one ormore processors 404 result in themachine 402 performing any of the actions described with respect to the methods above. - The
machine 402 may take the form of a specific computer system having aprocessor 404 coupled to a number of components directly, and/or using abus 416. Thus, themachine 402 may be similar to or identical to theapparatus 300 orsystem 360 shown inFIG. 3 . - Turning now to
FIG. 4 , it can be seen that the components of themachine 402 may includemain memory 420, static ornon-volatile memory 424, andmass storage 406. Other components coupled to theprocessor 404 may include aninput device 432, such as a keyboard, or acursor control device 436, such as a mouse. Anoutput device 428, such as a video display, may be located apart from the machine 402 (as shown), or made as an integral part of themachine 402. - A
network interface device 440 to couple theprocessor 404 and other components to anetwork 444 may also be coupled to thebus 416. Theinstructions 412 may be transmitted or received over thenetwork 444 via thenetwork interface device 440 utilizing any one of a number of well-known transfer protocols (e.g., HyperText Transfer Protocol). Any of these elements coupled to thebus 416 may be absent, present singly, or present in plural numbers, depending on the specific embodiment to be realized. - The
processor 404, thememories storage device 406 may each includeinstructions 412 which, when executed, cause themachine 402 to perform any one or more of the methods described herein. In some embodiments, themachine 402 operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked environment, themachine 402 may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. - The
machine 402 may comprise a personal computer (PC), a tablet PC, a set-top box (STB), a PDA, a notebook computer, a cellular telephone, a web appliance, a network router, switch or bridge, server, client, or any specific machine capable of executing a set of instructions (sequential or otherwise) that direct actions to be taken by that machine to implement the methods and functions described herein. Further, while only asingle machine 402 is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. - While the machine-
readable medium 408 is shown as a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers, and or a variety of storage media, such as the registers of theprocessor 404,memories storage device 406 that store the one or more sets ofinstructions 412. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause themachine 402 to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The terms “machine-readable medium” or “computer-readable medium” shall accordingly be taken to include tangible media, such as solid-state memories and optical and magnetic media. - Various embodiments may be implemented as a stand-alone application (e.g., without any network capabilities), a client-server application or a peer-to-peer (or distributed) application. Embodiments may also, for example, be deployed by Software-as-a-Service (SaaS), an Application Service Provider (ASP), or utility computing providers, in addition to being sold or licensed via traditional channels.
- Implementing the apparatus, systems, and methods described herein may operate to pre-allocate a set of IP addresses to users when user accounts are created by a DS. This assignment of permanent IP addresses to specific user identities can make it much easier for network administrators to monitor and control the activity of users within a network. Further, the mechanisms described herein can make it possible for individual users to receive the same IP address whenever they log in to a particular network, regardless of the device used to gain access. More efficient allocation of processing resources, and increased user satisfaction, may result.
- This Detailed Description is illustrative, and not restrictive. Many other embodiments will be apparent to those of ordinary skill in the art upon reviewing this disclosure. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
- The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
- In this Detailed Description of various embodiments, a number of features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as an implication that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/402,715 US20120151091A1 (en) | 2009-10-23 | 2012-02-22 | Network address allocation using a user identity |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/604,714 US8296403B2 (en) | 2009-10-23 | 2009-10-23 | Network address allocation using a user identity |
US13/402,715 US20120151091A1 (en) | 2009-10-23 | 2012-02-22 | Network address allocation using a user identity |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/604,714 Continuation US8296403B2 (en) | 2009-10-23 | 2009-10-23 | Network address allocation using a user identity |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120151091A1 true US20120151091A1 (en) | 2012-06-14 |
Family
ID=43899307
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/604,714 Expired - Fee Related US8296403B2 (en) | 2009-10-23 | 2009-10-23 | Network address allocation using a user identity |
US13/402,715 Abandoned US20120151091A1 (en) | 2009-10-23 | 2012-02-22 | Network address allocation using a user identity |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/604,714 Expired - Fee Related US8296403B2 (en) | 2009-10-23 | 2009-10-23 | Network address allocation using a user identity |
Country Status (1)
Country | Link |
---|---|
US (2) | US8296403B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170237782A1 (en) * | 2014-06-02 | 2017-08-17 | Nokia Solutions And Networks Oy | Ims restoration support for temporary gruu |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5884793B2 (en) * | 2013-08-28 | 2016-03-15 | 株式会社豊田自動織機 | Loom monitoring system in a weaving factory |
GB2536067B (en) * | 2015-03-17 | 2017-02-22 | Openwave Mobility Inc | Identity management |
CN110048895B (en) * | 2019-04-25 | 2023-01-03 | 广州河东科技有限公司 | Node equipment, hotel network setting method and system |
CN111464503B (en) * | 2020-03-11 | 2022-03-01 | 中国人民解放军战略支援部队信息工程大学 | Network dynamic defense method, device and system based on random multidimensional transformation |
CN111371922B (en) * | 2020-03-31 | 2022-05-03 | 洛阳正扬软件技术有限公司 | Automatic setting algorithm for address of network node without master and slave in network |
CN116668408B (en) * | 2023-08-01 | 2023-10-13 | 华中科技大学 | IPv6 container cloud platform real address coding verification and tracing method and system |
Citations (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6009103A (en) * | 1997-12-23 | 1999-12-28 | Mediaone Group, Inc. | Method and system for automatic allocation of resources in a network |
US6233616B1 (en) * | 1997-10-24 | 2001-05-15 | William J. Reid | Enterprise network management using directory containing network addresses of users obtained through DHCP to control routers and servers |
US20020064141A1 (en) * | 2000-11-24 | 2002-05-30 | Takashi Sakakura | Radio communication control station, radio communication terminal, home agent, and radio communication method |
US20020083012A1 (en) * | 2000-11-16 | 2002-06-27 | Steve Bush | Method and system for account management |
US20030041151A1 (en) * | 2001-08-14 | 2003-02-27 | Senapati Ananta Sankar | System and method for provisioning broadband service in a PPPoE network using a configuration domain name |
US20030061484A1 (en) * | 2001-09-27 | 2003-03-27 | International Business Machines Corporation | Method and system for communication via a computer network |
US6587468B1 (en) * | 1999-02-10 | 2003-07-01 | Cisco Technology, Inc. | Reply to sender DHCP option |
US20030220994A1 (en) * | 2002-02-28 | 2003-11-27 | Chunrong Zhu | Wireless network access system and method |
US20040098507A1 (en) * | 2002-11-20 | 2004-05-20 | Cisco Technology, Inc. | Mobile IP registration supporting port identification |
US20040103310A1 (en) * | 2002-11-27 | 2004-05-27 | Sobel William E. | Enforcement of compliance with network security policies |
US20040153525A1 (en) * | 2003-01-31 | 2004-08-05 | 3Com Corporation | System and method for control of packet data serving node selection in a mobile internet protocol network |
US20040152446A1 (en) * | 2001-05-24 | 2004-08-05 | Saunders Martyn Dv | Method for providing network access to a mobile terminal and corresponding network |
US20040260816A1 (en) * | 2000-03-10 | 2004-12-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for mapping an IP address to an MSISDN number within a wireless application processing network |
US6845094B1 (en) * | 1999-12-16 | 2005-01-18 | Ut Starcom, Inc. | Network address translation based internet protocol mobility |
US20050089010A1 (en) * | 2003-10-27 | 2005-04-28 | Seon-Soo Rue | Method and system for supporting mobility of mobile terminal |
US6957276B1 (en) * | 2000-10-23 | 2005-10-18 | Microsoft Corporation | System and method of assigning and reclaiming static addresses through the dynamic host configuration protocol |
US7016682B2 (en) * | 2002-03-04 | 2006-03-21 | Air Broadband Communications, Inc. | Hybrid wireless access bridge and mobile access router system and method |
US20060101026A1 (en) * | 2002-12-24 | 2006-05-11 | Hajime Fukushima | Communication model, signal, method, and device for confirming reachability in network where host reachability is accomplished by relating static identifier to dynamic address |
US20060140182A1 (en) * | 2004-12-23 | 2006-06-29 | Michael Sullivan | Systems and methods for monitoring and controlling communication traffic |
US20060215595A1 (en) * | 2003-09-15 | 2006-09-28 | Hancock Robert E | Telecommunications system |
US7130629B1 (en) * | 2000-03-08 | 2006-10-31 | Cisco Technology, Inc. | Enabling services for multiple sessions using a single mobile node |
US20070014301A1 (en) * | 2005-07-13 | 2007-01-18 | Motient Corporation | Method and apparatus for providing static addressing |
US7188167B2 (en) * | 2004-03-19 | 2007-03-06 | Motorola, Inc. | Method and system for registering multiple communication devices of a user in a session initiation protocol (SIP) based communication system |
US7277416B1 (en) * | 2003-09-02 | 2007-10-02 | Cellco Partnership | Network based IP address assignment for static IP subscriber |
US7310671B1 (en) * | 2000-02-10 | 2007-12-18 | Paradyne Corporation | System and method for a trouble shooting portal to allow temporary management access to a communication device |
US20090070441A1 (en) * | 2007-09-10 | 2009-03-12 | Ncomputing Inc. | System and method for computer network configuration and operation |
US20090113073A1 (en) * | 2005-06-07 | 2009-04-30 | Nec Corporation | Remote access system and its ip address assigning method |
US20090154394A1 (en) * | 2007-12-18 | 2009-06-18 | Electronics & Telecommunications Research Institute | Call control method for seamless mobility service |
US20100011426A1 (en) * | 2005-11-04 | 2010-01-14 | Siemens Aktiengesellschaft | Subscriber-Specific Enforecement of Proxy-Mobile-IP (PMIP) Instead of Client-Mobile-IP (CMIP) |
US20100046438A1 (en) * | 2006-01-26 | 2010-02-25 | Huawei Technologies, Inc. | Method and System for Implementing Data Routing of Roaming User |
US7689716B2 (en) * | 1998-12-08 | 2010-03-30 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
US20100118831A1 (en) * | 2008-07-31 | 2010-05-13 | International Business Machines Corporation | Method For Network Layer Handoff Over a Wireless LAN and an Associated Access Point Device |
US8055264B2 (en) * | 2005-01-14 | 2011-11-08 | Huawei Technologies Co., Ltd. | Method and apparatus for controlling handoff |
US8140074B2 (en) * | 2008-08-28 | 2012-03-20 | Motorola Solutions, Inc. | Mobile communication network |
US20120131653A1 (en) * | 2010-11-19 | 2012-05-24 | Research In Motion Limited | System, devices and method for secure authentication |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6684243B1 (en) * | 1999-11-25 | 2004-01-27 | International Business Machines Corporation | Method for assigning a dual IP address to a workstation attached on an IP data transmission network |
US7356841B2 (en) * | 2000-05-12 | 2008-04-08 | Solutioninc Limited | Server and method for providing specific network services |
US7194004B1 (en) * | 2002-01-28 | 2007-03-20 | 3Com Corporation | Method for managing network access |
US7965693B2 (en) * | 2002-05-28 | 2011-06-21 | Zte (Usa) Inc. | Interworking mechanism between wireless wide area network and wireless local area network |
US7318148B2 (en) * | 2003-07-31 | 2008-01-08 | Sap Ag | Automatically configuring a computer |
US7457626B2 (en) * | 2004-03-19 | 2008-11-25 | Microsoft Corporation | Virtual private network structure reuse for mobile computing devices |
WO2006012058A1 (en) * | 2004-06-28 | 2006-02-02 | Japan Communications, Inc. | Systems and methods for mutual authentication of network |
US7673010B2 (en) * | 2006-01-27 | 2010-03-02 | Broadcom Corporation | Multi user client terminals operable to support network communications |
US7990891B2 (en) * | 2006-03-31 | 2011-08-02 | France Telecom | Method for organizing a network of communicating objects and communicating object for the implementation of the method |
EP2007098A1 (en) | 2007-06-18 | 2008-12-24 | Nokia Siemens Networks Oy | Methods, apparatuses and computer program product for user equipment authorization based on matching network access technology specific identification information |
US7835304B2 (en) * | 2007-11-28 | 2010-11-16 | Alcatel-Lucent Usa Inc. | Method and apparatus for assigning IP addresses |
US9307393B2 (en) * | 2009-05-15 | 2016-04-05 | Telcordia Technologies, Inc. | Peer-to-peer mobility management in heterogeneous IPV4 networks |
-
2009
- 2009-10-23 US US12/604,714 patent/US8296403B2/en not_active Expired - Fee Related
-
2012
- 2012-02-22 US US13/402,715 patent/US20120151091A1/en not_active Abandoned
Patent Citations (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6233616B1 (en) * | 1997-10-24 | 2001-05-15 | William J. Reid | Enterprise network management using directory containing network addresses of users obtained through DHCP to control routers and servers |
US6009103A (en) * | 1997-12-23 | 1999-12-28 | Mediaone Group, Inc. | Method and system for automatic allocation of resources in a network |
US7689716B2 (en) * | 1998-12-08 | 2010-03-30 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
US6587468B1 (en) * | 1999-02-10 | 2003-07-01 | Cisco Technology, Inc. | Reply to sender DHCP option |
US6845094B1 (en) * | 1999-12-16 | 2005-01-18 | Ut Starcom, Inc. | Network address translation based internet protocol mobility |
US7310671B1 (en) * | 2000-02-10 | 2007-12-18 | Paradyne Corporation | System and method for a trouble shooting portal to allow temporary management access to a communication device |
US7130629B1 (en) * | 2000-03-08 | 2006-10-31 | Cisco Technology, Inc. | Enabling services for multiple sessions using a single mobile node |
US20040260816A1 (en) * | 2000-03-10 | 2004-12-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for mapping an IP address to an MSISDN number within a wireless application processing network |
US6957276B1 (en) * | 2000-10-23 | 2005-10-18 | Microsoft Corporation | System and method of assigning and reclaiming static addresses through the dynamic host configuration protocol |
US20020083012A1 (en) * | 2000-11-16 | 2002-06-27 | Steve Bush | Method and system for account management |
US20020064141A1 (en) * | 2000-11-24 | 2002-05-30 | Takashi Sakakura | Radio communication control station, radio communication terminal, home agent, and radio communication method |
US20040152446A1 (en) * | 2001-05-24 | 2004-08-05 | Saunders Martyn Dv | Method for providing network access to a mobile terminal and corresponding network |
US20030041151A1 (en) * | 2001-08-14 | 2003-02-27 | Senapati Ananta Sankar | System and method for provisioning broadband service in a PPPoE network using a configuration domain name |
US20030061484A1 (en) * | 2001-09-27 | 2003-03-27 | International Business Machines Corporation | Method and system for communication via a computer network |
US20030220994A1 (en) * | 2002-02-28 | 2003-11-27 | Chunrong Zhu | Wireless network access system and method |
US7016682B2 (en) * | 2002-03-04 | 2006-03-21 | Air Broadband Communications, Inc. | Hybrid wireless access bridge and mobile access router system and method |
US20040098507A1 (en) * | 2002-11-20 | 2004-05-20 | Cisco Technology, Inc. | Mobile IP registration supporting port identification |
US20040103310A1 (en) * | 2002-11-27 | 2004-05-27 | Sobel William E. | Enforcement of compliance with network security policies |
US20060101026A1 (en) * | 2002-12-24 | 2006-05-11 | Hajime Fukushima | Communication model, signal, method, and device for confirming reachability in network where host reachability is accomplished by relating static identifier to dynamic address |
US20040153525A1 (en) * | 2003-01-31 | 2004-08-05 | 3Com Corporation | System and method for control of packet data serving node selection in a mobile internet protocol network |
US7277416B1 (en) * | 2003-09-02 | 2007-10-02 | Cellco Partnership | Network based IP address assignment for static IP subscriber |
US20060215595A1 (en) * | 2003-09-15 | 2006-09-28 | Hancock Robert E | Telecommunications system |
US20050089010A1 (en) * | 2003-10-27 | 2005-04-28 | Seon-Soo Rue | Method and system for supporting mobility of mobile terminal |
US7188167B2 (en) * | 2004-03-19 | 2007-03-06 | Motorola, Inc. | Method and system for registering multiple communication devices of a user in a session initiation protocol (SIP) based communication system |
US20060140182A1 (en) * | 2004-12-23 | 2006-06-29 | Michael Sullivan | Systems and methods for monitoring and controlling communication traffic |
US8055264B2 (en) * | 2005-01-14 | 2011-11-08 | Huawei Technologies Co., Ltd. | Method and apparatus for controlling handoff |
US20090113073A1 (en) * | 2005-06-07 | 2009-04-30 | Nec Corporation | Remote access system and its ip address assigning method |
US20070014301A1 (en) * | 2005-07-13 | 2007-01-18 | Motient Corporation | Method and apparatus for providing static addressing |
US20100011426A1 (en) * | 2005-11-04 | 2010-01-14 | Siemens Aktiengesellschaft | Subscriber-Specific Enforecement of Proxy-Mobile-IP (PMIP) Instead of Client-Mobile-IP (CMIP) |
US20100046438A1 (en) * | 2006-01-26 | 2010-02-25 | Huawei Technologies, Inc. | Method and System for Implementing Data Routing of Roaming User |
US20090070441A1 (en) * | 2007-09-10 | 2009-03-12 | Ncomputing Inc. | System and method for computer network configuration and operation |
US20090154394A1 (en) * | 2007-12-18 | 2009-06-18 | Electronics & Telecommunications Research Institute | Call control method for seamless mobility service |
US20100118831A1 (en) * | 2008-07-31 | 2010-05-13 | International Business Machines Corporation | Method For Network Layer Handoff Over a Wireless LAN and an Associated Access Point Device |
US8140074B2 (en) * | 2008-08-28 | 2012-03-20 | Motorola Solutions, Inc. | Mobile communication network |
US20120131653A1 (en) * | 2010-11-19 | 2012-05-24 | Research In Motion Limited | System, devices and method for secure authentication |
Non-Patent Citations (1)
Title |
---|
Droms, Dynamic Host Configuration Protocol, March 1997, Networking Group, Pages 1-45 http://www.ietf.org/rfc/rfc2131.txt * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170237782A1 (en) * | 2014-06-02 | 2017-08-17 | Nokia Solutions And Networks Oy | Ims restoration support for temporary gruu |
US10193937B2 (en) * | 2014-06-02 | 2019-01-29 | Nokia Solutions And Networks Oy | Internet protocol multimedia subsystem (IMS) restoration support for temporary globally routable user agent uniform resource identifier (GRUU) |
Also Published As
Publication number | Publication date |
---|---|
US20110099252A1 (en) | 2011-04-28 |
US8296403B2 (en) | 2012-10-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20120151091A1 (en) | Network address allocation using a user identity | |
US11245576B2 (en) | Blockchain-based configuration profile provisioning system | |
US10757086B2 (en) | Using credentials stored in different directories to access a common endpoint | |
US8474009B2 (en) | Dynamic service access | |
US8966082B2 (en) | Virtual machine address management | |
US20080250407A1 (en) | Network group name for virtual machines | |
US20130326599A1 (en) | Validating Pointer Records In A Domain Name System (DNS) Service | |
US20090320116A1 (en) | Federated realm discovery | |
US9584481B2 (en) | Host providing system and communication control method | |
KR20110055392A (en) | User-based dns server access control | |
US9438629B2 (en) | Sensitive information leakage prevention system, sensitive information leakage prevention method, and computer-readable recording medium | |
CN111464481B (en) | Method, apparatus and computer readable medium for service security protection | |
JP5749812B2 (en) | DNS proxy service for multi-core platforms | |
WO2019059979A1 (en) | Geographic location based computing asset provisioning in distributed computing systems | |
US8738605B2 (en) | Systems for discovering sensitive information on computer networks | |
JP2006180095A (en) | Gateway, and access control method of web server | |
US8738604B2 (en) | Methods for discovering sensitive information on computer networks | |
JP5187981B2 (en) | Apparatus, method and computer program for allocating network resources | |
US8296853B2 (en) | Method and system for authenticating a user | |
JP6484166B2 (en) | Name resolution device, name resolution method, and name resolution program | |
US8996607B1 (en) | Identity-based casting of network addresses | |
US7813274B1 (en) | Dynamic demultiplexing of network traffic | |
US11695773B2 (en) | Distributing dynamic access control lists for managing interactions with a cloud datacenter | |
KR100744083B1 (en) | Method and device for allocating ip address based on authentication of user | |
JP2024010384A (en) | Single sign-on authentication system and single sign-on authentication device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNORS:MICRO FOCUS (US), INC.;BORLAND SOFTWARE CORPORATION;ATTACHMATE CORPORATION;AND OTHERS;REEL/FRAME:035656/0251 Effective date: 20141120 |
|
AS | Assignment |
Owner name: MICRO FOCUS SOFTWARE INC., DELAWARE Free format text: CHANGE OF NAME;ASSIGNOR:NOVELL, INC.;REEL/FRAME:040020/0703 Effective date: 20160718 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT, NEW Free format text: NOTICE OF SUCCESSION OF AGENCY;ASSIGNOR:BANK OF AMERICA, N.A., AS PRIOR AGENT;REEL/FRAME:042388/0386 Effective date: 20170501 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., DELAWARE Free format text: SECURITY INTEREST;ASSIGNORS:ATTACHMATE CORPORATION;BORLAND SOFTWARE CORPORATION;NETIQ CORPORATION;AND OTHERS;REEL/FRAME:044183/0718 Effective date: 20170901 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS SUCCESSOR AGENT, NEW Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE TO CORRECT TYPO IN APPLICATION NUMBER 10708121 WHICH SHOULD BE 10708021 PREVIOUSLY RECORDED ON REEL 042388 FRAME 0386. ASSIGNOR(S) HEREBY CONFIRMS THE NOTICE OF SUCCESSION OF AGENCY;ASSIGNOR:BANK OF AMERICA, N.A., AS PRIOR AGENT;REEL/FRAME:048793/0832 Effective date: 20170501 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: NETIQ CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: ATTACHMATE CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: SERENA SOFTWARE, INC, CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS (US), INC., MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: BORLAND SOFTWARE CORPORATION, MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS LLC (F/K/A ENTIT SOFTWARE LLC), CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 044183/0718;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062746/0399 Effective date: 20230131 Owner name: MICRO FOCUS SOFTWARE INC. (F/K/A NOVELL, INC.), WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: MICRO FOCUS (US), INC., MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: NETIQ CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: ATTACHMATE CORPORATION, WASHINGTON Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 Owner name: BORLAND SOFTWARE CORPORATION, MARYLAND Free format text: RELEASE OF SECURITY INTEREST REEL/FRAME 035656/0251;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:062623/0009 Effective date: 20230131 |